From jfmezei at vaxination.ca Wed Oct 1 01:44:27 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Wed, 01 Oct 2008 02:44:27 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: References: Message-ID: <48E31C4B.30508@vaxination.ca> Ernie Rubi wrote: > From an ops perspective, wonder just how much traffic caused: > > "This morning, our engineers sounded the alarms ... More of a case of a worldwide press conference broadcasted live by news networms around the world when Nancy Pelosi stated that "as of now, the recovery plan is available for everyone to read at the following web address". The web site was immediatly overloaded and remained so for hours. Normally, this web site would have received just a few visits from the public at large every day. All of a sudden, millions of people tried to get to it at the same time. From ops.lists at gmail.com Wed Oct 1 03:35:23 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 1 Oct 2008 14:05:23 +0530 Subject: 143.228.0.0/16 and house.gov In-Reply-To: References: Message-ID: Some political action groups probably decided to step up the astroturfing. You know, enter your email address here and we'll send out some boilerplate nonsense to a bunch of congressmen and senators. Block or firewall the worst of them, whether left or right leaning, and I guess that should leave the servers clear for real users ... --srs On Wed, Oct 1, 2008 at 10:11 AM, Ernie Rubi wrote: > Hi folks, just musing... > > From an ops perspective, wonder just how much traffic caused: > > "This morning, our engineers sounded the alarms ... and we have installed a > digital version of a traffic cop. We enacted stopgaps that we planned for > last night. We had hoped we didn't have to." > --Jeff Ventura, communications director for the House's chief > administrator. (from > http://www.cnn.com/2008/POLITICS/09/30/congress.website/index.html) > > Don't .govs have enough b/w or at least ability to add b/w in order to > satisfy their 'public outreach/information' role? (not a rhetorical > question...hehe) > > It also seems to me that adding load balancing, firewall, throttling, etc > methods for traffic shaping might actually make the problem worse by adding > yet another layer(s) of hardware/software that may be prone to bottlenecking > or overloading. > > whaddayathink? > > Ernie M. Rubi > Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > > > > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From joe at via.net Wed Oct 1 03:56:29 2008 From: joe at via.net (joe mcguckin) Date: Wed, 1 Oct 2008 01:56:29 -0700 Subject: DSL at MAE-East In-Reply-To: <366100670809251536o5632b097qd39e20989d35d609@mail.gmail.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> <366100670809251536o5632b097qd39e20989d35d609@mail.gmail.com> Message-ID: ISR? Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Sep 25, 2008, at 3:36 PM, Brandon Galbraith wrote: > On 9/25/08, Mike Lyon wrote: >> >> Or get an ISR with a 3G GSM card? > > > I'm a fan of this solution. We use T-Mobile with EDGE cards (not 3G, > but I > don't need 3G for SSH, RDP, etc) in several of our colocation > environments > for remote access. At $30/month for the service (per card), it was way > cheaper than a cross-connect and DSL service. Also fairly reliable. > > -brandon From ops.lists at gmail.com Wed Oct 1 03:58:42 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 1 Oct 2008 14:28:42 +0530 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <20081001084756.GA56410@revolt.com> References: <20081001084756.GA56410@revolt.com> Message-ID: On Wed, Oct 1, 2008 at 2:17 PM, chris neill wrote: > > Give me a break. You're telling me the White House's mail servers are even > on the same network as their web servers? What, is this 1997? > Well, I do know that there's two ways you can contact your congressman - * Feedback forms on individual websites * Email srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From morrowc.lists at gmail.com Wed Oct 1 08:55:27 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 1 Oct 2008 09:55:27 -0400 Subject: About.com/NYTimes admins about? In-Reply-To: <48E29470.8060602@nytimes.com> References: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> <75cb24520809270833p4b24013o9993a38406feb745@mail.gmail.com> <48E29470.8060602@nytimes.com> Message-ID: <75cb24520810010655m1d7451edv7509383d8f95b129@mail.gmail.com> On Tue, Sep 30, 2008 at 5:04 PM, Brendan Cleary wrote: > I worked with Chris on this outside of the list. Replying here just to close > the loop in case anyone else was interested. > > This situation is explained in this Case Study: > http://support.citrix.com/article/CTX117947 > > The key sentence being: > "In NetScaler software release 7.0, when the DNS server looks up AAAA > records, the response was "0" and errors "0". However, in NetScaler software > release 8.0, with standard response "0", the NetScaler appliance sends the > delegation records to root. " > > To summarize, if you don't have your NS records in place on the Netscalers, > you will see a loop for AAAA queries (root>auth>netscaler>root....), > eventually resulting in a SERVFAIL. Thanks Brendan! Hopefully Citrix can improve their standard config for this sort of deployment to make this a little simpler? I can't believe NYTimes is the only user of Netscalers for this function. -Chris From jkinz at kinz.org Wed Oct 1 09:17:20 2008 From: jkinz at kinz.org (Jeff Kinz) Date: Wed, 1 Oct 2008 10:17:20 -0400 Subject: Go daddy mail services admin In-Reply-To: <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> Message-ID: <20081001141720.GA15221@redline.kinz.org> On Tue, Sep 30, 2008 at 07:21:52AM -0600, Blake Pfankuch wrote: > Amazingly its not a route problem. Its actually confirmed an issue > with the mail server. Hense me asking for a mail services admin. The > issue is confirmed from 3 locations with 3 different ISP's and I do > actually know whats going on. I can connect to the server, but it > will not allow me to send messages, even when authenticated. Returns > a 554. It has been doing this with legitimate mail. They do not have > the ability to send outbound as they get a 554 from their home office. > The secondary smtp server links me to spamhaus saying that it will not > allow relay based on an existing PBL entry. The PBL entry is because > it's a residential DHCP connection, and the PBL entry was put in place > by the isp. Please see http://www.spamhaus.org/pbl/query/PBL191963 if > you have questions. > > So. Again. Looking for a GoDaddy Mail services Admin. Hi Blake - With Godaddy The 554 code is a tipoff. Does the error also contain the text: SMTP error from remote mail server after end of data: host smtp.where.secureserver.net [xx.xx.xx.xx]: 554 The message was rejected because it contains prohibited virus or spam content GoDaddy has an unusual policy of rejecting any email that mentions anything that resolves to an IP address on the PBL list Note this means any text string with the email body itself, not the originating IP of the email. Any text, a URL or a even a dotted quad that resolves to the PBL list will cause the email to blocked. By way of example, this policy blocks emails from amazon ec2 merchants even if the email only mentions a web site hosted at ec2, and the email itself is from a static web server with proper MX records. They have been contacted multiple times over the years about this issue and refuse to change their policy. The PBL list explicitly describes how to use their list and this way of using it is incorrect. The PBL list is supposed to be used to check the IP address of the system actually delivering the email to your server, not the contents of the email. Based on their long term refusal to adjust their policy to conform to PBL intended usage of the list I suspect this issue cannot be corrected. The only answer I have found is to inform the affected people they have to move from GoDaddy to a company that does a better job to correct the problem. If this is NOT the issue creating your problem, then you may be able to get GoDaddy to do something to help. Good luck. Jeff Kinz. From beckman at angryox.com Wed Oct 1 09:31:31 2008 From: beckman at angryox.com (Peter Beckman) Date: Wed, 1 Oct 2008 10:31:31 -0400 Subject: Go daddy mail services admin In-Reply-To: <20081001141720.GA15221@redline.kinz.org> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> <20081001141720.GA15221@redline.kinz.org> Message-ID: On Wed, 1 Oct 2008, Jeff Kinz wrote: > GoDaddy has an unusual policy of rejecting any email that mentions > anything that resolves to an IP address on the PBL list Why doesn't someone at Spamhaus block godaddy requests for the PBL, until they get their act together? If they are using the PBL inappropriately, or outside the terms and conditions set forth by Spamhaus fur use of the PBL, then Spamhaus has full control here. I'm sure goDaddy is paying Spamhaus for access to the PBL, so it might be problematic, but I think Spamhaus should have a policy that if someone is misusing the PBL, the PBL will be blocked until the PBL is being properly implemented. Get it together, Spamhaus, help us out. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From mhuff at ox.com Wed Oct 1 09:34:13 2008 From: mhuff at ox.com (Matthew Huff) Date: Wed, 1 Oct 2008 10:34:13 -0400 Subject: Go daddy mail services admin In-Reply-To: <20081001141720.GA15221@redline.kinz.org> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> <20081001141720.GA15221@redline.kinz.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F9142D5A8632@PUR-EXCH07.ox.com> We encountered some mail systems where they checked each hop in the received list and if each and every one could not be reverse resolved, the mail would bounce. And even if they resolved, they were checked against the PBL. We had to add some internal mail servers to our external dns because of this. I would have preferred just to let the mail bounce, but since they were customers, we had to bend. Designing a mail system that paranoid is certainly up to individual sites, but they shouldn't be surprised when legitimate mail bounces. Even if you are doing this, it should be to setup a score and mark the header, rather than bouncing. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Jeff Kinz [mailto:jkinz at kinz.org] Sent: Wednesday, October 01, 2008 10:17 AM To: Blake Pfankuch Cc: nanog at nanog.org Subject: Re: Go daddy mail services admin On Tue, Sep 30, 2008 at 07:21:52AM -0600, Blake Pfankuch wrote: > Amazingly its not a route problem. Its actually confirmed an issue > with the mail server. Hense me asking for a mail services admin. The > issue is confirmed from 3 locations with 3 different ISP's and I do > actually know whats going on. I can connect to the server, but it > will not allow me to send messages, even when authenticated. Returns > a 554. It has been doing this with legitimate mail. They do not have > the ability to send outbound as they get a 554 from their home office. > The secondary smtp server links me to spamhaus saying that it will not > allow relay based on an existing PBL entry. The PBL entry is because > it's a residential DHCP connection, and the PBL entry was put in place > by the isp. Please see http://www.spamhaus.org/pbl/query/PBL191963 if > you have questions. > > So. Again. Looking for a GoDaddy Mail services Admin. Hi Blake - With Godaddy The 554 code is a tipoff. Does the error also contain the text: SMTP error from remote mail server after end of data: host smtp.where.secureserver.net [xx.xx.xx.xx]: 554 The message was rejected because it contains prohibited virus or spam content GoDaddy has an unusual policy of rejecting any email that mentions anything that resolves to an IP address on the PBL list Note this means any text string with the email body itself, not the originating IP of the email. Any text, a URL or a even a dotted quad that resolves to the PBL list will cause the email to blocked. By way of example, this policy blocks emails from amazon ec2 merchants even if the email only mentions a web site hosted at ec2, and the email itself is from a static web server with proper MX records. They have been contacted multiple times over the years about this issue and refuse to change their policy. The PBL list explicitly describes how to use their list and this way of using it is incorrect. The PBL list is supposed to be used to check the IP address of the system actually delivering the email to your server, not the contents of the email. Based on their long term refusal to adjust their policy to conform to PBL intended usage of the list I suspect this issue cannot be corrected. The only answer I have found is to inform the affected people they have to move from GoDaddy to a company that does a better job to correct the problem. If this is NOT the issue creating your problem, then you may be able to get GoDaddy to do something to help. Good luck. Jeff Kinz. From sethm at rollernet.us Wed Oct 1 11:48:09 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 01 Oct 2008 09:48:09 -0700 Subject: Go daddy mail services admin In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> <20081001141720.GA15221@redline.kinz.org> Message-ID: <48E3A9C9.8010108@rollernet.us> Peter Beckman wrote: > On Wed, 1 Oct 2008, Jeff Kinz wrote: > >> GoDaddy has an unusual policy of rejecting any email that mentions >> anything that resolves to an IP address on the PBL list > > Why doesn't someone at Spamhaus block godaddy requests for the PBL, until > they get their act together? If they are using the PBL inappropriately, > or outside the terms and conditions set forth by Spamhaus fur use of the > PBL, then Spamhaus has full control here. > > I'm sure goDaddy is paying Spamhaus for access to the PBL, so it might be > problematic, but I think Spamhaus should have a policy that if someone is > misusing the PBL, the PBL will be blocked until the PBL is being properly > implemented. > > Get it together, Spamhaus, help us out. > If I use the PBL (or any other list) to stupidly block on my own customers, why should spamhaus care? I'm sure they have better things to do that babysit people who may or not be using it inappropriately (for whoever decides to define "inappropriate"). ~Seth From patrick at ianai.net Wed Oct 1 12:52:54 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 1 Oct 2008 13:52:54 -0400 Subject: Google's PUE Message-ID: [#include: boiler-plate apology for operational content] Google has released its PUE numbers: There is a nice explanation of this, including a graph showing why DC efficiency is more important than machine efficiency (on the second page) at this link: I think GOOG deserves a hearty "well done" for getting a whole DC under 1.2 PUE for a whole year. (Actually, I think they deserve a "HOLY @#$@, NO @*&@#-ing WAY!!!") Personally, I think only a self-owned DC could get that low. A general purpose DC would have too many inefficiencies since someone like Equinix must have randomly sized cages, routers and servers, custom-built suites, etc. By owning both sides, GOOG gets a boost. But it's still frickin' amazing, IMHO. For their next miracle, I expect GOOG to capture the waste heat from all their servers and co-gen more electricity to pump back into the servers. :-) -- TTFN, patrick From Martin.Hannigan at verneglobal.com Wed Oct 1 13:04:44 2008 From: Martin.Hannigan at verneglobal.com (Martin Hannigan) Date: Wed, 1 Oct 2008 18:04:44 -0000 Subject: Google's PUE In-Reply-To: References: Message-ID: > Personally, I think only a self-owned DC could get that low. A > general purpose DC would have too many inefficiencies since someone > like Equinix must have randomly sized cages, routers and servers, > custom-built suites, etc. By owning both sides, GOOG gets a boost. > But it's still frickin' amazing, IMHO. > I wonder what it cost? :-) -M< From patrick at ianai.net Wed Oct 1 13:21:40 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 1 Oct 2008 14:21:40 -0400 Subject: Google's PUE In-Reply-To: References: Message-ID: <3F80A263-492A-47D7-8C69-C7797FB5EFFF@ianai.net> On Oct 1, 2008, at 2:04 PM, Martin Hannigan wrote: >> Personally, I think only a self-owned DC could get that low. A >> general purpose DC would have too many inefficiencies since someone >> like Equinix must have randomly sized cages, routers and servers, >> custom-built suites, etc. By owning both sides, GOOG gets a boost. >> But it's still frickin' amazing, IMHO. > > I wonder what it cost? :-) What cost to the environment of not doing it? OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious savings from this over time. If they weren't why would they do it? -- TTFN, patrick From repstein at chello.at Wed Oct 1 13:54:23 2008 From: repstein at chello.at (Randy Epstein) Date: Wed, 1 Oct 2008 14:54:23 -0400 Subject: once again, network hardware vendors spamming... In-Reply-To: <9D2F7191-F08B-4C74-81D9-D3CD32AFB6C7@multicasttech.com> References: <86r678uis2.fsf@seastrom.com> <9D2F7191-F08B-4C74-81D9-D3CD32AFB6C7@multicasttech.com> Message-ID: All, I just crushed John's foot accidently with my chair, so he wants to know if we're even? Randy -----Original Message----- From: Marshall Eubanks [mailto:tme at multicasttech.com] Sent: Friday, September 26, 2008 7:48 AM To: Robert E. Seastrom Cc: nanog at nanog.org Subject: Re: once again, network hardware vendors spamming... Dear Robert; I feel that this is not appropriate for this list. Anyone on this list might have valid or nefarious reasons to wish to DOS someone else. This list is not an appropriate means of organizing that. I have not received such mail. I have no way of verifying whether or not you have. I don't know J.L. and don't even see him as a contributor to this list. Now, I know you, but there are way too many people on this list to know them all, or for them to all know you (or me, or anyone else). And, email addresses can be spoofed. And, not everyone reads NANOG faithfully all the time, so a spoof might not be detected for some time. I think you can see the potential for mischief here. Regards Marshall On Sep 25, 2008, at 3:28 PM, Robert E. Seastrom wrote: > > Anyone else gotten mail from John Lucania at atlantixglobal.com today? > > He lists his phone numbers as: > > 770.582.7248 Direct > and > 404.287.2603 Cell > > Why not give him a ring (preferably on his cell phone, maybe tonight?) > and tell him what you think of spammers? :-) > > -r > > From ml at t-b-o-h.net Wed Oct 1 14:06:19 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 1 Oct 2008 15:06:19 -0400 (EDT) Subject: Google's PUE In-Reply-To: <3F80A263-492A-47D7-8C69-C7797FB5EFFF@ianai.net> Message-ID: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> > > On Oct 1, 2008, at 2:04 PM, Martin Hannigan wrote: > > >> Personally, I think only a self-owned DC could get that low. A > >> general purpose DC would have too many inefficiencies since someone > >> like Equinix must have randomly sized cages, routers and servers, > >> custom-built suites, etc. By owning both sides, GOOG gets a boost. > >> But it's still frickin' amazing, IMHO. > > > > I wonder what it cost? :-) > > What cost to the environment of not doing it? > > OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious > savings from this over time. If they weren't why would they do it? > They seem to be very environment focused, so I'm sure doing anything that isn't is subject to scrutiny from the rest of the industry. Hopefully it won't come around to bite them. I had read an article on "The Planet" going as green as possible, then they had the huge outage and I'm sure negated 2-3 times what they had done to that point. Tuc/TBOH From bpfankuch at cpgreeley.com Wed Oct 1 14:13:27 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 1 Oct 2008 13:13:27 -0600 Subject: Go daddy mail services admin In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9142D5A8632@PUR-EXCH07.ox.com> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> <20081001141720.GA15221@redline.kinz.org> <483E6B0272B0284BA86D7596C40D29F9142D5A8632@PUR-EXCH07.ox.com> Message-ID: <01759D50DC387C45A018FE1817CE27D751CBA4C66F@CPExchange1.cpgreeley.com> Thank you all for your help. The issue is now resolved, in an ass backwards sort of way. We purchased a VPS and set up a smtp proxy on an obscure port and mail is now being processed..... -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Wednesday, October 01, 2008 8:34 AM To: 'Jeff Kinz'; Blake Pfankuch Cc: 'nanog at nanog.org' Subject: RE: Go daddy mail services admin We encountered some mail systems where they checked each hop in the received list and if each and every one could not be reverse resolved, the mail would bounce. And even if they resolved, they were checked against the PBL. We had to add some internal mail servers to our external dns because of this. I would have preferred just to let the mail bounce, but since they were customers, we had to bend. Designing a mail system that paranoid is certainly up to individual sites, but they shouldn't be surprised when legitimate mail bounces. Even if you are doing this, it should be to setup a score and mark the header, rather than bouncing. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Jeff Kinz [mailto:jkinz at kinz.org] Sent: Wednesday, October 01, 2008 10:17 AM To: Blake Pfankuch Cc: nanog at nanog.org Subject: Re: Go daddy mail services admin On Tue, Sep 30, 2008 at 07:21:52AM -0600, Blake Pfankuch wrote: > Amazingly its not a route problem. Its actually confirmed an issue > with the mail server. Hense me asking for a mail services admin. The > issue is confirmed from 3 locations with 3 different ISP's and I do > actually know whats going on. I can connect to the server, but it > will not allow me to send messages, even when authenticated. Returns > a 554. It has been doing this with legitimate mail. They do not have > the ability to send outbound as they get a 554 from their home office. > The secondary smtp server links me to spamhaus saying that it will not > allow relay based on an existing PBL entry. The PBL entry is because > it's a residential DHCP connection, and the PBL entry was put in place > by the isp. Please see http://www.spamhaus.org/pbl/query/PBL191963 if > you have questions. > > So. Again. Looking for a GoDaddy Mail services Admin. Hi Blake - With Godaddy The 554 code is a tipoff. Does the error also contain the text: SMTP error from remote mail server after end of data: host smtp.where.secureserver.net [xx.xx.xx.xx]: 554 The message was rejected because it contains prohibited virus or spam content GoDaddy has an unusual policy of rejecting any email that mentions anything that resolves to an IP address on the PBL list Note this means any text string with the email body itself, not the originating IP of the email. Any text, a URL or a even a dotted quad that resolves to the PBL list will cause the email to blocked. By way of example, this policy blocks emails from amazon ec2 merchants even if the email only mentions a web site hosted at ec2, and the email itself is from a static web server with proper MX records. They have been contacted multiple times over the years about this issue and refuse to change their policy. The PBL list explicitly describes how to use their list and this way of using it is incorrect. The PBL list is supposed to be used to check the IP address of the system actually delivering the email to your server, not the contents of the email. Based on their long term refusal to adjust their policy to conform to PBL intended usage of the list I suspect this issue cannot be corrected. The only answer I have found is to inform the affected people they have to move from GoDaddy to a company that does a better job to correct the problem. If this is NOT the issue creating your problem, then you may be able to get GoDaddy to do something to help. Good luck. Jeff Kinz. From deepak at ai.net Wed Oct 1 15:06:05 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 01 Oct 2008 16:06:05 -0400 Subject: Google's PUE In-Reply-To: <3F80A263-492A-47D7-8C69-C7797FB5EFFF@ianai.net> References: <3F80A263-492A-47D7-8C69-C7797FB5EFFF@ianai.net> Message-ID: <48E3D82D.1090700@ai.net> Patrick W. Gilmore wrote: > On Oct 1, 2008, at 2:04 PM, Martin Hannigan wrote: > >>> Personally, I think only a self-owned DC could get that low. A >>> general purpose DC would have too many inefficiencies since someone >>> like Equinix must have randomly sized cages, routers and servers, >>> custom-built suites, etc. By owning both sides, GOOG gets a boost. >>> But it's still frickin' amazing, IMHO. >> >> I wonder what it cost? :-) > > What cost to the environment of not doing it? > > OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious > savings from this over time. If they weren't why would they do it? > Not talking down this PR release.... Without comparing locations, sizes of floor plates, etc. I am sure Google has more than A-F, so one has to wonder which data centers they left off the map. I think I can submit without proof that a PUE of 1.2 is far more impressive in New Mexico or Arizona than it is in Vancouver, BC since you are essentially measuring the energy to keep the datacenter at temperature throughout seasonal (or external) ambient heat deltas. Likewise, a 10,000 sq ft single customer DC is far less impressive than a 200,000 sq ft general purpose (colo) DC. (they say large scale -- is that number of cores, or sq ft?, but I don't have a number for that). And to address Patrick's rhetorical question - if it costs you $400MM (like a datacenter proposed underground in Japan) to save $15MM / yr in energy costs, one could easily argue that the environment "savings" is not sufficient to overcome the upfront investment. If you spent $40MM in trees (instead of $400MM on an investment to save $15MM/yr), you could argue the environment would be far better off. Deepak From Skywing at valhallalegends.com Wed Oct 1 15:12:27 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 1 Oct 2008 15:12:27 -0500 Subject: Google's PUE Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D731E@caralain.haven.nynaeve.net> Maybe, but I suspect that it is more complex than that. Most of the real environmental costs are still externalized in today's day and age. - S -----Original Message----- From: Deepak Jain Sent: Wednesday, October 01, 2008 15:08 To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Google's PUE Patrick W. Gilmore wrote: > On Oct 1, 2008, at 2:04 PM, Martin Hannigan wrote: > >>> Personally, I think only a self-owned DC could get that low. A >>> general purpose DC would have too many inefficiencies since someone >>> like Equinix must have randomly sized cages, routers and servers, >>> custom-built suites, etc. By owning both sides, GOOG gets a boost. >>> But it's still frickin' amazing, IMHO. >> >> I wonder what it cost? :-) > > What cost to the environment of not doing it? > > OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious > savings from this over time. If they weren't why would they do it? > Not talking down this PR release.... Without comparing locations, sizes of floor plates, etc. I am sure Google has more than A-F, so one has to wonder which data centers they left off the map. I think I can submit without proof that a PUE of 1.2 is far more impressive in New Mexico or Arizona than it is in Vancouver, BC since you are essentially measuring the energy to keep the datacenter at temperature throughout seasonal (or external) ambient heat deltas. Likewise, a 10,000 sq ft single customer DC is far less impressive than a 200,000 sq ft general purpose (colo) DC. (they say large scale -- is that number of cores, or sq ft?, but I don't have a number for that). And to address Patrick's rhetorical question - if it costs you $400MM (like a datacenter proposed underground in Japan) to save $15MM / yr in energy costs, one could easily argue that the environment "savings" is not sufficient to overcome the upfront investment. If you spent $40MM in trees (instead of $400MM on an investment to save $15MM/yr), you could argue the environment would be far better off. Deepak From jlewis at lewis.org Wed Oct 1 15:18:16 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 1 Oct 2008 16:18:16 -0400 (EDT) Subject: Google's PUE In-Reply-To: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> Message-ID: On Wed, 1 Oct 2008, Tuc at T-B-O-H.NET wrote: >> OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious >> savings from this over time. If they weren't why would they do it? >> > They seem to be very environment focused, so I'm sure doing > anything that isn't is subject to scrutiny from the rest of the industry. Personal 747, cough, cough... I'd bet at their scale, they're saving tens if not hundreds of thousands of dollars a month on their data center power bills by optimizing power efficiency. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dean at av8.com Wed Oct 1 15:32:45 2008 From: dean at av8.com (Dean Anderson) Date: Wed, 1 Oct 2008 16:32:45 -0400 (EDT) Subject: once again, network hardware vendors spamming... In-Reply-To: <200809261531.m8QFVjHx055092@aurora.sol.net> Message-ID: The size of a mailing list can be judged from its participants over a long time, and from meeting attendence records. Every participant in a list eventually sends at least one message to a mailing list. Those who don't ever send a message are just monitoring the list; those people aren't participants. >From the meeting records and about 10 years of mailing list archives, I count about 600 active participants in NANOG, with about 200 core members who continue year after year, while the remainder of participants will quit participating. NANOG doesn't report the size of its mailing list, but does report its meeting attendance and its budget. NANOG spends about $180,000 per year; $50,000 of this appears to come from ARIN [improperly--the transfer violates ARIN 501(c6) tax status, and was approved by NANOG-affiliated Board members with undisclosed conflict of interest in the transaction]. However, this amount does not represent the budget of a very large organization. Considering that there are about 3000 members of ARIN, and many more ISP like organizations that don't have their own direct allocations, or who are legacy block owners (which aren't ARIN members automatically); considering that even limited to just the North American region of ARIN, there are tens, perhaps hundreds of thousands of ISP operations employees; NANOG represents a very, very few. But the core 200 members are unusually influential, and this is a matter of some interest. --Dean On Fri, 26 Sep 2008, Joe Greco wrote: > > Now, I know you, but there are way too many people on this list to > > know them all, or for them to all know you (or me, or anyone else). > > This caused me to go "aha" and I counted up unique accesses to the URL > of the rack diagram I posted yesterday, and came up with 185. > > Assuming that most people aren't using clients that automatically display > URL's in non-HTML e-mail, and that power strip configurations within a > rack is a topic of interest to a small subset of subscribers, it seems > apparent that there are probably thousands of people reading NANOG traffic > on at least a daily basis. > > It is often easy to forget how many people you're sending to when you're > sending to a mailing list. > > ... JG > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dga at cs.cmu.edu Wed Oct 1 15:48:32 2008 From: dga at cs.cmu.edu (David Andersen) Date: Wed, 1 Oct 2008 16:48:32 -0400 Subject: Google's PUE In-Reply-To: References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> Message-ID: On Oct 1, 2008, at 4:18 PM, Jon Lewis wrote: > On Wed, 1 Oct 2008, Tuc at T-B-O-H.NET wrote: > >>> OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious >>> savings from this over time. If they weren't why would they do it? >>> >> They seem to be very environment focused, so I'm sure doing >> anything that isn't is subject to scrutiny from the rest of the >> industry. > > Personal 747, cough, cough... > > I'd bet at their scale, they're saving tens if not hundreds of > thousands of dollars a month on their data center power bills by > optimizing power efficiency. I think you're being overly conservative. ~500,000 computers. (cough; estimate as of 2006) [1] ~150W per computer (google's are supposedly pretty efficient, this number may be high). that's about 75 megawatts. = 657,000,000 kWh/year (if they're all turned on all the time, which recent articles suggest is probably the case [2]). $65M per year @ $0.10 per kWh. (possibly an over-estimate with datacenters located near hydropower dams). If the average datacenter has a PUE of ~1.9 and google's are at 1.2, that suggests that they're saving something on the order of $10-20M per year with power efficiency efforts. Over a million bucks per month. Not bad. This seems to mesh with the non-scientific, vague claim in the PUE document that "we save hundreds of millions of kWhs of electricity" and "cut our operating expenses by tens of millions of dollars." There's serious money in improving server efficiency. Green feathers in the cap, green in the hand... -Dave [1] http://www.nytimes.com/2006/06/14/technology/14search.html?pagewanted=2&ei=5088&en=c96a72bbc5f90a47&ex=1307937600&partner=rssnyt&emc=rss [2] http://news.cnet.com/8301-11128_3-9975495-54.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From alex at corp.nac.net Wed Oct 1 16:04:23 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 1 Oct 2008 17:04:23 -0400 Subject: Google's PUE In-Reply-To: References: Message-ID: I only quickly read this, but have the following question, should google like to answer it... Of the six datacenters, where are they all physically located? Someone should get on the bandwagon of having a PUE standard that is climate based. A PUE of 1.3 in the Caribbean is way impressive than 1.3 in Quebec. And, why the hell do people use PUE rather than DCIE? DCIE makes more sense. A PUE of 1.15 is DCIE of .86, which is somewhat easier to quantify in ones mind. Translation would be, "for every 100 watts into a site, 86 goes to the critical load." I'd be interested to hear what economization methods they use. And, while they touch on how the water evaporates to cool their datacenters (a la cooling towers), they neglect to tell us how much water is consumed and evaporated (in a heated form) in to the atmosphere. Don't take this as an attack on Google, but there is a lot more to a datacenter efficiency analysis than simple stating your PUE and some other data. For instance, if you have a higher PUE but consume no water, are you more eco-friendly? What about airside vs. waterside economization? Is a higher PUE acceptable if the power generation source is photovoltaic or wind (rather than coal or gas)? Do they do ice storage? If they are they using river water, what does heating that water affect? It's a good topic to talk about (and something I believe NANOG should focus on), but I'd love to see more nuts and bolts in the data from Google. > Google has released its PUE numbers: > > From davidb at pins.net Wed Oct 1 14:26:48 2008 From: davidb at pins.net (David Birnbaum) Date: Wed, 01 Oct 2008 15:26:48 -0400 Subject: Google's PUE In-Reply-To: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <48E3CEF8.2050402@pins.net> I can't comment on the cost to a large data center, but I just finished renovating our small data center here in New York City by putting in a cogeneration system. We installed a natural gas microturbine, and are recapturing the waste heat to drive an absorption chiller. The rough rule of thumb is 30KW = 10T of chilling. This type of cogeneration is a great match for a communications room because the load is relatively stable, and it supports a dual-mode operation, grid-connect and grid-standalone, allowing you to run completely detached from local utility in the event of an electrical disturbance. No more recip generator backup. As we were the first to do this in New York City, a lot of the cost and delay in the project came in explaining to the city what a microturbine was, how it was going to work, demonstrating to the fire department that it was safer than 500 gallons of diesel on the roof of a mid-rise, etc. The math on the cost savings if you factor in the turbine equipment is pretty quick, a couple of years, but if you look at the cost of the entire project, 10 years is optimistic. However, unlike a traditional backup, you at least /have/ some sort of cost savings to offset the cap investment. I am going to attempt to determine our PUE, using the methodology described in the Google paper. One must figure that "in the spirit it was intended" has to factor in the natural gas consumption, otherwise my PUE would be about 0.1. :) Cheers, David. ------------------------------------------------------------------------ Tuc at T-B-O-H.NET wrote: >> On Oct 1, 2008, at 2:04 PM, Martin Hannigan wrote: >> >> >>>> Personally, I think only a self-owned DC could get that low. A >>>> general purpose DC would have too many inefficiencies since someone >>>> like Equinix must have randomly sized cages, routers and servers, >>>> custom-built suites, etc. By owning both sides, GOOG gets a boost. >>>> But it's still frickin' amazing, IMHO. >>>> >>> I wonder what it cost? :-) >>> >> What cost to the environment of not doing it? >> >> OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious >> savings from this over time. If they weren't why would they do it? >> >> > They seem to be very environment focused, so I'm sure doing > anything that isn't is subject to scrutiny from the rest of the industry. > > Hopefully it won't come around to bite them. I had read an > article on "The Planet" going as green as possible, then they had the > huge outage and I'm sure negated 2-3 times what they had done to that > point. > > Tuc/TBOH > > From deepak at ai.net Wed Oct 1 16:44:49 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 01 Oct 2008 17:44:49 -0400 Subject: Google's PUE In-Reply-To: <48E3CEF8.2050402@pins.net> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> <48E3CEF8.2050402@pins.net> Message-ID: <48E3EF51.9050708@ai.net> > > I am going to attempt to determine our PUE, using the methodology > described in the Google paper. One must figure that "in the spirit it > was intended" has to factor in the natural gas consumption, otherwise my > PUE would be about 0.1. :) > If you generate energy for your microturbine from a land fill (free methane gas) your PUE would be nearly zero. Obviously PUE can be skewed and shouldn't be considered as a single metric for anything other than a press release. I would also suggest that Alex shouldn't hold is breath on more details. The details provided are interesting, but without context. (Its like: "Hi, we filter our river water to evaporate it." But are they calculating the cost of all that contaminated material and its disposal? The blowdown on their cooling towers would have to be many times more hazardous than normal, and may require additional treatment to make it safe to release). Is any math being done to decide whether free river/water-side economization is more important (financially/environmentally) than cheap energy inputs? If rather than density, we REDUCE density and build very large foot print data centers that can use ambient air (I've heard rumors that MSFT is using 85 degree air [cool side] in New Mexico) we could get to PUE numbers that were nearly ideal (hot air rises, natural convection, no fans, just PDU overhead, etc). Except where it impacts the bottom line, this all seems more like a fashion show than an actual business plan. Deepak Jain From jeffshultz at wvi.com Wed Oct 1 16:56:23 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 01 Oct 2008 14:56:23 -0700 Subject: Google's PUE In-Reply-To: References: Message-ID: <48E3F207.3020205@wvi.com> Alex Rubenstein wrote: > I only quickly read this, but have the following question, should google > like to answer it... > > Of the six datacenters, where are they all physically located? > Based on their job openings at least three are located in Mountain View, CA; The Dalles, OR; and Atlanta, GA. -- Jeff Shultz From tme at multicasttech.com Wed Oct 1 17:10:37 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 1 Oct 2008 18:10:37 -0400 Subject: Google's PUE In-Reply-To: <48E3EF51.9050708@ai.net> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> <48E3CEF8.2050402@pins.net> <48E3EF51.9050708@ai.net> Message-ID: <8EA2777A-90D2-4BAA-9582-AE657342B219@multicasttech.com> On Oct 1, 2008, at 5:44 PM, Deepak Jain wrote: > >> I am going to attempt to determine our PUE, using the methodology >> described in the Google paper. One must figure that "in the spirit >> it was intended" has to factor in the natural gas consumption, >> otherwise my PUE would be about 0.1. :) > > If you generate energy for your microturbine from a land fill (free > methane gas) your PUE would be nearly zero. Obviously PUE can be > skewed and shouldn't be considered as a single metric for anything > other than a press release. > > I would also suggest that Alex shouldn't hold is breath on more > details. The details provided are interesting, but without context. Indeed. If they would refuse a visit to Cory Doctorow writing for Nature, I don't think we should hold our breath at all : http://www.nature.com/news/2008/080903/full/455016a.html " It doesn't disclose the dimensions or capacity of those data centres. Nature wanted me to visit one for this piece, but a highly placed Googler told me that no one from the press had ever been admitted to a Google data centre; it would require a decision taken at the board level. Which is too bad." Regards Marshall > > > (Its like: > > "Hi, we filter our river water to evaporate it." But are they > calculating the cost of all that contaminated material and its > disposal? The blowdown on their cooling towers would have to be many > times more hazardous than normal, and may require additional > treatment to make it safe to release). > > Is any math being done to decide whether free river/water-side > economization is more important (financially/environmentally) than > cheap energy inputs? > > If rather than density, we REDUCE density and build very large foot > print data centers that can use ambient air (I've heard rumors that > MSFT is using 85 degree air [cool side] in New Mexico) we could get > to PUE numbers that were nearly ideal (hot air rises, natural > convection, no fans, just PDU overhead, etc). > > Except where it impacts the bottom line, this all seems more like a > fashion show than an actual business plan. > > Deepak Jain > From jfmezei at vaxination.ca Wed Oct 1 17:11:03 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Wed, 01 Oct 2008 18:11:03 -0400 Subject: Google's PUE In-Reply-To: <48E3EF51.9050708@ai.net> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> <48E3CEF8.2050402@pins.net> <48E3EF51.9050708@ai.net> Message-ID: <48E3F577.4050308@vaxination.ca> Google not counting electricity losses from power cords etc gives the image that it doesn't really want to account everything and want to skew the numbers as much as possible. I would be far more interested in a metric that shows the amount of power used for each MIPS of CPU power (or whatever CPU horsepower metric other than clock speed). And also amount of power used for each gbps of telecom capacity USED. Another metric would be how much power is used to store how many terabytes of data on disk. Disks consume much power too. In the case of Google, the amount of data they spit out to the internet would be a good metric of how much work is being done. So how much power is consumed per gigabyte of data spitted out to the internet would be a good metric of how efficient the data centre is. But for a bank, this would not be a good metric since a lot fo the work doesn't involve sending much data in/out. (because much of the work of a transaction involves a lot of validation/logging) To me, it seems that PUE is just a metric of how efficient the air conditioning is. Not really how energy efficient the whole data centre is for how much work it does. From alex at corp.nac.net Wed Oct 1 17:22:19 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 1 Oct 2008 18:22:19 -0400 Subject: Google's PUE In-Reply-To: <48E3F577.4050308@vaxination.ca> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> <48E3CEF8.2050402@pins.net><48E3EF51.9050708@ai.net> <48E3F577.4050308@vaxination.ca> Message-ID: > Google not counting electricity losses from power cords etc gives the > image that it doesn't really want to account everything and want to > skew the numbers as much as possible. I don't agree with this. It is commonly accepted that when computing DCIE/PUE, the point of "demarcation" (used that term for the telco crowd) is the receptacle. If they did not include losses in transformation, UPS, distribution, etc., then I would agree. But they seem clear about that in the discussion. > I would be far more interested in a metric that shows the amount of > power used for each MIPS of CPU power (or whatever CPU horsepower > metric other than clock speed). And also amount of power used for each gbps of > telecom capacity USED. > > Another metric would be how much power is used to store how many > terabytes of data on disk. Disks consume much power too. I think you mean "energy", not telecom. While what you ask for is very important, that is generally a function of efficiency of a piece of equipment closed to the consumer. In other words, how efficient a Dell is vs. a HP or something. These things do not relate to the definition of PUE/DCIE. > To me, it seems that PUE is just a metric of how efficient the air > conditioning is. This is the point. It's a metric of the FACILITY, not the COMPUTATION. From pauldotwall at gmail.com Wed Oct 1 17:22:31 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 1 Oct 2008 18:22:31 -0400 Subject: paix palo attitude In-Reply-To: <48E2579F.4020808@psg.com> References: <48E2579F.4020808@psg.com> Message-ID: <620fd17c0810011522y13cc5f40ke165e329482285ac@mail.gmail.com> IIJ had some empty space when I was there the other day, you should ask them for a feed and some Us. :) Seriously though, is the requirement to be physically plugged into the fabric an important one? Might some ebgp multihop feeds to a remote route collector suffice? Drive Slow, Paul Wall On Tue, Sep 30, 2008 at 12:45 PM, Randy Bush wrote: > we're looking at dropping 2/3 of a rack of routing research measurement > kit into paix palo alto, and have some questions. considering the price > of space and power, we want to kinda make sure we'll get the data we need. > > we are looking specifically for a large amount of bgp peering data, we > hope that folk will give us bgp peering though we expect no in- or > out-bound traffic. think analogously to route views, though the kit on > our end will be grinding the beans much more finely, espressoBGP :). > > pnis are expensive. if we plug into the peering mesh, are any larger > folk on it? > > if not, would we be better off at the linx, at de-cix, at amsix, in > stockholm? > > private replies are probably better as this is not of general interest. > thanks. > > randy > > From intercage.blows at gmail.com Wed Oct 1 20:27:10 2008 From: intercage.blows at gmail.com (intercage blows) Date: Wed, 1 Oct 2008 21:27:10 -0400 Subject: Hey ISC, thanks for providing free wifi to intercage! Message-ID: * RussM (~RussM at 204.152.185.ba4c5ba0) has joined #dronebl * RussM *pokes* nenolod * RussM says, is IT alive? possibly. why are you at ISC? nenolod: You ask no such questions! :P are you there to punch Paul Vixie out? lol if so, knock him out once for BIND9 nenolod: If he ever tried to talk the shit he has to my face, surely then when he wakes up nenolod: But I've never seen him here knock him out again for DHCPD LOL ISC: making my life hell daily nenolod: ISC has a few racks and a cage on the other side of the wall from one of my cages (I'm at my desk) lol nenolod: So I'm using their wireless since my wireless is dead lol thanks esthost * RussM has quit (Quit: Leaving) From ge at linuxbox.org Wed Oct 1 20:52:14 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 1 Oct 2008 20:52:14 -0500 (CDT) Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: Message-ID: I do believe the wireless is provided for 200 Paul and everyone hosted there. But if gloating in an inflamatory fashion ... oh, fake email address. What a surprise. Gadi. On Wed, 1 Oct 2008, intercage blows wrote: > * RussM (~RussM at 204.152.185.ba4c5ba0) has joined #dronebl > * RussM *pokes* nenolod > * RussM says, is IT alive? > possibly. > why are you at ISC? > nenolod: You ask no such questions! > :P > are you there to punch Paul Vixie out? > lol > if so, knock him out once for BIND9 > nenolod: If he ever tried to talk the shit he has to my face, surely > then when he wakes up > nenolod: But I've never seen him here > knock him out again for DHCPD > LOL > ISC: making my life hell daily > nenolod: ISC has a few racks and a cage on the other side of the > wall from one of my cages (I'm at my desk) > lol > nenolod: So I'm using their wireless since my wireless is dead > lol > thanks esthost > * RussM has quit (Quit: Leaving) > From randy at psg.com Wed Oct 1 21:10:18 2008 From: randy at psg.com (Randy Bush) Date: Wed, 01 Oct 2008 22:10:18 -0400 Subject: paix palo attitude In-Reply-To: <620fd17c0810011522y13cc5f40ke165e329482285ac@mail.gmail.com> References: <48E2579F.4020808@psg.com> <620fd17c0810011522y13cc5f40ke165e329482285ac@mail.gmail.com> Message-ID: <48E42D8A.1020305@psg.com> > Seriously though, is the requirement to be physically plugged into the > fabric an important one? Might some ebgp multihop feeds to a remote > route collector suffice? no. if that would do, we would put it somewhere much easier. randy From nenolod at systeminplace.net Wed Oct 1 21:19:41 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 01 Oct 2008 21:19:41 -0500 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: Message-ID: <1222913981.20200.1789.camel@petrie.sacredspiral.co.uk> This sort of garbage (e.g. posting IRC logs to NANOG) really isn't helpful. Yay for the shit-infested drama trap that is NANOG. Whoever you are, grow the fuck up. - nenolod On Wed, 2008-10-01 at 21:27 -0400, intercage blows wrote: > * RussM (~RussM at 204.152.185.ba4c5ba0) has joined #dronebl > * RussM *pokes* nenolod > * RussM says, is IT alive? > possibly. > why are you at ISC? > nenolod: You ask no such questions! > :P > are you there to punch Paul Vixie out? > lol > if so, knock him out once for BIND9 > nenolod: If he ever tried to talk the shit he has to my face, surely > then when he wakes up > nenolod: But I've never seen him here > knock him out again for DHCPD > LOL > ISC: making my life hell daily > nenolod: ISC has a few racks and a cage on the other side of the > wall from one of my cages (I'm at my desk) > lol > nenolod: So I'm using their wireless since my wireless is dead > lol > thanks esthost > * RussM has quit (Quit: Leaving) From noel.butler at ausics.net Wed Oct 1 22:25:51 2008 From: noel.butler at ausics.net (Noel Butler) Date: Thu, 02 Oct 2008 13:25:51 +1000 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: Message-ID: <1222917950.7331.8.camel@roswell.ausics.net> On Thu, 2008-10-02 at 11:52, Gadi Evron wrote: > I do believe the wireless is provided for 200 Paul and everyone hosted > there. But if gloating in an inflamatory fashion ... oh, fake email > address. What a surprise. > They wouldn't have the guts to post under their real name, remember, IRC is for the gutless keyboard commandos...and for posting IRC logs on mailing lists, is it school holidays over there or something, must be. > Gadi. > > > On Wed, 1 Oct 2008, intercage blows wrote: > > * RussM (~RussM at 204.152.185.ba4c5ba0) has joined #dronebl > > * RussM *pokes* nenolod > > * RussM says, is IT alive? > > possibly. > > why are you at ISC? > > nenolod: You ask no such questions! > > :P > > are you there to punch Paul Vixie out? > > lol > > if so, knock him out once for BIND9 > > nenolod: If he ever tried to talk the shit he has to my face, surely > > then when he wakes up > > nenolod: But I've never seen him here > > knock him out again for DHCPD > > LOL > > ISC: making my life hell daily > > nenolod: ISC has a few racks and a cage on the other side of the > > wall from one of my cages (I'm at my desk) > > lol > > nenolod: So I'm using their wireless since my wireless is dead > > lol > > thanks esthost > > * RussM has quit (Quit: Leaving) > > From hobbit at avian.org Wed Oct 1 21:16:25 2008 From: hobbit at avian.org (*Hobbit*) Date: Thu, 2 Oct 2008 02:16:25 +0000 (GMT) Subject: Hey ISC, thanks for providing free wifi to intercage! Message-ID: <20081002021625.0E7597808@relayer.avian.org> see, *this* is why google needs to WAKE UP and start putting real headers in their gmail spew. _H* From ops.lists at gmail.com Wed Oct 1 22:36:10 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 2 Oct 2008 09:06:10 +0530 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <1222917950.7331.8.camel@roswell.ausics.net> References: <1222917950.7331.8.camel@roswell.ausics.net> Message-ID: On Thu, Oct 2, 2008 at 8:55 AM, Noel Butler wrote: > They wouldn't have the guts to post under their real name, remember, IRC > is for the gutless keyboard commandos...and for posting IRC logs on > mailing lists, is it school holidays over there or something, must be. Well .. one of the parties to that conversation seems to have posted about it to nanog, upthread, under his real name .. >> > are you there to punch Paul Vixie out? srs From nenolod at systeminplace.net Wed Oct 1 23:05:09 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 01 Oct 2008 23:05:09 -0500 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: <1222917950.7331.8.camel@roswell.ausics.net> Message-ID: <1222920309.20200.1795.camel@petrie.sacredspiral.co.uk> Hi, On Thu, 2008-10-02 at 09:06 +0530, Suresh Ramasubramanian wrote: > On Thu, Oct 2, 2008 at 8:55 AM, Noel Butler wrote: > > They wouldn't have the guts to post under their real name, remember, IRC > > is for the gutless keyboard commandos...and for posting IRC logs on > > mailing lists, is it school holidays over there or something, must be. > > Well .. one of the parties to that conversation seems to have posted > about it to nanog, upthread, under his real name .. > > >> > are you there to punch Paul Vixie out? > > srs > Furthermore I know who leaked the logs now. Annoying, that. He said he was "searching for the lolz." (Please note that I do not actually have anything against Paul Vixie, I was just busy dealing with trying to get this dynamic RDNS stuff with dhcp3+bind9 going, and it wasn't going so well at the time...) William From morrowc.lists at gmail.com Wed Oct 1 23:27:34 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Oct 2008 00:27:34 -0400 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <1222920309.20200.1795.camel@petrie.sacredspiral.co.uk> References: <1222917950.7331.8.camel@roswell.ausics.net> <1222920309.20200.1795.camel@petrie.sacredspiral.co.uk> Message-ID: <75cb24520810012127ydde09d9xb112b9434ba38e02@mail.gmail.com> could we all let this thread skate off into memory-land now? It's not productive nor operationally focused. thanks, citizen-chris On Thu, Oct 2, 2008 at 12:05 AM, William Pitcock wrote: > Hi, From karnaugh at karnaugh.za.net Wed Oct 1 23:42:47 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 02 Oct 2008 06:42:47 +0200 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <1222917950.7331.8.camel@roswell.ausics.net> References: <1222917950.7331.8.camel@roswell.ausics.net> Message-ID: <48E45147.1050904@karnaugh.za.net> On 2008/10/02 05:25 AM Noel Butler wrote: > They wouldn't have the guts to post under their real name, remember, IRC > is for the gutless keyboard commandos... What a stupid generalisation From darkuncle at gmail.com Thu Oct 2 00:49:10 2008 From: darkuncle at gmail.com (Scott Francis) Date: Wed, 1 Oct 2008 22:49:10 -0700 Subject: remembering Jon Postel: Looking Beyond the Decade Message-ID: <171423de0810012249n4d1f8edem745db7445c1b73c7@mail.gmail.com> nice writeup by Mr. Cerf: http://www.circleid.com/posts/20081001_remembering_jon_postel_a_decade/ I was not fortunate enough to have known Mr. Postel, but I have developed a deep posthumous respect for the work he did from listening to what others have had to say about him, and from using (and benefiting from) his legacy on a daily basis. He was not alone among the pioneers who enabled the Internet to become what it is today, but there weren't many who made such a significant contribution. thanks for the writeup, Vint. -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From pfs at cisco.com Thu Oct 2 02:07:09 2008 From: pfs at cisco.com (Philip Smith) Date: Thu, 02 Oct 2008 17:07:09 +1000 Subject: [NANOG-announce] Election reminder - charter amendments Message-ID: <48E4731D.8060104@cisco.com> Hello everyone, Please take a moment to look at the current charter amendment proposals for the October ballot at: http://www.nanog.org/charter/ If you have comments on the proposals, please post them on the nanog-futures list or send them to steering at nanog.org in the next few days. The Steering Committee plans to vote on the final wording for the ballot during its next meeting on Tuesday, October 7th. Many thanks, philip (for the Steering Committee) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From william.allen.simpson at gmail.com Thu Oct 2 05:18:39 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 02 Oct 2008 06:18:39 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: References: <20081001084756.GA56410@revolt.com> Message-ID: <48E49FFF.7010208@gmail.com> Suresh Ramasubramanian wrote: > On Wed, Oct 1, 2008 at 2:17 PM, chris neill wrote: >> Give me a break. You're telling me the White House's mail servers are even >> on the same network as their web servers? What, is this 1997? >> > > Well, I do know that there's two ways you can contact your congressman - > > * Feedback forms on individual websites > * Email > Chris: The "House" is the House of Representatives; see also the "Senate", the other branch of Congress. The "White House" is the place the President of the Executive branch lives. One of its wings has executive offices in it.... As it is obvious, the various servers are not on the same network, as they are controlled by different branches (that don't trust each other). Suresh: AFAICT, the www.house.gov stuff is Akamaized. At least in the days I was hanging around there, all the email was sent via a centralized system for the House. Even the web forms were actually sent via that system. Some years ago, I caused considerable consternation bypassing that system with a VPN for my Member, as the system was controlled by Republicans, and it was apparent that they were snooping on the Democrats. I don't know how it's setup these days. Democrats have only been in control since early 2007, and it has changed considerably. I'll note that the house.gov SOA still lists mail.house.gov, but there's no A record. The clerk and primary DNS systems seem to be 143.231.x.x/16, with diverse paths. The secondary NS is on 143.228.x.x/16, so it seems to be reasonably well done. From ops.lists at gmail.com Thu Oct 2 07:29:56 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 2 Oct 2008 17:59:56 +0530 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <48E49FFF.7010208@gmail.com> References: <20081001084756.GA56410@revolt.com> <48E49FFF.7010208@gmail.com> Message-ID: On Thu, Oct 2, 2008 at 3:48 PM, William Allen Simpson wrote: > The clerk and primary DNS systems seem to be 143.231.x.x/16, with diverse > paths. The secondary NS is on 143.228.x.x/16, so it seems to be > reasonably well done. Not talking about network redundancy here .. but I have a feeling they use what would effectively be a typical corporate MTA / groupware. Not something that's ISP class and capable of truly heavy loads. srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From LarrySheldon at cox.net Thu Oct 2 07:47:19 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 02 Oct 2008 07:47:19 -0500 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <1222917950.7331.8.camel@roswell.ausics.net> References: <1222917950.7331.8.camel@roswell.ausics.net> Message-ID: <48E4C2D7.9050905@cox.net> Noel Butler wrote: [nothing worth having been forwarded several times] I'm sure I'll get a nastygram from the kabal for this, but just out of curiosity, why is talking about broken network protocols and other stuff "off topic", but talking mindlessly and endlessly about mindless and pointless drivel (quoting the whole history of the thread with each entry , top posting to remove whatever residual content there might have been) is not? From jabley at hopcount.ca Thu Oct 2 08:02:08 2008 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 2 Oct 2008 09:02:08 -0400 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <48E4C2D7.9050905@cox.net> References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> Message-ID: On 2 Oct 2008, at 08:47, Laurence F. Sheldon, Jr. wrote: > I'm sure I'll get a nastygram from the kabal for this, but just out > of curiosity, why is talking about broken network protocols and > other stuff "off topic", but talking mindlessly and endlessly about > mindless and pointless drivel (quoting the whole history of the > thread with each entry , top posting to remove whatever residual > content there might have been) is not? How about moving the meta-nanog themes in this thread to nanog- futures, instead of adding to the noise on the main list? Joe (meta-meta-nanog theme, guilty as charged) From LarrySheldon at cox.net Thu Oct 2 08:33:57 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 02 Oct 2008 08:33:57 -0500 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> Message-ID: <48E4CDC5.8030505@cox.net> Joe Abley wrote: > How about moving the meta-nanog themes in this thread to nanog-futures, > instead of adding to the noise on the main list? Because nobody reads it? From hobbit at avian.org Thu Oct 2 07:45:18 2008 From: hobbit at avian.org (*Hobbit*) Date: Thu, 2 Oct 2008 12:45:18 +0000 (GMT) Subject: Hey ISC, thanks for providing free wifi to intercage! Message-ID: <20081002124518.D45927809@relayer.avian.org> ... instead of adding to the noise on the main list? Because it's people on the main list that are causing the quoting problem, and need to have it held in their faces far more often than it is. I completely agree with LarrySheldon here and I see the same crap in countless other mailing lists, and it still astounds me that people I thought were intelligent and list-etiquette-aware can become so complacent about stuff like this. F'krissake it generally takes ONE KEYSTROKE to remove all the quoted content from a reply composition in most mail software, there's absolutely NO excuse. [That's your "select all" shortcut used before typing, in case you're wondering.] I would argue that this is not a meta-issue, it points out a central, fundamental flaw in daily practice among people who claim to be proponents of efficient use of bandwidth and resources. THINK ABOUT IT. _H* From patrick at ianai.net Thu Oct 2 09:06:59 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 2 Oct 2008 10:06:59 -0400 Subject: Reading NANOG-Futures [was: Hey ISC, thanks for providing free wifi to intercage!] In-Reply-To: <48E4CDC5.8030505@cox.net> References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> <48E4CDC5.8030505@cox.net> Message-ID: <697D97FA-7EC2-4519-9B45-97BCC60CF43C@ianai.net> On Oct 2, 2008, at 9:33 AM, Laurence F. Sheldon, Jr. wrote: > Joe Abley wrote: > >> How about moving the meta-nanog themes in this thread to nanog- >> futures, instead of adding to the noise on the main list? > > Because nobody reads it? I've been called a lot of things, but I can't seem to remember being called "nobody" before. And there are lots of people who post there. While I agree it could be argued some have clearly not read the thread into which they are posting, some must be reading it, even if just by accident. -- TTFN, patrick From shrdlu at deaddrop.org Thu Oct 2 09:08:55 2008 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Thu, 02 Oct 2008 07:08:55 -0700 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <48E4CDC5.8030505@cox.net> References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> <48E4CDC5.8030505@cox.net> Message-ID: <48E4D5F7.1040607@deaddrop.org> Laurence F. Sheldon, Jr. wrote: > Joe Abley wrote: > >> How about moving the meta-nanog themes in this thread to >> nanog-futures, instead of adding to the noise on the main list? > Because nobody reads it? You are mistaken, sir. There are plenty that read it, and meta discussions belong there. -- If it is a Miracle, any sort of evidence will answer, but if it is a Fact, proof is necessary. Samuel Clemens From andy at sugar.meniscus.org Thu Oct 2 09:26:58 2008 From: andy at sugar.meniscus.org (Andy Grosser) Date: Thu, 2 Oct 2008 10:26:58 -0400 (EDT) Subject: Google's PUE In-Reply-To: <8EA2777A-90D2-4BAA-9582-AE657342B219@multicasttech.com> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> <48E3CEF8.2050402@pins.net> <48E3EF51.9050708@ai.net> <8EA2777A-90D2-4BAA-9582-AE657342B219@multicasttech.com> Message-ID: On Wed, 1 Oct 2008, Marshall Eubanks wrote: > Date: Wed, 1 Oct 2008 18:10:37 -0400 > From: Marshall Eubanks > To: deepak at ai.net > Cc: NANOG list > Subject: Re: Google's PUE >> >>> I am going to attempt to determine our PUE, using the methodology >>> described in the Google paper. One must figure that "in the spirit it was >>> intended" has to factor in the natural gas consumption, otherwise my PUE >>> would be about 0.1. :) >> >> If you generate energy for your microturbine from a land fill (free methane >> gas) your PUE would be nearly zero. Obviously PUE can be skewed and >> shouldn't be considered as a single metric for anything other than a press >> release. >> >> I would also suggest that Alex shouldn't hold is breath on more details. >> The details provided are interesting, but without context. > > Indeed. If they would refuse a visit to Cory Doctorow writing for Nature, I > don't think we should hold our breath at > all : > > http://www.nature.com/news/2008/080903/full/455016a.html Ack! US$32 for the article. :-) --- Andy Grosser andy [at] meniscus {dot} org --- From michael.dillon at bt.com Thu Oct 2 09:40:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 2 Oct 2008 15:40:40 +0100 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <48E4CDC5.8030505@cox.net> Message-ID: > > How about moving the meta-nanog themes in this thread to > > nanog-futures, instead of adding to the noise on the main list? > > Because nobody reads it? Try "because nobody knows that NANOG has a website where you can simple instructions to subscribe to Nanog-futures". For the record, there is a simple form to fill in on this page which will add you to the "other" NANOG list. --Michael Dillon From yahoo at jimpop.com Thu Oct 2 10:36:50 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 2 Oct 2008 11:36:50 -0400 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: <48E4CDC5.8030505@cox.net> Message-ID: <7ff145960810020836g355491doe854c5b9d6223cbc@mail.gmail.com> On Thu, Oct 2, 2008 at 10:40, wrote: >> > How about moving the meta-nanog themes in this thread to >> > nanog-futures, instead of adding to the noise on the main list? >> >> Because nobody reads it? > > Try "because nobody knows that NANOG has a website where you can > simple instructions to subscribe to Nanog-futures". Does it really qualify as a "futures" item? Larry's point seems more for the present than for the future. -Jim P. From jsdy at center.osis.gov Thu Oct 2 10:54:26 2008 From: jsdy at center.osis.gov (Joseph S D Yao) Date: Thu, 2 Oct 2008 11:54:26 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: References: Message-ID: <20081002155426.GM10127@core.center.osis.gov> On Wed, Oct 01, 2008 at 12:41:12AM -0400, Ernie Rubi wrote: > Hi folks, just musing... > > From an ops perspective, wonder just how much traffic caused: > > "This morning, our engineers sounded the alarms ... and we have > installed a digital version of a traffic cop. We enacted stopgaps that > we planned for last night. We had hoped we didn't have to." > --Jeff Ventura, communications director for the House's chief > administrator. (from > http://www.cnn.com/2008/POLITICS/09/30/congress.website/index.html) > > Don't .govs have enough b/w or at least ability to add b/w in order to > satisfy their 'public outreach/information' role? (not a rhetorical > question...hehe) What makes you thing that .gov's "have" anything at all? They have to buy any bandwidth they have (other than strictly internal bandwidth) from ISP's. If the IT budget doesn't allow for it, the IT department can't buy it. If the projected need is much lower than this surge, then they would not have budgeted for it. The USGOV, contrary to some folks' belief, does not own the Internet. Some ISP's are able to quickly add bandwidth if the line is set up for it, but I think the IT department would have had to have an existing active relationship with the ISP to be able to know whom to ask. -- Joe Yao Qinetiq NA / Analex Contractor From bergmanm at imsg.com Thu Oct 2 11:39:19 2008 From: bergmanm at imsg.com (Mick Bergman) Date: Thu, 2 Oct 2008 12:39:19 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <20081002155426.GM10127@core.center.osis.gov> References: <20081002155426.GM10127@core.center.osis.gov> Message-ID: <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> Are you saying that the house.gov site is not in a large data center with direct fiber connectivity along with many of the other large federal web sites (with alternative hot sites ready to go at a moment's notice, of course)? As someone who has been to different government data centers, I can tell you they have huge amounts of data connectivity there in case of emergency. For a large site like house.gov, bandwidth should never be an issue. In this case I highly doubt it was the issue, but instead overloading of the hardware in place. Just my $.02... Mick -----Original Message----- From: Joseph S D Yao [mailto:jsdy at center.osis.gov] Sent: Thursday, October 02, 2008 11:54 AM To: Ernie Rubi Cc: nanog at nanog.org Subject: Re: 143.228.0.0/16 and house.gov What makes you thing that .gov's "have" anything at all? They have to buy any bandwidth they have (other than strictly internal bandwidth) from ISP's. If the IT budget doesn't allow for it, the IT department can't buy it. If the projected need is much lower than this surge, then they would not have budgeted for it. The USGOV, contrary to some folks' belief, does not own the Internet. Some ISP's are able to quickly add bandwidth if the line is set up for it, but I think the IT department would have had to have an existing active relationship with the ISP to be able to know whom to ask. -- Joe Yao Qinetiq NA / Analex Contractor From braaen at zcorum.com Thu Oct 2 12:38:37 2008 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 2 Oct 2008 13:38:37 -0400 Subject: Google's PUE In-Reply-To: References: Message-ID: <200810021338.38238.braaen@zcorum.com> The datacenter in Atlanta is located in Suwanee which is north of Atlanta. The Building is operated by Quality Technology Services (www.qualitytech.com). I know since they occupy half of the building. ---------------------- Brian Raaen Network Engineer On Wednesday 01 October 2008, Alex Rubenstein wrote: > I only quickly read this, but have the following question, should google > like to answer it... > > Of the six datacenters, where are they all physically located? > > Someone should get on the bandwagon of having a PUE standard that is > climate based. A PUE of 1.3 in the Caribbean is way impressive than 1.3 > in Quebec. > > And, why the hell do people use PUE rather than DCIE? DCIE makes more > sense. A PUE of 1.15 is DCIE of .86, which is somewhat easier to > quantify in ones mind. Translation would be, "for every 100 watts into a > site, 86 goes to the critical load." > > I'd be interested to hear what economization methods they use. > > And, while they touch on how the water evaporates to cool their > datacenters (a la cooling towers), they neglect to tell us how much > water is consumed and evaporated (in a heated form) in to the > atmosphere. > > Don't take this as an attack on Google, but there is a lot more to a > datacenter efficiency analysis than simple stating your PUE and some > other data. For instance, if you have a higher PUE but consume no water, > are you more eco-friendly? What about airside vs. waterside > economization? Is a higher PUE acceptable if the power generation source > is photovoltaic or wind (rather than coal or gas)? Do they do ice > storage? If they are they using river water, what does heating that > water affect? > > It's a good topic to talk about (and something I believe NANOG should > focus on), but I'd love to see more nuts and bolts in the data from > Google. > > > > > Google has released its PUE numbers: > > > > > > > From rjoffe at centergate.com Thu Oct 2 12:45:44 2008 From: rjoffe at centergate.com (Rodney Joffe) Date: Thu, 2 Oct 2008 10:45:44 -0700 Subject: remembering Jon Postel: Looking Beyond the Decade In-Reply-To: <171423de0810012249n4d1f8edem745db7445c1b73c7@mail.gmail.com> References: <171423de0810012249n4d1f8edem745db7445c1b73c7@mail.gmail.com> Message-ID: <7632CBE0-ECB7-4364-8903-8D7E902687D5@centergate.com> On Oct 1, 2008, at 10:49 PM, Scott Francis wrote: > nice writeup by Mr. Cerf: > http://www.circleid.com/posts/ > 20081001_remembering_jon_postel_a_decade/ > > I was not fortunate enough to have known Mr. Postel, but I have > developed a deep posthumous respect for the work he did from listening > to what others have had to say about him, and from using (and > benefiting from) his legacy on a daily basis. He was not alone among > the pioneers who enabled the Internet to become what it is today, but > there weren't many who made such a significant contribution. You may want to then consider coming to the next NANOG being held in just under two weeks time in Los Angeles (http://www.nanog.org/). This NANOG celebrates Jon's contributions on the 10th Anniversary of his passing (Oct 16) and includes a rare keynote opening speech by Vint Cerf, as well as a 90 minute panel of folks who were "there" when some important decisions were made, and who will share with us the reasons some of those decisions were made. Panelists like Paul Mockapetris who invented the DNS, Bob Braden who has taken care of much of Jon's role as RFC editor since Jon left us, Danny Cohen who Jon worked for, and who also worked for Jon ;-) at ISI in the '70s, Bob Hinden who was the ietf's first Area Director for routing, Lixia Zhang who was part of a small group of 6 including Jon who tackled the issues of addressing for the iab/iesg, and Van Jacobson, who you probably know mostly for his congestion control work, but who Paul Francis "credits" for the concept of NAT. Of course these folks had many other key contributions to "the Internets". Besides these official speakers at NANOG 44 you'll also get to meet in person many of Jon's peers and friends from the early days. I hesitate to name any, but if you listen carefully in the hallways, and for comments from the audience during this NANOG, you'll pick up on them. If you want to get to know more about some of the people who really gave us the opportunity to do the things we do today, this is probably the NANOG you want to attend. BTW, it is a joint meeting with ARIN, so you get a two'fer. ""be conservative in what you do, be liberal in what you accept from others" - Postel's Law From schnizlein at isoc.org Thu Oct 2 12:49:48 2008 From: schnizlein at isoc.org (John Schnizlein) Date: Thu, 2 Oct 2008 13:49:48 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> References: <20081002155426.GM10127@core.center.osis.gov> <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> Message-ID: <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> Is this really technical discussion of operation of networks? I connected the internal network of the US House of Representatives to the Internet when I worked there, and operated it through both Democratic and Republican control. I never saw any snooping by either party of the network traffic, and I had sniffers for diagnosing problems in several communication closets. I do recall unfounded accusations both ways, but it would be sad for the rumors to outlive the reality. The notorious case of intercepted cell-phone conversations had nothing to do with the data network. Not only is the data center, but so are all the committee and member offices that want it connected. Skilled professionals operate the House's network. There has been a collegial relationship among the operators of both the Senate and House networks, as well as the rest of the Legislative branch. There are good reasons, including Constitutional separation of powers, that the Legislative Branch is not managed by the Executive Branch. The independence of the two houses of Congress is more a matter of tradition, and the fact that a different party sometimes controls the other house. Bandwidth has ALWAYS been an issue because Internet access is acquired through normal business processes, and the appetite for bandwidth both to Congressional staff, and (occasionally - when something important happens) to the public. Since the source of money for these operations is Federal taxes, many readers of this list might appreciate that we have not bought more than we could justify. I will not say anything about how large or redundant the data center is for obvious reasons, beyond that I am no longer employed there and do not have the details. I really think this thread has outlived its entertainment value. John On 2008Oct2, at 12:39 PM, Mick Bergman wrote: > Are you saying that the house.gov site is not in a large data center > with direct fiber connectivity along with many of the other large > federal web sites (with alternative hot sites ready to go at a > moment's > notice, of course)? As someone who has been to different government > data > centers, I can tell you they have huge amounts of data connectivity > there in case of emergency. > > For a large site like house.gov, bandwidth should never be an issue. > In > this case I highly doubt it was the issue, but instead overloading of > the hardware in place. > > Just my $.02... From vixie at isc.org Thu Oct 2 13:15:52 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 02 Oct 2008 18:15:52 +0000 Subject: Wall it off, make it go away In-Reply-To: (michael dillon's message of "Thu\, 25 Sep 2008 15\:20\:22 +0100") References: Message-ID: writes: >> let's push this stuff back into the nation-states who sponsor >> it and then use treaties to wall it off inside those places. > > Let's not mince words. You want to wall off the Chinese and Russian > Internets because you believe that the reason so much cybercrime > originates there is for political reasons (state sponsorship) rather > than economic ones. ... No. That's not what I want and that's not what I believe. -- Paul Vixie From tvarriale at comcast.net Thu Oct 2 13:40:06 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 2 Oct 2008 13:40:06 -0500 Subject: remembering Jon Postel: Looking Beyond the Decade References: <171423de0810012249n4d1f8edem745db7445c1b73c7@mail.gmail.com> <7632CBE0-ECB7-4364-8903-8D7E902687D5@centergate.com> Message-ID: <004c01c924be$4ab6cd10$0100fea9@flamadam> Any chance this will be captured (maybe professionally via HD:)? Unfortunately I cannot be there but would really appreciate being in the audience. tv ----- Original Message ----- From: "Rodney Joffe" To: "Scott Francis" Cc: "NANOG list" Sent: Thursday, October 02, 2008 12:45 PM Subject: Re: remembering Jon Postel: Looking Beyond the Decade > > On Oct 1, 2008, at 10:49 PM, Scott Francis wrote: > >> nice writeup by Mr. Cerf: >> http://www.circleid.com/posts/ 20081001_remembering_jon_postel_a_decade/ >> >> I was not fortunate enough to have known Mr. Postel, but I have >> developed a deep posthumous respect for the work he did from listening >> to what others have had to say about him, and from using (and >> benefiting from) his legacy on a daily basis. He was not alone among >> the pioneers who enabled the Internet to become what it is today, but >> there weren't many who made such a significant contribution. > > You may want to then consider coming to the next NANOG being held in just > under two weeks time in Los Angeles (http://www.nanog.org/). This NANOG > celebrates Jon's contributions on the 10th Anniversary of his passing > (Oct 16) and includes a rare keynote opening speech by Vint Cerf, as well > as a 90 minute panel of folks who were "there" when some important > decisions were made, and who will share with us the reasons some of those > decisions were made. Panelists like Paul Mockapetris who invented the > DNS, Bob Braden who has taken care of much of Jon's role as RFC editor > since Jon left us, Danny Cohen who Jon worked for, and who also worked > for Jon ;-) at ISI in the '70s, Bob Hinden who was the ietf's first Area > Director for routing, Lixia Zhang who was part of a small group of 6 > including Jon who tackled the issues of addressing for the iab/iesg, and > Van Jacobson, who you probably know mostly for his congestion control > work, but who Paul Francis "credits" for the concept of NAT. Of course > these folks had many other key contributions to "the Internets". > > Besides these official speakers at NANOG 44 you'll also get to meet in > person many of Jon's peers and friends from the early days. I hesitate to > name any, but if you listen carefully in the hallways, and for comments > from the audience during this NANOG, you'll pick up on them. > > If you want to get to know more about some of the people who really gave > us the opportunity to do the things we do today, this is probably the > NANOG you want to attend. BTW, it is a joint meeting with ARIN, so you > get a two'fer. > > ""be conservative in what you do, be liberal in what you accept from > others" - Postel's Law > From tim at yocum.org Thu Oct 2 13:53:37 2008 From: tim at yocum.org (Tim Yocum) Date: Thu, 2 Oct 2008 13:53:37 -0500 Subject: remembering Jon Postel: Looking Beyond the Decade In-Reply-To: <004c01c924be$4ab6cd10$0100fea9@flamadam> References: <171423de0810012249n4d1f8edem745db7445c1b73c7@mail.gmail.com> <7632CBE0-ECB7-4364-8903-8D7E902687D5@centergate.com> <004c01c924be$4ab6cd10$0100fea9@flamadam> Message-ID: <14b99b330810021153u7e8afef3hc3cd6c324163ba6c@mail.gmail.com> On Thu, Oct 2, 2008 at 1:40 PM, Tony Varriale wrote: > Any chance this will be captured (maybe professionally via HD:)? > Unfortunately I cannot be there but would really appreciate being in the > audience. Check www.nanog.org for details surrounding the streams that are available throughout the conference. While they won't cover the hallways and secluded bar-room corners where a lot of interesting discussion seems to sprout up, you'll be able to follow along with the session talks. - Tim > tv From dgolding at t1r.com Thu Oct 2 14:15:29 2008 From: dgolding at t1r.com (Daniel Golding) Date: Thu, 2 Oct 2008 15:15:29 -0400 Subject: Google's PUE In-Reply-To: References: Message-ID: I am really skeptical of this, Patrick. PUE's of between 1.2 and 1.3 - sure. But below 1.2 on an annual basis? And its not even their newest facility. Color me skeptical. - Dan On Oct 1, 2008, at 1:52 PM, Patrick W. Gilmore wrote: > [#include: boiler-plate apology for operational content] > > Google has released its PUE numbers: > > > > There is a nice explanation of this, including a graph showing why > DC efficiency is more important than machine efficiency (on the > second page) at this link: > > > > > I think GOOG deserves a hearty "well done" for getting a whole DC > under 1.2 PUE for a whole year. (Actually, I think they deserve a > "HOLY @#$@, NO @*&@#-ing WAY!!!") > > Personally, I think only a self-owned DC could get that low. A > general purpose DC would have too many inefficiencies since someone > like Equinix must have randomly sized cages, routers and servers, > custom-built suites, etc. By owning both sides, GOOG gets a boost. > But it's still frickin' amazing, IMHO. > > For their next miracle, I expect GOOG to capture the waste heat from > all their servers and co-gen more electricity to pump back into the > servers. :-) > > -- > TTFN, > patrick > > From dgolding at t1r.com Thu Oct 2 14:17:02 2008 From: dgolding at t1r.com (Daniel Golding) Date: Thu, 2 Oct 2008 15:17:02 -0400 Subject: Google's PUE In-Reply-To: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> References: <200810011906.m91J6JZk037578@himinbjorg.tucs-beachin-obx-house.com> Message-ID: On Oct 1, 2008, at 3:06 PM, Tuc at T-B-O-H.NET wrote: >> >> On Oct 1, 2008, at 2:04 PM, Martin Hannigan wrote: >> >>>> Personally, I think only a self-owned DC could get that low. A >>>> general purpose DC would have too many inefficiencies since someone >>>> like Equinix must have randomly sized cages, routers and servers, >>>> custom-built suites, etc. By owning both sides, GOOG gets a boost. >>>> But it's still frickin' amazing, IMHO. >>> >>> I wonder what it cost? :-) >> >> What cost to the environment of not doing it? >> >> OK, green hat off. :) Seriously, I doubt GOOG isn't seeing serious >> savings from this over time. If they weren't why would they do it? >> > They seem to be very environment focused, so I'm sure doing > anything that isn't is subject to scrutiny from the rest of the > industry. > > Hopefully it won't come around to bite them. I had read an > article on "The Planet" going as green as possible, then they had the > huge outage and I'm sure negated 2-3 times what they had done to that > point. > > Tuc/TBOH > The Planet had an outage because something blew up and the fire department made them shut everything down. I wouldn't assume any sort of linkage between efficient design and power savings, except that one way to get very efficient design is to remove redundant components. I don't think Google, or the Planet, or anyone else is doing that, though. From virendra.rode at gmail.com Thu Oct 2 14:26:53 2008 From: virendra.rode at gmail.com (virendra rode) Date: Thu, 02 Oct 2008 12:26:53 -0700 Subject: Outages BOF - NANOG 44 (los angeles). Message-ID: <48E5207D.7090507@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Just wondering if there's any interest in meeting up during nanog 44 (los angeles) and sharing your thoughts, challenges or your outages experience in general or would like to simply vent and empty your head. Topics of interest: * Service provider(s) participation in outages notification? * What monitoring tools do you use to monitor your environment? How do they work for your environment? Does it scale for your environment? What would you like to see out of such a tool (open-source or commercial). Collaboration/participation is one of the key things that I'm aiming to achieve w/o the need for an overarching organizational body and have a broad base of representation. So come and speak your mind. Please respond to me directly and not the list so I can arrange for a meeting room. grateful thanks, regards, /virendra moderator, outages.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5SB9pbZvCIJx1bcRApU5AJ916/9T3+k0swPIyFMQfEJBWLNAmQCgoyDo KD7qhBFmjfcrmSJTXhDmJtk= =641j -----END PGP SIGNATURE----- From patrick at ianai.net Thu Oct 2 14:30:26 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 2 Oct 2008 15:30:26 -0400 Subject: Google's PUE In-Reply-To: References: Message-ID: <816E66A0-4654-4BB1-B39C-08ABFA80272B@ianai.net> On Oct 2, 2008, at 3:15 PM, Daniel Golding wrote: > I am really skeptical of this, Patrick. PUE's of between 1.2 and 1.3 > - sure. But below 1.2 on an annual basis? And its not even their > newest facility. Color me skeptical. I said "NO @*&@#-ing WAY!!!". :) Just presenting info. If someone has more detailed information, or a rebuttal, I bet the collected audience would love to hear it. Personally, I am glad GOOG is posting their PUE. People who talk about additional metrics are correct - more information is better. But some information is better than none, and PUE is a perfectly valid data point. It doesn't measure everything, but that does not make it completely useless. Given Google's history of .. shall we say reticence regarding internal information, it's nice to see SOMETHING from them. So let's encourage it and see if they release more. -- TTFN, patrick > On Oct 1, 2008, at 1:52 PM, Patrick W. Gilmore wrote: > >> [#include: boiler-plate apology for operational content] >> >> Google has released its PUE numbers: >> >> >> >> There is a nice explanation of this, including a graph showing why >> DC efficiency is more important than machine efficiency (on the >> second page) at this link: >> >> > > >> >> I think GOOG deserves a hearty "well done" for getting a whole DC >> under 1.2 PUE for a whole year. (Actually, I think they deserve a >> "HOLY @#$@, NO @*&@#-ing WAY!!!") >> >> Personally, I think only a self-owned DC could get that low. A >> general purpose DC would have too many inefficiencies since someone >> like Equinix must have randomly sized cages, routers and servers, >> custom-built suites, etc. By owning both sides, GOOG gets a >> boost. But it's still frickin' amazing, IMHO. >> >> For their next miracle, I expect GOOG to capture the waste heat >> from all their servers and co-gen more electricity to pump back >> into the servers. :-) >> >> -- >> TTFN, >> patrick >> >> > From KKomar at IdahoAGC.org Thu Oct 2 14:30:35 2008 From: KKomar at IdahoAGC.org (KKomar at IdahoAGC.org) Date: Thu, 2 Oct 2008 13:30:35 -0600 Subject: how to unsubscribe In-Reply-To: <48E5207D.7090507@gmail.com> References: <48E5207D.7090507@gmail.com> Message-ID: How do you unsubscribe from the list? When I go to the nanog site, log in and hit "unsubscribe" but it never sends me the email to confirm... What am I doing wrong? From adam.young at mountaincable.on.ca Thu Oct 2 14:37:03 2008 From: adam.young at mountaincable.on.ca (Adam Young) Date: Thu, 02 Oct 2008 15:37:03 -0400 Subject: how to unsubscribe In-Reply-To: References: <48E5207D.7090507@gmail.com> Message-ID: <48E522DF.9080506@mountaincable.on.ca> KKomar at IdahoAGC.org wrote: > How do you unsubscribe from the list? > When I go to the nanog site, log in and hit "unsubscribe" but it never sends me the email to confirm... > What am I doing wrong? > As per the headers generated in the mailing list manager: List-Unsubscribe: , Thanks, -- Adam Young Senior Data Management Specialist Mountain Cablevision Ltd. http://www.mountaincable.net/ From yahoo at jimpop.com Thu Oct 2 14:38:24 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 2 Oct 2008 15:38:24 -0400 Subject: how to unsubscribe In-Reply-To: References: <48E5207D.7090507@gmail.com> Message-ID: <7ff145960810021238j2200a013xb33ff101015d2a65@mail.gmail.com> It's in the email headers of every recent email from NANOG. ;-) List-Unsubscribe: , hth, -Jim P. On Thu, Oct 2, 2008 at 15:30, wrote: > How do you unsubscribe from the list? > When I go to the nanog site, log in and hit "unsubscribe" but it never sends me the email to confirm... > What am I doing wrong? > > From ren.provo at gmail.com Thu Oct 2 15:07:23 2008 From: ren.provo at gmail.com (Ren Provo) Date: Thu, 2 Oct 2008 16:07:23 -0400 Subject: Outages BOF - NANOG 44 (los angeles). In-Reply-To: <48E5207D.7090507@gmail.com> References: <48E5207D.7090507@gmail.com> Message-ID: <787581440810021307g5d705fbbh8a812adaf5644014@mail.gmail.com> Hi Virendra, Putting my NANOG Program Committee Member hat on, please work with Joel Jaeggli, also on the NANOG PC. He is moderating a Tools BOF Monday afternoon at 4:30 in the Heinsbergen Room as per http://www.nanog.org/meetings/nanog44/agenda.php If you are interested in leading an outages specific BOF please put in a request at http://www.nanogpc.org for NANOG45. January 2009 will be here before you know it! Cheers, -ren On Thu, Oct 2, 2008 at 3:26 PM, virendra rode wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Just wondering if there's any interest in meeting up during nanog 44 > (los angeles) and sharing your thoughts, challenges or your outages > experience in general or would like to simply vent and empty your head. > > > Topics of interest: > > * Service provider(s) participation in outages notification? > > * What monitoring tools do you use to monitor your environment? How do > they work for your environment? Does it scale for your environment? What > would you like to see out of such a tool (open-source or commercial). > > Collaboration/participation is one of the key things that I'm aiming to > achieve w/o the need for an overarching organizational body and have a > broad base of representation. So come and speak your mind. > > > Please respond to me directly and not the list so I can arrange for a > meeting room. > > > grateful thanks, > > > regards, > /virendra > moderator, outages.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFI5SB9pbZvCIJx1bcRApU5AJ916/9T3+k0swPIyFMQfEJBWLNAmQCgoyDo > KD7qhBFmjfcrmSJTXhDmJtk= > =641j > -----END PGP SIGNATURE----- > > From william.allen.simpson at gmail.com Thu Oct 2 15:08:46 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 02 Oct 2008 16:08:46 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> References: <20081002155426.GM10127@core.center.osis.gov> <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> Message-ID: <48E52A4E.7020209@gmail.com> John Schnizlein wrote: > I connected the internal network of the US House of Representatives to > the Internet when I worked there, and operated it through both > Democratic and Republican control. Aha, I wondered who was to blame.... Of course, my Member was on the Internet before the House, as MERIT -- the very same organization that ran/runs NANOG -- had its own POP (called an SCP in those days) in DC. Only later did we use the House net. She usually took her Mac laptop to Science and Education committee meetings. Her staff was often asked how they got her to use her own laptop, when they couldn't get their own members to read (or type) their own email. This was all pre-2001, and Blackberry mania. > I never saw any snooping by either > party of the network traffic, and I had sniffers for diagnosing problems > in several communication closets. Yet, there was verified interception of both House and Senate email communications. Nobody claimed it was "on the wire" network traffic, as there were many weaknesses in the data network security design. And the vicious fight about our setting up a VPN to bypass the centrally controlled system -- as in "if you do this, we'll cut off your network access entirely" -- led all concerned to guess that there was a political reason, not a technical reason. So, I just used non-standard ports, and some other firewalling, to prevent your staff from detecting it. Also, there was the long fight about members running their own servers (as in member.house.gov), instead of relying on the central servers for connectivity (www.house.gov/member). Again, we really didn't trust the Republicans not to examine internal data. > I do recall unfounded accusations > both ways, but it would be sad for the rumors to outlive the reality. Like this verified and widely reported: "Democrats Suggest Inquiry Points to Wider Spying by G.O.P." http://query.nytimes.com/gst/fullpage.html?res=940DE4D7173AF933A25751C0A9629C8B63&sec=&spon=&pagewanted=print > The notorious case of intercepted cell-phone conversations had nothing > to do with the data network. > True, but irrelevant. > I will not say anything about how large or redundant the data center is > for obvious reasons, beyond that I am no longer employed there and do > not have the details. > I've not even visited DC since 2002, and the old building with the page dorm was torn down that summer. But I can dig and traceroute. I'm pretty sure this isn't an ideal (or standard conforming) setup. But it shouldn't have been swamped, as seems to be akamaized. === ;; QUESTION SECTION: ;financialservices.house.gov. IN A ;; ANSWER SECTION: financialservices.house.gov. 3600 IN CNAME www.house.gov. www.house.gov. 3503 IN CNAME house.gov.edgesuite.net. house.gov.edgesuite.net. 4372 IN CNAME a1164.g.akamai.net. a1164.g.akamai.net. 20 IN A 192.122.184.19 a1164.g.akamai.net. 20 IN A 192.122.184.7 === house.gov. 900 IN SOA mercury.house.gov. dnsadmin.mail.house.gov. 1002529 3600 1800 604800 3600 house.gov. 14128 IN NS chyron.house.gov. house.gov. 14128 IN NS mercury.house.gov. mercury.house.gov. 14166 IN A 143.231.1.67 chyron.house.gov. 14149 IN A 143.228.129.38 From schnizlein at isoc.org Thu Oct 2 16:06:35 2008 From: schnizlein at isoc.org (John Schnizlein) Date: Thu, 2 Oct 2008 17:06:35 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <48E52A4E.7020209@gmail.com> References: <20081002155426.GM10127@core.center.osis.gov> <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> <48E52A4E.7020209@gmail.com> Message-ID: This will be my last response on this despite whatever spin follows. On 2008Oct2, at 4:08 PM, William Allen Simpson wrote: > John Schnizlein wrote: >> I connected the internal network of the US House of Representatives >> to the Internet when I worked there, and operated it through both >> Democratic and Republican control. > > Aha, I wondered who was to blame.... Thank you for the compliment. > ... >> I never saw any snooping by either party of the network traffic, >> and I had sniffers for diagnosing problems in several communication >> closets. > > Yet, there was verified interception of both House and Senate email > communications. Nobody claimed it was "on the wire" network > traffic, as > there were many weaknesses in the data network security design. If you know any, please send them to me privately. I can assure the community that our design and implementation got repeated review and testing from the best we could find at the time. > And the vicious fight about our setting up a VPN to bypass the > centrally > controlled system -- as in "if you do this, we'll cut off your network > access entirely" -- led all concerned to guess that there was a > political > reason, not a technical reason. So, I just used non-standard ports, > and > some other firewalling, to prevent your staff from detecting it. I hope no damage was produced by any inadvertent back doors opened by your VPN. Since we were not blocking applications other than IRC, I don't know what you felt you needed to get around. > Also, there was the long fight about members running their own servers > (as in member.house.gov), instead of relying on the central servers > for > connectivity (www.house.gov/member). Again, we really didn't trust > the > Republicans not to examine internal data. Although I do not recall the particular offices, I do recall that several committees and members had both email and web servers in their own offices with domains delegated to them on request. I have no idea what "long fight" you might have experienced. >> I do recall unfounded accusations both ways, but it would be sad >> for the rumors to outlive the reality. > > Like this verified and widely reported: > > "Democrats Suggest Inquiry Points to Wider Spying by G.O.P." > http://query.nytimes.com/gst/fullpage.html?res=940DE4D7173AF933A25751C0A9629C8B63&sec=&spon=&pagewanted=print As I recall this was simply a case of one staffer logging into a server in a different office. As you mentioned above, not "on the wire" and not a data network security issue. As sometimes still happens, the "computer network" actually referred to a file server. This article is about activities in the Senate, which operates independently of the House - was your experience actually with respect to the Senate? John From jfmezei at vaxination.ca Thu Oct 2 16:11:35 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Thu, 02 Oct 2008 17:11:35 -0400 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <48E52A4E.7020209@gmail.com> References: <20081002155426.GM10127@core.center.osis.gov> <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> <48E52A4E.7020209@gmail.com> Message-ID: <48E53907.1010506@vaxination.ca> William Allen Simpson wrote: > But I can dig and traceroute. I'm pretty sure this isn't an ideal (or > standard conforming) setup. But it shouldn't have been swamped, as seems to > be akamaized. I don't have traceroutes kept, but during that night when Pelosi announced the bill was available for all to download, I tried to get to that page and it was extremely slow. Doing a traceroute didn't *seem* to end at an akamai point. My memory could be in error. Question: Is it possible to setup an akamai feed in hours once you know your website is to be swamped ? Obviously, the system managers there might not have been warned in advance that the politicians would place a huge load on their servers. But once they realised it, is it conceivable that they quickly setup an akamai feed ? Or is that something which takes weeks to setup ? From brandon.galbraith at gmail.com Thu Oct 2 16:20:01 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 2 Oct 2008 16:20:01 -0500 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <48E53907.1010506@vaxination.ca> References: <20081002155426.GM10127@core.center.osis.gov> <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> <48E52A4E.7020209@gmail.com> <48E53907.1010506@vaxination.ca> Message-ID: <366100670810021420o7f333883q353bdf27ebdd0b56@mail.gmail.com> On 10/2/08, Jean-Fran?ois Mezei wrote: > > Question: > > Is it possible to setup an akamai feed in hours once you know your > website is to be swamped ? > > Obviously, the system managers there might not have been warned in > advance that the politicians would place a huge load on their servers. > But once they realised it, is it conceivable that they quickly setup an > akamai feed ? Or is that something which takes weeks to setup ? > > I'm not sure about Akamai, but I believe Amazon is about to roll out CDN services as well (and I would assume they're as flexible as their other "cloud" offerings). As always, hindsight is 20/20. http://www.amazon.com/gp/html-forms-controller/aws-content-delivery-service -brandon From web at typo.org Thu Oct 2 16:50:40 2008 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 2 Oct 2008 14:50:40 -0700 Subject: 143.228.0.0/16 and house.gov In-Reply-To: <366100670810021420o7f333883q353bdf27ebdd0b56@mail.gmail.com> References: <20081002155426.GM10127@core.center.osis.gov> <83D04485CE9BEF4883EBF055E1EC15923E4980@EX02.IMSG.ADS> <214784DF-F7FD-4C7F-9D3D-8D4D7B11173A@isoc.org> <48E52A4E.7020209@gmail.com> <48E53907.1010506@vaxination.ca> <366100670810021420o7f333883q353bdf27ebdd0b56@mail.gmail.com> Message-ID: <20081002215040.GA9581@typo.org> Pretty much no matter who you use, this can easily be done in an hour or so if people really want it to and the right techs are available. If there's a pre-existing agreement, this can go to mere minutes. The setup doesn't take long. it's usually the business stuff that drags it out. On Thu, Oct 02, 2008 at 04:20:01PM -0500, Brandon Galbraith wrote: > On 10/2/08, Jean-Fran??ois Mezei wrote: > > > > > > Question: > > > > Is it possible to setup an akamai feed in hours once you know your > > website is to be swamped ? > > > > Obviously, the system managers there might not have been warned in > > advance that the politicians would place a huge load on their servers. > > But once they realised it, is it conceivable that they quickly setup an > > akamai feed ? Or is that something which takes weeks to setup ? > > > > > I'm not sure about Akamai, but I believe Amazon is about to roll out CDN > services as well (and I would assume they're as flexible as their other > "cloud" offerings). As always, hindsight is 20/20. > > http://www.amazon.com/gp/html-forms-controller/aws-content-delivery-service > > -brandon --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From fwc at mt.net Thu Oct 2 23:25:28 2008 From: fwc at mt.net (Forrest W. Christian) Date: Thu, 02 Oct 2008 22:25:28 -0600 Subject: Used (SONET) equipment sources/lists? Message-ID: <48E59EB8.8070706@mt.net> I'm switching one end of a PtP DS3 to a location which only has fiber to the carrier. As a result, I'm really in need of a Fujitsu FlashWave 4010 or equivalent which can take a sonet-framed OC3 from a carrier and break it out into individual DS3's. So far, my normal sources of used equipment have come up dry - but most of them really only deal with data networking (cisco) stuff, so it's a bit out of their league. A long time ago (you know, like 100 internet years ago), I used to post these type of needs to misc.forsale.computers.net-hardware with good results, but that doesn't look very useful anymore. I'm hoping someone can point me towards a reseller which specializes in this type of stuff, or another source I've overlooked. (and no, eBay isn't a valid answer for this question... I've been watching :) Of course, if someone would like to tell me a easier/different (but still reasonably inexpensive) way to break apart a SONET OC3 such that a far end DS3 can be connected to something like a PA-A3-T3 or a PA-T3 that would work too. Thanks, -forrest From aaron.glenn at gmail.com Thu Oct 2 23:35:12 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Thu, 2 Oct 2008 21:35:12 -0700 Subject: Used (SONET) equipment sources/lists? In-Reply-To: <48E59EB8.8070706@mt.net> References: <48E59EB8.8070706@mt.net> Message-ID: <18f601940810022135l46fb662qddeb2ed0803dca58@mail.gmail.com> On Thu, Oct 2, 2008 at 9:25 PM, Forrest W. Christian wrote: > I'm hoping someone can point me towards a reseller which specializes in this > type of stuff, or another source I've overlooked. I'm going to (slightly) hijack this by saying: if anyone knows of a reseller that specializes in used/aftermarket DWDM gear, I'd love to know. From swmike at swm.pp.se Thu Oct 2 23:44:08 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 3 Oct 2008 06:44:08 +0200 (CEST) Subject: Used (SONET) equipment sources/lists? In-Reply-To: <48E59EB8.8070706@mt.net> References: <48E59EB8.8070706@mt.net> Message-ID: On Thu, 2 Oct 2008, Forrest W. Christian wrote: > So far, my normal sources of used equipment have come up dry - but most of > them really only deal with data networking (cisco) stuff, so it's a bit out > of their league. A long time ago (you know, like 100 internet years ago), > I used to post these type of needs to misc.forsale.computers.net-hardware > with good results, but that doesn't look very useful anymore. You can try the email list "network-resell at network-resell.com", there are quite a few used part resellers there. -- Mikael Abrahamsson email: swmike at swm.pp.se From jay at west.net Thu Oct 2 23:49:58 2008 From: jay at west.net (Jay Hennigan) Date: Thu, 02 Oct 2008 21:49:58 -0700 Subject: Used (SONET) equipment sources/lists? In-Reply-To: <48E59EB8.8070706@mt.net> References: <48E59EB8.8070706@mt.net> Message-ID: <48E5A476.8050400@west.net> Forrest W. Christian wrote: > I'm switching one end of a PtP DS3 to a location which only has fiber to > the carrier. As a result, I'm really in need of a Fujitsu FlashWave > 4010 or equivalent which can take a sonet-framed OC3 from a carrier and > break it out into individual DS3's. > > So far, my normal sources of used equipment have come up dry - but most > of them really only deal with data networking (cisco) stuff, so it's a > bit out of their league. A long time ago (you know, like 100 internet > years ago), I used to post these type of needs to > misc.forsale.computers.net-hardware with good results, but that doesn't > look very useful anymore. Take a look at Adtran's OPTI-3 or more scalable OPTI-6100 series products. I have no idea why Adtran has mile-long URLs, so here goes: http://tinyurl.com/3gt54w http://tinyurl.com/2z3yeg Some used gear out there but not a lot. The right wholesaler can give you a pretty good discount on the new stuff. We've had excellent results with Adtran equipment. Note that this gear as well as TTBOMK the Fujitsu is native 48VDC power, so figure in a power supply if you're in an AC environment. Adtran sells compatible power supplies if needed. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From cidr-report at potaroo.net Fri Oct 3 07:00:06 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Oct 2008 22:00:06 +1000 (EST) Subject: BGP Update Report Message-ID: <200810031200.m93C06Ze049078@wattle.apnic.net> BGP Update Report Interval: 01-Sep-08 -to- 02-Oct-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 270423 3.1% 219.0 -- SIFY-AS-IN Sify Limited 2 - AS1803 112677 1.3% 83.0 -- ICMNET-5 - Sprint 3 - AS4538 94973 1.1% 18.9 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS5691 78608 0.9% 6046.8 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8151 73506 0.8% 30.0 -- Uninet S.A. de C.V. 6 - AS6389 68084 0.8% 15.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 7 - AS9051 62207 0.7% 391.2 -- IDM Autonomous System 8 - AS20255 52357 0.6% 2181.5 -- Tecnowind S.A. 9 - AS14593 51930 0.6% 51930.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 10 - AS4184 51693 0.6% 25846.5 -- STORTEK-WHQ - Storage Technology Corporation 11 - AS209 50485 0.6% 16.8 -- ASN-QWEST - Qwest 12 - AS10396 49882 0.6% 906.9 -- COQUI-NET - DATACOM CARIBE, INC. 13 - AS4274 46859 0.5% 689.1 -- ERX-AU-NET Assumption University 14 - AS11971 43557 0.5% 6222.4 -- PFIZERNET-GROTON - PFIZER INC. 15 - AS30890 40551 0.5% 29.9 -- EVOLVA Evolva Telecom 16 - AS20115 39360 0.5% 19.7 -- CHARTER-NET-HKY-NC - Charter Communications 17 - AS7018 38723 0.4% 26.2 -- ATT-INTERNET4 - AT&T WorldNet Services 18 - AS18231 36408 0.4% 146.2 -- EXATT-AS-AP IOL NETCOM LTD 19 - AS6458 35507 0.4% 104.4 -- Telgua 20 - AS17488 34904 0.4% 23.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 51930 0.6% 51930.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 51693 0.6% 25846.5 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS8266 18591 0.2% 18591.0 -- NEXUSTEL Nexus Telecommunications 4 - AS29910 6939 0.1% 6939.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS38180 6814 0.1% 6814.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 6 - AS11971 43557 0.5% 6222.4 -- PFIZERNET-GROTON - PFIZER INC. 7 - AS5691 78608 0.9% 6046.8 -- MITRE-AS-5 - The MITRE Corporation 8 - AS4557 7862 0.1% 3931.0 -- EP0-BLK-ASNBLOCK-7 - EP.NET, LLC. 9 - AS30969 30688 0.3% 3836.0 -- TAN-NET TransAfrica Networks 10 - AS23082 18093 0.2% 3618.6 -- MPHI - Michigan Public Health Institute 11 - AS44194 2814 0.0% 2814.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 12 - AS32761 2557 0.0% 2557.0 -- WASSE-NYC - Wasserstein & Co. 13 - AS23917 2280 0.0% 2280.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS20255 52357 0.6% 2181.5 -- Tecnowind S.A. 15 - AS24491 1705 0.0% 1705.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 16 - AS32011 1529 0.0% 1529.0 -- JOHO-NYC - Joho Capital, LLC 17 - AS10221 5694 0.1% 1423.5 -- HEWLETT-PACKARD Multi-homed connections to multiple ISP's providing 18 - AS9747 10398 0.1% 1299.8 -- EZINTERNET-AS-AP EZInternet Pty Ltd 19 - AS25321 1251 0.0% 1251.0 -- G4S-NET GROUP 4 SECURITAS Prague 20 - AS3944 3594 0.0% 1198.0 -- PARTAN-LAB - Partan & Partan TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 78486 0.8% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 210.214.151.0/24 61815 0.7% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.134.222.0/24 58347 0.6% AS9583 -- SIFY-AS-IN Sify Limited 4 - 194.126.143.0/24 52197 0.6% AS9051 -- IDM Autonomous System 5 - 12.8.7.0/24 51930 0.6% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 6 - 221.135.80.0/24 47652 0.5% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.210.112.0/24 45236 0.5% AS9583 -- SIFY-AS-IN Sify Limited 8 - 12.18.36.0/24 43289 0.5% AS11971 -- PFIZERNET-GROTON - PFIZER INC. 9 - 221.135.251.0/24 32666 0.3% AS9583 -- SIFY-AS-IN Sify Limited 10 - 221.128.192.0/18 28021 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 11 - 200.108.200.0/24 26534 0.3% AS20255 -- Tecnowind S.A. 12 - 199.117.144.0/22 25847 0.3% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 13 - 129.80.0.0/16 25846 0.3% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 14 - 200.108.220.0/24 25547 0.3% AS20255 -- Tecnowind S.A. 15 - 72.50.96.0/20 24477 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 196.42.0.0/20 24460 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 17 - 83.228.71.0/24 22340 0.2% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 18 - 193.93.148.0/22 18591 0.2% AS8266 -- NEXUSTEL Nexus Telecommunications 19 - 196.27.108.0/22 15165 0.2% AS30969 -- TAN-NET TransAfrica Networks 20 - 196.27.104.0/21 15140 0.2% AS30969 -- TAN-NET TransAfrica Networks Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 3 07:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Oct 2008 22:00:01 +1000 (EST) Subject: The Cidr Report Message-ID: <200810031200.m93C01LU049049@wattle.apnic.net> This report has been generated at Fri Oct 3 21:17:30 2008 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 26-09-08 282212 172840 27-09-08 281895 173376 28-09-08 281607 173846 29-09-08 282138 174099 30-09-08 282044 173861 01-10-08 282391 174307 02-10-08 282791 172229 03-10-08 282818 171922 AS Summary 29547 Number of ASes in routing system 12513 Number of ASes announcing only one prefix 5032 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88349184 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 03Oct08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 282956 171914 111042 39.2% All ASes AS4538 5032 880 4152 82.5% ERX-CERNET-BKB China Education and Research Network Center AS6389 4302 351 3951 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2948 1332 1616 54.8% ASN-QWEST - Qwest Communications Corporation AS1785 1670 159 1511 90.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 2010 714 1296 64.5% COX-PHX - Cox Communications Inc. AS4755 1457 271 1186 81.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1393 307 1086 78.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1537 596 941 61.2% TWTC - tw telecom holdings, inc. AS22773 991 86 905 91.3% CCINET-2 - Cox Communications Inc. AS8151 1411 550 861 61.0% Uninet S.A. de C.V. AS19262 956 174 782 81.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1212 442 770 63.5% CABLEONE - CABLE ONE AS18566 1057 318 739 69.9% COVAD - Covad Communications Co. AS18101 781 94 687 88.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS2386 1557 912 645 41.4% INS-AS - AT&T Data Communications Services AS9498 682 72 610 89.4% BBIL-AP BHARTI Airtel Ltd. AS6478 1203 597 606 50.4% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1032 539 493 47.8% LEVEL3 Level 3 Communications AS855 596 108 488 81.9% CANET-ASN-4 - Bell Aliant AS4766 914 438 476 52.1% KIXS-AS-KR Korea Telecom AS4808 616 145 471 76.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17676 524 65 459 87.6% GIGAINFRA BB TECHNOLOGY Corp. AS9443 524 77 447 85.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS20115 1805 1360 445 24.7% CHARTER-NET-HKY-NC - Charter Communications AS7011 913 476 437 47.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7545 586 149 437 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 564 128 436 77.3% VTR BANDA ANCHA S.A. AS24560 593 157 436 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1433 999 434 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 839 411 428 51.0% CHINANET-BACKBONE No.31,Jin-rong Street Total 41138 12907 28231 68.6% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 31.31.31.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.133.0.0/19 AS16082 SPITFIRE Spitfire Network Services Autonomous System 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.200.192.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.193.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.194.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.195.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 119.31.232.0/21 AS38870 124.109.16.0/21 AS38137 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest Communications Corporation 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.25.240.0/21 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From morrowc.lists at gmail.com Fri Oct 3 09:56:04 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 Oct 2008 10:56:04 -0400 Subject: NANOG 44 (Los Angeles): ISP Security BOF In-Reply-To: References: Message-ID: <75cb24520810030756q2d2ebd3bp4a8b2b20d25d7e33@mail.gmail.com> I would love (though I'll miss it in person) to see a discussion, structured, of why the Intercage/Atrivo situation got to where it was. I believe that in many (this one in particular) cases the upstream networks do not: 1) get 2) have relevant information in a useful format about abuse/use of their downstream networks. When I was at AS701 there were consistently folks who'd say this or that customer is obviously bad, why hadn't we disconnected them? When looking through abuse tickets for issues we could bring to management as ammo for disconnection often a majority of complaints related to the customer in question were not complete, didn't have enough information, didn't have ANY information in them. How can we, as a community get better at providing complete and useful information (ip, timestamp+timezone, act-that-caused-ire) How can we, as a community, get better at tying together the bits and pieces that are one issue? (atrivo/intercage/ukrtelecom/hostfresh) As an interesting aside, there were many occasions of the last 4 years where some horrible virus/trojan/malware thing got rolling on the internets, tracking it back was fairly simple (for the C&C or distribution site) to AS27595... often folks reporting the issue would say things like: "Oh, that's ukrtelecom, they are in the Ukraine, too bad we can't get hands on the server/router/code/subpoena them..." "Oh, that's something living in hostfresh, in ASPAC, gosh it'd be nice if the FBI/HTC-group could get there and give the provider some trouble..." oddly in many/all of these cases the IP space might have tracked back to somewhere not ARIN related, but an actual traceroute ended inside AS27595. So, tying together these incidents with more complete information would have potentially given the upstreams, or even 27595 if they are to be believed as being in the right and just framed by their bad customers (not my belief, but...), more actionable intelligence about their customer(s) and the ability to make an informed decision (at a management/legal level). -Chris (thanks) This is a set of topics I'd love to see handled in the SP Security BOF. On Mon, Sep 29, 2008 at 11:12 AM, Warren Kumari wrote: > Hi all, > > NANOG 44 is fast approaching and once again we are looking for topics for > the ISP Security BOF. > If you have any security related topics that you would like to hear about, > not hear about, or (best of all) speak about, please let me know as soon as > possible... > > This is your chance to air your views --- slides are welcome but not > required. > > Danny McPherson and I are going to be moderating this year... > > W > > > > From celestea at usc.edu Fri Oct 3 09:59:20 2008 From: celestea at usc.edu (Celeste Anderson) Date: Fri, 03 Oct 2008 07:59:20 -0700 Subject: Upcoming NANOG44 - Hockey in Los Angeles Message-ID: If you are planning on attending the upcoming NANOG44 conference in Los Angeles and are interested in attending a hockey game..... The Los Angeles Kings opening night is against the San Jose Sharks at Staples center Sunday Night.,October 12 at 6PM If there is enough interest Ralph Whitmore will arrange for tickets for all that want to go. He will need a count and money by Wednesday at the latest. Tickets will be priced based on the interest. He will have some ballpark numbers tomorrow after the Kings call him back. If the numbers are enough for a suite (15?), he will get a suite with a NO-Host bar in it. If not he will get good seats for all, though he cannot tell where they will be yet. If you are interested please e-mail Ralph at ralphw at interworld.net ASAP so he can get a ballpark number. I'll be sending another email shortly for other activities in the Los Angeles area for those who have some extra time for sightseeing before or after the NANOG/ARIN meetings. Hope to see you all in Los Angeles. Celeste. From dot at dotat.at Fri Oct 3 10:31:00 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 3 Oct 2008 16:31:00 +0100 Subject: Google's PUE In-Reply-To: <816E66A0-4654-4BB1-B39C-08ABFA80272B@ianai.net> References: <816E66A0-4654-4BB1-B39C-08ABFA80272B@ianai.net> Message-ID: On Thu, 2 Oct 2008, Patrick W. Gilmore wrote: > > Personally, I am glad GOOG is posting their PUE. People who talk about > additional metrics are correct - more information is better. But some > information is better than none, and PUE is a perfectly valid data > point. It doesn't measure everything, but that does not make it > completely useless. Given Google's history of .. shall we say reticence > regarding internal information, it's nice to see SOMETHING from them. > So let's encourage it and see if they release more. Also relevant is this paper: "Power provisioning for a warehouse-sized computer" http://research.google.com/archive/power_provisioning.pdf Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT: WEST 5 OR 6 VEERING NORTHWEST 6 TO GALE 8, BACKING SOUTHWEST 5 OR 6 LATER. ROUGH OR VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From cscora at apnic.net Fri Oct 3 13:08:47 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Oct 2008 04:08:47 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200810031808.m93I8lCH019621@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Oct, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 270385 Prefixes after maximum aggregation: 130450 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131768 Total ASes present in the Internet Routing Table: 29399 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25577 Origin ASes announcing only one prefix: 12464 Transit ASes present in the Internet Routing Table: 3822 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 560 Unregistered ASNs in the Routing Table: 200 Number of 32-bit ASNs allocated by the RIRs: 61 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 752 Number of addresses announced to Internet: 1909012352 Equivalent to 113 /8s, 201 /16s and 55 /24s Percentage of available address space announced: 51.5 Percentage of allocated address space announced: 62.5 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.7 Total number of prefixes smaller than registry allocations: 132791 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62421 Total APNIC prefixes after maximum aggregation: 23127 APNIC Deaggregation factor: 2.70 Prefixes being announced from the APNIC address blocks: 59307 Unique aggregates announced from the APNIC address blocks: 26669 APNIC Region origin ASes present in the Internet Routing Table: 3389 APNIC Prefixes per ASN: 17.50 APNIC Region origin ASes announcing only one prefix: 903 APNIC Region transit ASes present in the Internet Routing Table: 539 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 377990304 Equivalent to 22 /8s, 135 /16s and 172 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/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, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 122827 Total ARIN prefixes after maximum aggregation: 64724 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92067 Unique aggregates announced from the ARIN address blocks: 35235 ARIN Region origin ASes present in the Internet Routing Table: 12493 ARIN Prefixes per ASN: 7.37 ARIN Region origin ASes announcing only one prefix: 4833 ARIN Region transit ASes present in the Internet Routing Table: 1189 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 364498912 Equivalent to 21 /8s, 185 /16s and 207 /24s Percentage of available ARIN address space announced: 74.9 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 ARIN Address Blocks 24/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, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 58838 Total RIPE prefixes after maximum aggregation: 35441 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 54018 Unique aggregates announced from the RIPE address blocks: 36183 RIPE Region origin ASes present in the Internet Routing Table: 11981 RIPE Prefixes per ASN: 4.51 RIPE Region origin ASes announcing only one prefix: 6314 RIPE Region transit ASes present in the Internet Routing Table: 1824 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 374235424 Equivalent to 22 /8s, 78 /16s and 97 /24s Percentage of available RIPE address space announced: 85.8 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-49151 RIPE Address Blocks 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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 21554 Total LACNIC prefixes after maximum aggregation: 5416 LACNIC Deaggregation factor: 3.98 Prefixes being announced from the LACNIC address blocks: 19669 Unique aggregates announced from the LACNIC address blocks: 11065 LACNIC Region origin ASes present in the Internet Routing Table: 1005 LACNIC Prefixes per ASN: 19.57 LACNIC Region origin ASes announcing only one prefix: 332 LACNIC Region transit ASes present in the Internet Routing Table: 169 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 56901120 Equivalent to 3 /8s, 100 /16s and 62 /24s Percentage of available LACNIC address space announced: 56.5 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4189 Total AfriNIC prefixes after maximum aggregation: 1300 AfriNIC Deaggregation factor: 3.22 Prefixes being announced from the AfriNIC address blocks: 4464 Unique aggregates announced from the AfriNIC address blocks: 2066 AfriNIC Region origin ASes present in the Internet Routing Table: 260 AfriNIC Prefixes per ASN: 17.17 AfriNIC Region origin ASes announcing only one prefix: 82 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12766464 Equivalent to 0 /8s, 194 /16s and 205 /24s Percentage of available AfriNIC address space announced: 38.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1454 521 190 TATA Communications formerly 17488 1393 95 99 Hathway IP Over Cable Interne 9583 1109 87 476 Sify Limited 4766 876 6407 359 Korea Telecom (KIX) 4134 839 13664 343 CHINANET-BACKBONE 23577 808 34 689 Korea Telecom (ATM-MPLS) 18101 781 161 63 Reliance Infocom Ltd Internet 4780 717 355 61 Digital United Inc. 9498 680 295 54 BHARTI BT INTERNET LTD. 4808 627 1164 142 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4299 3416 339 bellsouth.net, inc. 209 2940 4033 623 Qwest 6298 2009 319 713 Cox Communicatons 20115 1811 1425 712 Charter Communications 1785 1668 717 154 PaeTec Communications, Inc. 2386 1554 699 895 AT&T Data Communications Serv 4323 1540 1083 373 Time Warner Telecom 7018 1414 5795 984 AT&T WorldNet Services 11492 1212 152 11 Cable One 6478 1203 242 182 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 432 1761 381 TDC Tele Danmark 30890 338 90 182 SC Kappa Invexim SRL 3301 330 1428 301 TeliaNet Sweden 3215 328 2756 107 France Telecom Transpac 3320 324 7063 273 Deutsche Telekom AG 8866 324 79 22 Bulgarian Telecommunication C 8452 316 188 11 TEDATA 5462 301 794 27 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1412 2847 223 UniNet S.A. de C.V. 11830 669 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 493 242 71 Telecom Argentina Stet-France 10620 483 118 93 TVCABLE BOGOTA 16814 426 27 10 NSS, S.A. 6471 420 85 48 ENTEL CHILE S.A. 11172 407 118 71 Servicios Alestra S.A de C.V 14117 343 23 9 Telefonica del Sur S.A. 28573 339 443 28 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 545 71 39 LINKdotNET AS number 20858 401 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 234 215 139 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 119 555 69 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited 29571 109 13 9 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4299 3416 339 bellsouth.net, inc. 209 2940 4033 623 Qwest 6298 2009 319 713 Cox Communicatons 20115 1811 1425 712 Charter Communications 1785 1668 717 154 PaeTec Communications, Inc. 2386 1554 699 895 AT&T Data Communications Serv 4323 1540 1083 373 Time Warner Telecom 4755 1454 521 190 TATA Communications formerly 7018 1414 5795 984 AT&T WorldNet Services 8151 1412 2847 223 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2940 2317 Qwest 1785 1668 1514 PaeTec Communications, Inc. 6298 2009 1296 Cox Communicatons 17488 1393 1294 Hathway IP Over Cable Interne 4755 1454 1264 TATA Communications formerly 11492 1212 1201 Cable One 8151 1412 1189 UniNet S.A. de C.V. 4323 1540 1167 Time Warner Telecom 20115 1811 1099 Charter Communications 18566 1058 1048 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.189.32.0/21 29571 Ci Telecom Autonomous system 41.215.208.0/20 8657 CPRM Autonomous System 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.133.0.0/19 16082 Spitfire Digital Networks Aut 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.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:18 /9:9 /10:17 /11:45 /12:147 /13:295 /14:531 /15:1060 /16:10127 /17:4401 /18:7603 /19:16337 /20:19159 /21:18671 /22:23526 /23:24569 /24:141200 /25:816 /26:979 /27:769 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2847 4299 bellsouth.net, inc. 6298 1983 2009 Cox Communicatons 209 1698 2940 Qwest 2386 1234 1554 AT&T Data Communications Serv 17488 1200 1393 Hathway IP Over Cable Interne 11492 1188 1212 Cable One 1785 1128 1668 PaeTec Communications, Inc. 6478 1095 1203 AT&T Worldnet Services 18566 1039 1058 Covad Communications 9583 977 1109 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:142 12:2173 13:2 15:22 16:3 17:5 18:13 20:35 24:1128 31:1 32:58 38:502 40:92 41:712 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:520 59:526 60:452 61:974 62:1233 63:2034 64:3219 65:2418 66:3509 67:1264 68:802 69:2321 70:859 71:244 72:2053 73:7 74:1217 75:161 76:265 77:804 78:839 79:255 80:929 81:863 82:603 83:381 84:581 85:1006 86:401 87:709 88:340 89:1384 90:20 91:1561 92:267 93:895 94:227 96:79 97:88 98:338 99:8 113:1 114:104 115:100 116:998 117:373 118:236 119:515 120:93 121:599 122:853 123:444 124:863 125:1183 128:356 129:201 130:134 131:416 132:72 133:9 134:180 135:32 136:217 137:97 138:142 139:81 140:511 141:106 142:408 143:299 144:328 145:51 146:371 147:159 148:524 149:210 150:128 151:182 152:149 153:136 154:10 155:283 156:173 157:301 158:168 159:305 160:275 161:138 162:255 163:131 164:518 165:509 166:365 167:336 168:635 169:143 170:452 171:33 172:10 173:34 187:16 188:1 189:309 190:2235 192:5750 193:4147 194:3265 195:2584 196:1006 198:3740 199:3295 200:5538 201:1435 202:7855 203:8083 204:3943 205:2154 206:2349 207:2742 208:3680 209:3437 210:2580 211:1096 212:1464 213:1595 214:175 215:50 216:4355 217:1237 218:348 219:435 220:1061 221:416 222:287 End of report From justin at justinshore.com Fri Oct 3 13:13:05 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 03 Oct 2008 13:13:05 -0500 Subject: Go daddy mail services admin In-Reply-To: <20081001141720.GA15221@redline.kinz.org> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> <20081001141720.GA15221@redline.kinz.org> Message-ID: <48E660B1.70803@justinshore.com> Jeff Kinz wrote: > Based on their long term refusal to adjust their policy to > conform to PBL intended usage of the list I suspect this > issue cannot be corrected. The only answer I have found is > to inform the affected people they have to move from GoDaddy > to a company that does a better job to correct the problem. GoDaddy is about as worthless of a mail provider and it gets. I can't count the number of times I've had customers get themselves blacklisted by GoDaddy and not be able to get unlisted. Finding a contact number for them used to be damn near impossible. Finding a competent mail admin on the other end actually was impossible. My own company got blacklisted by GoDaddy a little over a year ago. A user with an infected laptop relayed infected email out through the corporate firewall's NAT pool (no longer blindly permitted). GoDaddy's response? The entire /24 used by our corporate firewall was blacklisted intermittently for about 6 months. Our recommendation to our clients and our SP customers is to not use GoDaddy's mail services. Pick a mail provider that's known for being responsive. Justin From rcorbin at TRAFFIQ.com Fri Oct 3 13:23:15 2008 From: rcorbin at TRAFFIQ.com (Raymond Corbin) Date: Fri, 3 Oct 2008 14:23:15 -0400 Subject: Go daddy mail services admin In-Reply-To: <48E660B1.70803@justinshore.com> Message-ID: Yeah they usually simply do /24 blocks. From what I remember in the blacklist 550 response it says a removal link? Something like http://unblock.secureserver.net/?ip=x.x.x.x right? -r -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Friday, October 03, 2008 2:13 PM To: Jeff Kinz; NANOG Subject: Re: Go daddy mail services admin Jeff Kinz wrote: > Based on their long term refusal to adjust their policy to > conform to PBL intended usage of the list I suspect this > issue cannot be corrected. The only answer I have found is > to inform the affected people they have to move from GoDaddy > to a company that does a better job to correct the problem. GoDaddy is about as worthless of a mail provider and it gets. I can't count the number of times I've had customers get themselves blacklisted by GoDaddy and not be able to get unlisted. Finding a contact number for them used to be damn near impossible. Finding a competent mail admin on the other end actually was impossible. My own company got blacklisted by GoDaddy a little over a year ago. A user with an infected laptop relayed infected email out through the corporate firewall's NAT pool (no longer blindly permitted). GoDaddy's response? The entire /24 used by our corporate firewall was blacklisted intermittently for about 6 months. Our recommendation to our clients and our SP customers is to not use GoDaddy's mail services. Pick a mail provider that's known for being responsive. Justin From justin at justinshore.com Fri Oct 3 13:26:05 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 03 Oct 2008 13:26:05 -0500 Subject: Go daddy mail services admin In-Reply-To: References: Message-ID: <48E663BD.5070900@justinshore.com> Raymond Corbin wrote: > Yeah they usually simply do /24 blocks. From what I remember in the > blacklist 550 response it says a removal link? Something like > > http://unblock.secureserver.net/?ip=x.x.x.x right? I believe that's correct. It's a shame it doesn't accomplish anything (or it never has for me before). I always had to dig until I found a number for them to call and complain. Even then I only succeeded 1 out of every 10 tries or so. Justin From warren at kumari.net Fri Oct 3 13:37:33 2008 From: warren at kumari.net (Warren Kumari) Date: Fri, 3 Oct 2008 14:37:33 -0400 Subject: NANOG 44 (Los Angeles): ISP Security BOF In-Reply-To: <75cb24520810030756q2d2ebd3bp4a8b2b20d25d7e33@mail.gmail.com> References: <75cb24520810030756q2d2ebd3bp4a8b2b20d25d7e33@mail.gmail.com> Message-ID: <4BCCDB69-A885-4957-BF2B-8487355B05AF@kumari.net> On Oct 3, 2008, at 10:56 AM, Christopher Morrow wrote: > I would love (though I'll miss it in person) to see a discussion, > structured, of why the Intercage/Atrivo situation got to where it was. While I realize that this is not quite what you asked for, Esthost has requested some time on the agenda to be able to tell their side of the story... After some deliberations we have decided to give them 10 minutes for a presentation and 10 minutes for questions and answers[0]. We would also welcome any talks presenting the other viewpoint, but ask that they be kept civil and factual (as we have requested from Esthost). W [0]: We have not listed this talk yet as we are waiting for a title and abstract.... > > I believe that in many (this one in particular) cases the upstream > networks do not: > 1) get > 2) have > > relevant information in a useful format about abuse/use of their > downstream networks. When I was at AS701 there were consistently folks > who'd say this or that customer is obviously bad, why hadn't we > disconnected them? When looking through abuse tickets for issues we > could bring to management as ammo for disconnection often a majority > of complaints related to the customer in question were not complete, > didn't have enough information, didn't have ANY information in them. > > How can we, as a community get better at providing complete and useful > information (ip, timestamp+timezone, act-that-caused-ire) > How can we, as a community, get better at tying together the bits and > pieces that are one issue? (atrivo/intercage/ukrtelecom/hostfresh) > > As an interesting aside, there were many occasions of the last 4 years > where some horrible virus/trojan/malware thing got rolling on the > internets, tracking it back was fairly simple (for the C&C or > distribution site) to AS27595... often folks reporting the issue would > say things like: > > "Oh, that's ukrtelecom, they are in the Ukraine, too bad we can't get > hands on the server/router/code/subpoena them..." > "Oh, that's something living in hostfresh, in ASPAC, gosh it'd be nice > if the FBI/HTC-group could get there and give the provider some > trouble..." > > oddly in many/all of these cases the IP space might have tracked back > to somewhere not ARIN related, but an actual traceroute ended inside > AS27595. So, tying together these incidents with more complete > information would have potentially given the upstreams, or even 27595 > if they are to be believed as being in the right and just framed by > their bad customers (not my belief, but...), more actionable > intelligence about their customer(s) and the ability to make an > informed decision (at a management/legal level). > > -Chris > (thanks) > > This is a set of topics I'd love to see handled in the SP Security > BOF. > > On Mon, Sep 29, 2008 at 11:12 AM, Warren Kumari > wrote: >> Hi all, >> >> NANOG 44 is fast approaching and once again we are looking for >> topics for >> the ISP Security BOF. >> If you have any security related topics that you would like to hear >> about, >> not hear about, or (best of all) speak about, please let me know as >> soon as >> possible... >> >> This is your chance to air your views --- slides are welcome but not >> required. >> >> Danny McPherson and I are going to be moderating this year... >> >> W >> >> >> >> > From paul at blacknight.com Fri Oct 3 18:17:14 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Sat, 4 Oct 2008 00:17:14 +0100 Subject: Outblaze admins? Message-ID: Hi There, If there are any people who manage outblaze can they contact me either on or offlist. We've been trying to get a server delisted since September 12th and have been completely unsuccessful. The website doesn't appear to remove the IP and using the contact forms to contact the postmaster has not resulted in any contact from them to us. Thanks, Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 From noel.butler at ausics.net Fri Oct 3 19:41:46 2008 From: noel.butler at ausics.net (Noel Butler) Date: Sat, 04 Oct 2008 10:41:46 +1000 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <48E4C2D7.9050905@cox.net> References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> Message-ID: <1223080906.6922.2.camel@roswell.ausics.net> I'll post what I want, when I want and however I want, and no self appointed net nazi is going to tell me otherwise. have a nice weekend, I know I will. On Thu, 2008-10-02 at 22:47, Laurence F. Sheldon, Jr. wrote: > Noel Butler wrote: > [nothing worth having been forwarded several times] > > I'm sure I'll get a nastygram from the kabal for this, but just out of > curiosity, why is talking about broken network protocols and other stuff > "off topic", but talking mindlessly and endlessly about mindless and > pointless drivel (quoting the whole history of the thread with each > entry , top posting to remove whatever residual content there might > have been) is not? From ge at linuxbox.org Fri Oct 3 19:49:36 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 3 Oct 2008 19:49:36 -0500 (CDT) Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: <1223080906.6922.2.camel@roswell.ausics.net> References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> <1223080906.6922.2.camel@roswell.ausics.net> Message-ID: On Sat, 4 Oct 2008, Noel Butler wrote: > I'll post what I want, when I want and however I want, and no self > appointed net nazi is going to tell me otherwise. Ah! You mentioned the Nazis. Now we know the thread is over. :) We should mention Nazis more often to end threads here. Godwin's law to the rescue. > have a nice weekend, I know I will. > > > On Thu, 2008-10-02 at 22:47, Laurence F. Sheldon, Jr. wrote: > >> Noel Butler wrote: >> [nothing worth having been forwarded several times] >> >> I'm sure I'll get a nastygram from the kabal for this, but just out of >> curiosity, why is talking about broken network protocols and other stuff >> "off topic", but talking mindlessly and endlessly about mindless and >> pointless drivel (quoting the whole history of the thread with each >> entry , top posting to remove whatever residual content there might >> have been) is not? > From ops.lists at gmail.com Fri Oct 3 20:01:53 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 4 Oct 2008 06:31:53 +0530 Subject: Outblaze admins? In-Reply-To: References: Message-ID: Taken offlist. ps: Yes, we did reply multiple times - but we do recommend that people dont spam filter email from postmaster at outblaze.com precisely to avoid this sort of communication gap. thanks srs On Sat, Oct 4, 2008 at 4:47 AM, Paul Kelly :: Blacknight wrote: > Hi There, > > If there are any people who manage outblaze can they contact me either on or offlist. We've been trying to get a server delisted since September 12th and have been completely unsuccessful. The website doesn't appear to remove the IP and using the contact forms to contact the postmaster has not resulted in any contact from them to us. > > Thanks, > > Paul From ops.lists at gmail.com Fri Oct 3 20:08:27 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 4 Oct 2008 06:38:27 +0530 Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> <1223080906.6922.2.camel@roswell.ausics.net> Message-ID: On Sat, Oct 4, 2008 at 6:19 AM, Gadi Evron wrote: > On Sat, 4 Oct 2008, Noel Butler wrote: >> >> I'll post what I want, when I want and however I want, and no self >> appointed net nazi is going to tell me otherwise. > > Ah! You mentioned the Nazis. Now we know the thread is over. :) > > We should mention Nazis more often to end threads here. Godwin's law to the > rescue. Deliberate invocation of Hitler does not invoke Godwin's law (courtesy Gym Quirk .. now that's a name from the past.. havent read usenet in about a decade. --srs http://www.faqs.org/faqs/usenet/legends/godwin/ > 6. "Hitler!" Ha! The thread is over! > > Nope, doesn't work that way. Not only is it wrong to say that a > thread is over when Godwin's Law is invoked anyway (Usenet threads > virtually always outlive their usefulness), but long ago a corollary to > the Law was proposed and accepted by Taki "Quirk" Kogama (quirk at swcp.com): > > Quirk's Exception: Intentional invocation of this so-called > "Nazi Clause" is ineffectual. > > Sorry, folks. Nice try, though. From ge at linuxbox.org Sat Oct 4 00:03:45 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 4 Oct 2008 00:03:45 -0500 (CDT) Subject: Hey ISC, thanks for providing free wifi to intercage! In-Reply-To: References: <1222917950.7331.8.camel@roswell.ausics.net> <48E4C2D7.9050905@cox.net> <1223080906.6922.2.camel@roswell.ausics.net> Message-ID: On Sat, 4 Oct 2008, Suresh Ramasubramanian wrote: > On Sat, Oct 4, 2008 at 6:19 AM, Gadi Evron wrote: >> On Sat, 4 Oct 2008, Noel Butler wrote: >>> >>> I'll post what I want, when I want and however I want, and no self >>> appointed net nazi is going to tell me otherwise. >> >> Ah! You mentioned the Nazis. Now we know the thread is over. :) >> >> We should mention Nazis more often to end threads here. Godwin's law to the >> rescue. > > Deliberate invocation of Hitler does not invoke Godwin's law (courtesy > Gym Quirk .. now that's a name from the past.. havent read usenet in > about a decade. According to another interpretation, any invovation is allowed, although following it is optional and mostly dependent on peer pressure. I just made that up. That guy, did .. too. > --srs > > http://www.faqs.org/faqs/usenet/legends/godwin/ > >> 6. "Hitler!" Ha! The thread is over! >> >> Nope, doesn't work that way. Not only is it wrong to say that a >> thread is over when Godwin's Law is invoked anyway (Usenet threads >> virtually always outlive their usefulness), but long ago a corollary to >> the Law was proposed and accepted by Taki "Quirk" Kogama (quirk at swcp.com): >> >> Quirk's Exception: Intentional invocation of this so-called >> "Nazi Clause" is ineffectual. >> >> Sorry, folks. Nice try, though. > From frnkblk at iname.com Sat Oct 4 00:04:59 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Oct 2008 00:04:59 -0500 Subject: Used (SONET) equipment sources/lists? In-Reply-To: <48E59EB8.8070706@mt.net> References: <48E59EB8.8070706@mt.net> Message-ID: You could try here, too: http://www.telecomclassifiedads.com/ Frank -----Original Message----- From: Forrest W. Christian [mailto:fwc at mt.net] Sent: Thursday, October 02, 2008 11:25 PM To: nanog at nanog.org Subject: Used (SONET) equipment sources/lists? I'm switching one end of a PtP DS3 to a location which only has fiber to the carrier. As a result, I'm really in need of a Fujitsu FlashWave 4010 or equivalent which can take a sonet-framed OC3 from a carrier and break it out into individual DS3's. So far, my normal sources of used equipment have come up dry - but most of them really only deal with data networking (cisco) stuff, so it's a bit out of their league. A long time ago (you know, like 100 internet years ago), I used to post these type of needs to misc.forsale.computers.net-hardware with good results, but that doesn't look very useful anymore. I'm hoping someone can point me towards a reseller which specializes in this type of stuff, or another source I've overlooked. (and no, eBay isn't a valid answer for this question... I've been watching :) Of course, if someone would like to tell me a easier/different (but still reasonably inexpensive) way to break apart a SONET OC3 such that a far end DS3 can be connected to something like a PA-A3-T3 or a PA-T3 that would work too. Thanks, -forrest From nanog at nanog.org Sat Oct 4 00:58:56 2008 From: nanog at nanog.org (VIAGRA INC) Date: Sat, 04 Oct 2008 05:58:56 -0000 Subject: SALE 89% OFF Message-ID: <20081004115848.7101.qmail@gs207-246.toshima.ne.jp> [1][3.gif] References 1. http://www.biaveatt.com/ From lowen at pari.edu Sat Oct 4 11:53:46 2008 From: lowen at pari.edu (Lamar Owen) Date: Sat, 4 Oct 2008 12:53:46 -0400 Subject: Used (SONET) equipment sources/lists? In-Reply-To: <48E59EB8.8070706@mt.net> References: <48E59EB8.8070706@mt.net> Message-ID: <200810041253.47302.lowen@pari.edu> On Friday 03 October 2008 00:25:28 Forrest W. Christian wrote: > I'm hoping someone can point me towards a reseller which specializes in > this type of stuff, or another source I've overlooked. Fujitsu FLM-150 gear is cheap, and available on the used market. In just a quick look, a company called Bell Enterprise has a lot of that stuff. www.bell-enterprise.com > Of course, if someone would like to tell me a easier/different (but > still reasonably inexpensive) way to break apart a SONET OC3 such that a > far end DS3 can be connected to something like a PA-A3-T3 or a PA-T3 > that would work too. Don't know about easier or different, but the FLM-150, while old, is available. From sean at donelan.com Sat Oct 4 15:31:47 2008 From: sean at donelan.com (Sean Donelan) Date: Sat, 4 Oct 2008 16:31:47 -0400 (EDT) Subject: NANOG 44 (Los Angeles): ISP Security BOF In-Reply-To: <75cb24520810030756q2d2ebd3bp4a8b2b20d25d7e33@mail.gmail.com> References: <75cb24520810030756q2d2ebd3bp4a8b2b20d25d7e33@mail.gmail.com> Message-ID: <200810041613500.32BF5B92.18944@clifden.donelan.com> On Fri, 3 Oct 2008, Christopher Morrow wrote: > relevant information in a useful format about abuse/use of their > downstream networks. When I was at AS701 there were consistently folks > who'd say this or that customer is obviously bad, why hadn't we > disconnected them? When looking through abuse tickets for issues we > could bring to management as ammo for disconnection often a majority > of complaints related to the customer in question were not complete, > didn't have enough information, didn't have ANY information in them. > > How can we, as a community get better at providing complete and useful > information (ip, timestamp+timezone, act-that-caused-ire) > How can we, as a community, get better at tying together the bits and > pieces that are one issue? (atrivo/intercage/ukrtelecom/hostfresh) Is it that time of the year again for our annual discussion? There is a large crowd of motivated people, but often they don't seem to know how to put together everything they've down into an actionable package. They get frustrated, and it usually declines into the ISP's suck debate. Even security vendors selling things don't understand what is needed to quickly process abuse complaints (e.g. many examples from useless logs generated by IDS/personal firewalls). Would some current (or former, since the lawyers get a bit antsy) abuse desk folks from ISPs like to talk about putting together a training session about how to build and present an effective network abuse case to an ISP/LEA? From markjr at easydns.com Sat Oct 4 20:37:44 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Sat, 04 Oct 2008 21:37:44 -0400 Subject: gmail or google postmaster around? Message-ID: <48E81A68.3060308@easydns.com> Is there a google or gmail postmaster about? Please contact me offlist, thx -mark -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From markjr at easydns.com Sat Oct 4 21:01:53 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Sat, 04 Oct 2008 22:01:53 -0400 Subject: Nevermind (was Re: gmail or google postmaster around?) In-Reply-To: <48E81A68.3060308@easydns.com> References: <48E81A68.3060308@easydns.com> Message-ID: <48E82011.3050504@easydns.com> Sorry. Disregard. Mark Jeftovic wrote: > > Is there a google or gmail postmaster about? > > Please contact me offlist, thx > > -mark > -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From tony at swalter.com Sun Oct 5 11:20:00 2008 From: tony at swalter.com (Tony Patti) Date: Sun, 5 Oct 2008 16:20:00 +0000 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) Message-ID: <20081005162019.135541F8056@smtp01.swalter.com> I presume this CNN article falls within the "Internet operational and technical issues" (especially security) criteria of the NANOG AUP, in terms of "operat[ing] an Internet connected network", especially where Chertoff refers to " like an anti-aircraft weapon, shoot down an [Internet] attack before it hits its target". http://www.cnn.com/2008/TECH/10/04/chertoff.cyber.security/index.html Homeland Security seeks cyber counterattack system WASHINGTON (CNN) -- First, there was "Einstein," the federal government's effort to protect itself from cyber attacks by limiting the number of portals to government computer systems and searching for signs of cyber tampering. Then Einstein 2.0, a system now being tested to detect computer intrusions as they happen. And in the future? Perhaps Einstein 3.0, which would give the government the ability to fight back. Homeland Security Secretary Michael Chertoff on Friday said he'd like to see a government computer infrastructure that could look for early indications of computer skullduggery and stop it before it happens. The system "would literally, like an anti-aircraft weapon, shoot down an attack before it hits its target," he said. "And that's what we call Einstein 3.0." At a meeting with reporters to highlight National Cyber Security Month, Chertoff reiterated his belief that the government should aggressively defend its computer systems, saying that terrorists, if they gain expertise already available to others, would "cause potentially very serious havoc" to government systems. "Let's make the investment now rather than wait until there's a huge catastrophe," he said. But despite his emphasis on the risks posed, Chertoff said the government is moving slowly to avoid stepping on the toes of the private sector as it addresses calls to reorganize the governance of cyberspace to provide accountability and authority. "I think the question of what is the government's role in cyberspace in general needs to be discussed among all the stakeholders, because there is a culture of cyberspace that is an open architecture," he said. "And I think if we just came in and said we want to take it over, there'd be, understandably, a considerable amount of discomfort with that." "We are deliberately going slowly because we recognize that the issue of government involvement in the Internet is fraught with all kinds of potential concerns and potential anxieties about not having the government have a big-foot impact on an area of communication and commerce that has traditionally been viewed as really independent and free." Chertoff said the government is "feeling our way to what is the right mix of government involvement with protecting the Internet in the private domain while preserving everybody's comfort level that we're not going to be in their business in a way that would be inappropriate." Asked if he envisioned a world with two cyberspaces, he said he envisions a world with "a lot of different levels of security and trust, depending upon the nature of what it is that you're doing." "We already have that now, in the sense that we have classified systems which are walled off from unclassified systems," he said. The Bush administration released its National Cyber Security Initiative in January. The "most immediate component" of it from the Department of Homeland Security's perspective, Chertoff said, is to increase security for federal government computer systems. But another priority is to work with the private sector to address threats to businesses. This includes not only protection from hackers, but also from counterfeit parts, which an individual or another nation could use to create vulnerabilities in the United States, he said. E-mail to a friend Tony Patti CIO S. Walter Packaging Corp. From joelja at bogus.com Sun Oct 5 11:46:34 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 05 Oct 2008 09:46:34 -0700 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <20081005162019.135541F8056@smtp01.swalter.com> References: <20081005162019.135541F8056@smtp01.swalter.com> Message-ID: <48E8EF6A.5040908@bogus.com> Tony Patti wrote: > I presume this CNN article falls within the "Internet operational and technical issues" (especially security) criteria of the NANOG AUP, > in terms of "operat[ing] an Internet connected network", > especially where Chertoff refers to " like an anti-aircraft weapon, shoot down an [Internet] attack before it hits its target". > The system "would literally, like an anti-aircraft weapon, shoot down an attack before it hits its target," he said. "And that's what we call Einstein 3.0." http://en.wikipedia.org/wiki/Iran_Air_Flight_655 From hcb at netcases.net Sun Oct 5 12:21:08 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sun, 5 Oct 2008 13:21:08 -0400 Subject: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <48E8EF6A.5040908@bogus.com> References: <20081005162019.135541F8056@smtp01.swalter.com> <48E8EF6A.5040908@bogus.com> Message-ID: <4962A3890C344066BD3096AF0CCBD7BE@HDESK1> I'm not sure that this may not be veering into political OT, but, to the extent that proactive and automated reaction tools are being considered, even as benign as internal blackhole route generation, it may be worth discussing cases where, for various reasons, an automated defense system did not operate and people died. >From a technical perspective, the Iran Air shootdown probably would not have happened, rather like Chernobyl, if there hadn't been humans in the loop overriding safeguards and making determinations of threats. In particular, if one wanted to look at a technical parallel that actually might be useful in network operations, part of the Iran Air disaster was that the decisions were all being made at one point, the ship that actually fired the missiles. Think centralized routing. Now, there's a military technique called Cooperative Engagement Capability that I liken to link state routing; it's a distributed computation model where each participating ship, radar aircraft, etc., gets the sensor information from the others, and the decisionmaking can become much more precise. In the Iran Air incident, at least one other U.S. ship had radar tracking on the airliner and was trying to warn that it was not a valid target. I'm saying this technically and from a standpoint of fault analysis avoidance, not politics. Just as the USS Vincennes' captain caused a disaster by deciding to fire on a very questionable target, the USS Stark took missile hits because the captain had not turned on the missile defenses. The one SCUD hit in the Gulf War that caused major casualties was not engaged at all, apparently from a mixture of one radar being down for maintenance while the backup had not received a software patch to deal with a clock synchronization bug; the bug caused the radar to decide the incoming missile was an artifact and it was removed from the target list. Less seriously, my first reaction to Chertoff's statement is that the antiaircraft barrage already exists, is called Windows XP Pro Service Pack 3, which is sufficiently fanatical on my machine that its uninstaller committed suicide. -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Sunday, October 05, 2008 12:47 PM To: Tony Patti Cc: nanog at nanog.org Subject: Re: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) Tony Patti wrote: > I presume this CNN article falls within the "Internet operational and technical issues" (especially security) criteria of the NANOG AUP, > in terms of "operat[ing] an Internet connected network", > especially where Chertoff refers to " like an anti-aircraft weapon, shoot down an [Internet] attack before it hits its target". > The system "would literally, like an anti-aircraft weapon, shoot down an attack before it hits its target," he said. "And that's what we call Einstein 3.0." http://en.wikipedia.org/wiki/Iran_Air_Flight_655 From xploitable at gmail.com Sun Oct 5 12:30:11 2008 From: xploitable at gmail.com (n3td3v) Date: Sun, 5 Oct 2008 18:30:11 +0100 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <20081005162019.135541F8056@smtp01.swalter.com> References: <20081005162019.135541F8056@smtp01.swalter.com> Message-ID: <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> Bad idea, The rogue government would use hospitals and power stations, to "cyber human shield" against the counter attack. You guys are living in cloud cuckoo land. The rogue government wouldn't have their bot nets in home computers that you could shut down easily. Read my rant about it all with the link below that I typed in May 2008 to stop the "Afcyber" idea going through. http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062517.html All the best, n3td3v ---------- Forwarded message ---------- From: Tony Patti Date: Sun, Oct 5, 2008 at 5:20 PM Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) To: "nanog at nanog.org" I presume this CNN article falls within the "Internet operational and technical issues" (especially security) criteria of the NANOG AUP, in terms of "operat[ing] an Internet connected network", especially where Chertoff refers to " like an anti-aircraft weapon, shoot down an [Internet] attack before it hits its target". http://www.cnn.com/2008/TECH/10/04/chertoff.cyber.security/index.html Homeland Security seeks cyber counterattack system WASHINGTON (CNN) -- First, there was "Einstein," the federal government's effort to protect itself from cyber attacks by limiting the number of portals to government computer systems and searching for signs of cyber tampering. Then Einstein 2.0, a system now being tested to detect computer intrusions as they happen. And in the future? Perhaps Einstein 3.0, which would give the government the ability to fight back. Homeland Security Secretary Michael Chertoff on Friday said he'd like to see a government computer infrastructure that could look for early indications of computer skullduggery and stop it before it happens. The system "would literally, like an anti-aircraft weapon, shoot down an attack before it hits its target," he said. "And that's what we call Einstein 3.0." At a meeting with reporters to highlight National Cyber Security Month, Chertoff reiterated his belief that the government should aggressively defend its computer systems, saying that terrorists, if they gain expertise already available to others, would "cause potentially very serious havoc" to government systems. "Let's make the investment now rather than wait until there's a huge catastrophe," he said. But despite his emphasis on the risks posed, Chertoff said the government is moving slowly to avoid stepping on the toes of the private sector as it addresses calls to reorganize the governance of cyberspace to provide accountability and authority. "I think the question of what is the government's role in cyberspace in general needs to be discussed among all the stakeholders, because there is a culture of cyberspace that is an open architecture," he said. "And I think if we just came in and said we want to take it over, there'd be, understandably, a considerable amount of discomfort with that." "We are deliberately going slowly because we recognize that the issue of government involvement in the Internet is fraught with all kinds of potential concerns and potential anxieties about not having the government have a big-foot impact on an area of communication and commerce that has traditionally been viewed as really independent and free." Chertoff said the government is "feeling our way to what is the right mix of government involvement with protecting the Internet in the private domain while preserving everybody's comfort level that we're not going to be in their business in a way that would be inappropriate." Asked if he envisioned a world with two cyberspaces, he said he envisions a world with "a lot of different levels of security and trust, depending upon the nature of what it is that you're doing." "We already have that now, in the sense that we have classified systems which are walled off from unclassified systems," he said. The Bush administration released its National Cyber Security Initiative in January. The "most immediate component" of it from the Department of Homeland Security's perspective, Chertoff said, is to increase security for federal government computer systems. But another priority is to work with the private sector to address threats to businesses. This includes not only protection from hackers, but also from counterfeit parts, which an individual or another nation could use to create vulnerabilities in the United States, he said. E-mail to a friend Tony Patti CIO S. Walter Packaging Corp. From deleskie at gmail.com Sun Oct 5 12:42:14 2008 From: deleskie at gmail.com (jim deleskie) Date: Sun, 5 Oct 2008 14:42:14 -0300 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> References: <20081005162019.135541F8056@smtp01.swalter.com> <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> Message-ID: There is no need to attack the attacking computers.. this would be a mostly useless process and you'd always miss some. if the 'attacks' could not be filtered the 'external' to that nations links would be 'cut' the internet would be segmented and would could all go back to our regularly planed days. On Sun, Oct 5, 2008 at 2:30 PM, n3td3v wrote: > Bad idea, > > The rogue government would use hospitals and power stations, to "cyber > human shield" against the counter attack. > > You guys are living in cloud cuckoo land. The rogue government > wouldn't have their bot nets in home computers that you could shut > down easily. > > Read my rant about it all with the link below that I typed in May 2008 > to stop the "Afcyber" idea going through. > > http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062517.html > > All the best, > > n3td3v > > ---------- Forwarded message ---------- > From: Tony Patti > Date: Sun, Oct 5, 2008 at 5:20 PM > Subject: cnn.com - Homeland Security seeks cyber counterattack system > (Einstein 3.0) > To: "nanog at nanog.org" > > > I presume this CNN article falls within the "Internet operational and > technical issues" (especially security) criteria of the NANOG AUP, > in terms of "operat[ing] an Internet connected network", > especially where Chertoff refers to " like an anti-aircraft weapon, > shoot down an [Internet] attack before it hits its target". > > http://www.cnn.com/2008/TECH/10/04/chertoff.cyber.security/index.html > > Homeland Security seeks cyber counterattack system > > WASHINGTON (CNN) -- First, there was "Einstein," the federal > government's effort to protect itself from cyber attacks by limiting > the number of portals to government computer systems and searching for > signs of cyber tampering. > > Then Einstein 2.0, a system now being tested to detect computer > intrusions as they happen. > > And in the future? Perhaps Einstein 3.0, which would give the > government the ability to fight back. > > Homeland Security Secretary Michael Chertoff on Friday said he'd like > to see a government computer infrastructure that could look for early > indications of computer skullduggery and stop it before it happens. > > The system "would literally, like an anti-aircraft weapon, shoot down > an attack before it hits its target," he said. "And that's what we > call Einstein 3.0." > > At a meeting with reporters to highlight National Cyber Security > Month, Chertoff reiterated his belief that the government should > aggressively defend its computer systems, saying that terrorists, if > they gain expertise already available to others, would "cause > potentially very serious havoc" to government systems. > > "Let's make the investment now rather than wait until there's a huge > catastrophe," he said. > > But despite his emphasis on the risks posed, Chertoff said the > government is moving slowly to avoid stepping on the toes of the > private sector as it addresses calls to reorganize the governance of > cyberspace to provide accountability and authority. > > "I think the question of what is the government's role in cyberspace > in general needs to be discussed among all the stakeholders, because > there is a culture of cyberspace that is an open architecture," he > said. "And I think if we just came in and said we want to take it > over, there'd be, understandably, a considerable amount of discomfort > with that." > > "We are deliberately going slowly because we recognize that the issue > of government involvement in the Internet is fraught with all kinds of > potential concerns and potential anxieties about not having the > government have a big-foot impact on an area of communication and > commerce that has traditionally been viewed as really independent and > free." > > Chertoff said the government is "feeling our way to what is the right > mix of government involvement with protecting the Internet in the > private domain while preserving everybody's comfort level that we're > not going to be in their business in a way that would be > inappropriate." > > Asked if he envisioned a world with two cyberspaces, he said he > envisions a world with "a lot of different levels of security and > trust, depending upon the nature of what it is that you're doing." > > "We already have that now, in the sense that we have classified > systems which are walled off from unclassified systems," he said. > The Bush administration released its National Cyber Security > Initiative in January. The "most immediate component" of it from the > Department of Homeland Security's perspective, Chertoff said, is to > increase security for federal government computer systems. > > But another priority is to work with the private sector to address > threats to businesses. This includes not only protection from hackers, > but also from counterfeit parts, which an individual or another nation > could use to create vulnerabilities in the United States, he said. > E-mail to a friend > > > Tony Patti > CIO > S. Walter Packaging Corp. > > From markjr at easydns.com Sun Oct 5 12:43:15 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Sun, 5 Oct 2008 13:43:15 -0400 Subject: Comcast postmasters please? Message-ID: <9B2BC123-DE19-4FD2-AA09-CC91A6348653@easydns.com> can somebody contact me offlist? Sent from my iPhone From jfmezei at vaxination.ca Sun Oct 5 14:17:18 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sun, 05 Oct 2008 15:17:18 -0400 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: References: <20081005162019.135541F8056@smtp01.swalter.com> <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> Message-ID: <48E912BE.9000408@vaxination.ca> I have a big problem with politicians making technical decisions that may look good at the politicial level but make no sense at the technical level. "fighting back" implies that your own facilities will be busy pinging thousands of bots to death around the world. Yeah, smart. Looks good during a politician's speech, but in reality, what good does "fighting back" do when the remote computers won't be hurt by it ? I think the speech would have far more credibility if the politician had used terms such as "dynamic protection against attacks" where the network would reconfigure itself dynamically to block attacks etc etc. From LarrySheldon at cox.net Sun Oct 5 14:29:22 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sun, 05 Oct 2008 14:29:22 -0500 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <48E912BE.9000408@vaxination.ca> References: <20081005162019.135541F8056@smtp01.swalter.com> <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> <48E912BE.9000408@vaxination.ca> Message-ID: <48E91592.4070802@cox.net> Jean-Fran?ois Mezei wrote: > I have a big problem with politicians making technical decisions that > may look good at the politicial level but make no sense at the technical > level. Works in the financial world, doesn't it. -- Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From xploitable at gmail.com Sun Oct 5 14:53:27 2008 From: xploitable at gmail.com (n3td3v) Date: Sun, 5 Oct 2008 20:53:27 +0100 Subject: [Full-disclosure] Fwd: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <8a6b8e350810051046g5003d16dof0c8e7a0f0d861a5@mail.gmail.com> References: <20081005162019.135541F8056@smtp01.swalter.com> <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> <8a6b8e350810051046g5003d16dof0c8e7a0f0d861a5@mail.gmail.com> Message-ID: <4b6ee9310810051253p34b019favf0a51af9009f11ae@mail.gmail.com> Yes, they put these bizarre ideas out there to see what public opinion is, they don't have a chance in hell of implementing it. On Sun, Oct 5, 2008 at 6:46 PM, James Matthews wrote: > They generally don't have any clue what they want. This is only a PR stunt > > On Sun, Oct 5, 2008 at 10:30 AM, n3td3v wrote: >> >> Bad idea, >> >> The rogue government would use hospitals and power stations, to "cyber >> human shield" against the counter attack. >> >> You guys are living in cloud cuckoo land. The rogue government >> wouldn't have their bot nets in home computers that you could shut >> down easily. >> >> Read my rant about it all with the link below that I typed in May 2008 >> to stop the "Afcyber" idea going through. >> >> http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062517.html >> >> All the best, >> >> n3td3v >> >> ---------- Forwarded message ---------- >> From: Tony Patti >> Date: Sun, Oct 5, 2008 at 5:20 PM >> Subject: cnn.com - Homeland Security seeks cyber counterattack system >> (Einstein 3.0) >> To: "nanog at nanog.org" >> >> >> I presume this CNN article falls within the "Internet operational and >> technical issues" (especially security) criteria of the NANOG AUP, >> in terms of "operat[ing] an Internet connected network", >> especially where Chertoff refers to " like an anti-aircraft weapon, >> shoot down an [Internet] attack before it hits its target". >> >> http://www.cnn.com/2008/TECH/10/04/chertoff.cyber.security/index.html >> >> Homeland Security seeks cyber counterattack system >> >> WASHINGTON (CNN) -- First, there was "Einstein," the federal >> government's effort to protect itself from cyber attacks by limiting >> the number of portals to government computer systems and searching for >> signs of cyber tampering. >> >> Then Einstein 2.0, a system now being tested to detect computer >> intrusions as they happen. >> >> And in the future? Perhaps Einstein 3.0, which would give the >> government the ability to fight back. >> >> Homeland Security Secretary Michael Chertoff on Friday said he'd like >> to see a government computer infrastructure that could look for early >> indications of computer skullduggery and stop it before it happens. >> >> The system "would literally, like an anti-aircraft weapon, shoot down >> an attack before it hits its target," he said. "And that's what we >> call Einstein 3.0." >> >> At a meeting with reporters to highlight National Cyber Security >> Month, Chertoff reiterated his belief that the government should >> aggressively defend its computer systems, saying that terrorists, if >> they gain expertise already available to others, would "cause >> potentially very serious havoc" to government systems. >> >> "Let's make the investment now rather than wait until there's a huge >> catastrophe," he said. >> >> But despite his emphasis on the risks posed, Chertoff said the >> government is moving slowly to avoid stepping on the toes of the >> private sector as it addresses calls to reorganize the governance of >> cyberspace to provide accountability and authority. >> >> "I think the question of what is the government's role in cyberspace >> in general needs to be discussed among all the stakeholders, because >> there is a culture of cyberspace that is an open architecture," he >> said. "And I think if we just came in and said we want to take it >> over, there'd be, understandably, a considerable amount of discomfort >> with that." >> >> "We are deliberately going slowly because we recognize that the issue >> of government involvement in the Internet is fraught with all kinds of >> potential concerns and potential anxieties about not having the >> government have a big-foot impact on an area of communication and >> commerce that has traditionally been viewed as really independent and >> free." >> >> Chertoff said the government is "feeling our way to what is the right >> mix of government involvement with protecting the Internet in the >> private domain while preserving everybody's comfort level that we're >> not going to be in their business in a way that would be >> inappropriate." >> >> Asked if he envisioned a world with two cyberspaces, he said he >> envisions a world with "a lot of different levels of security and >> trust, depending upon the nature of what it is that you're doing." >> >> "We already have that now, in the sense that we have classified >> systems which are walled off from unclassified systems," he said. >> The Bush administration released its National Cyber Security >> Initiative in January. The "most immediate component" of it from the >> Department of Homeland Security's perspective, Chertoff said, is to >> increase security for federal government computer systems. >> >> But another priority is to work with the private sector to address >> threats to businesses. This includes not only protection from hackers, >> but also from counterfeit parts, which an individual or another nation >> could use to create vulnerabilities in the United States, he said. >> E-mail to a friend >> >> >> Tony Patti >> CIO >> S. Walter Packaging Corp. >> >> _______________________________________________ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ > > > > -- > http://www.goldwatches.com/ > > http://www.jewelerslounge.com/ > From markjr at easydns.com Sun Oct 5 18:56:08 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Sun, 05 Oct 2008 19:56:08 -0400 Subject: comcast postmaster? Message-ID: <48E95418.4060502@easydns.com> Anybody ever have any luck reaching out to comcast mail ops here? I'd really like to open a conversation with one offlist. -mark -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From mawatari at jpix.ad.jp Mon Oct 6 03:58:19 2008 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Mon, 06 Oct 2008 17:58:19 +0900 Subject: JANOG's English Page Update Message-ID: <20081006175150.599F.8FE1F57E@jpix.ad.jp> Dear NANOG Colleagues, We have updated JANOG (Japan Network Operators' Group) English wiki page. Recent additions include presentation titles and abstracts for the JANOG22 meeting, which was held July 2008. You can view the contents via the link below. http://www.janog.gr.jp/en/index.php?JANOG22%20Programs For us to bring better content, your comments and feedbacks are greatly appreciated. Regards, MAWATARI Masataka, for JANOG i18n Team From bill at edisys.co.uk Mon Oct 6 06:39:04 2008 From: bill at edisys.co.uk (William Hamilton) Date: Mon, 6 Oct 2008 12:39:04 +0100 (BST) Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <20081005162019.135541F8056@smtp01.swalter.com> References: <20081005162019.135541F8056@smtp01.swalter.com> Message-ID: <33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> > The system "would literally, like an anti-aircraft weapon, shoot down an > attack before it hits its target," he said. "And that's what we call > Einstein 3.0." Oh dear. I cringe whenever I read such a massacre of correct English like this. If it's going to "literally" shot down an attack like an AA weapon, are they planning on physically launching projectiles at compromised machines across the world and destroying them? That really *would* be something worth seeing. B From the.lists at mgm51.com Mon Oct 6 06:42:45 2008 From: the.lists at mgm51.com (Mike M) Date: Mon, 06 Oct 2008 07:42:45 -0400 Subject: Go daddy mail services admin In-Reply-To: <48E660B1.70803@justinshore.com> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> <20081001141720.GA15221@redline.kinz.org> <48E660B1.70803@justinshore.com> Message-ID: <200810060742450568.003753E1@sentry.24cl.com> On 10/3/2008 at 1:13 PM Justin Shore wrote: |Jeff Kinz wrote: |> Based on their long term refusal to adjust their policy to |> conform to PBL intended usage of the list I suspect this |> issue cannot be corrected. The only answer I have found is |> to inform the affected people they have to move from GoDaddy |> to a company that does a better job to correct the problem. | |GoDaddy is about as worthless of a mail provider and it gets. I can't |count the number of times I've had customers get themselves blacklisted |by GoDaddy and not be able to get unlisted. Finding a contact number |for them used to be damn near impossible. Finding a competent mail |admin on the other end actually was impossible. My own company got |blacklisted by GoDaddy a little over a year ago. A user with an |infected laptop relayed infected email out through the corporate |firewall's NAT pool (no longer blindly permitted). GoDaddy's response? | The entire /24 used by our corporate firewall was blacklisted |intermittently for about 6 months. | |Our recommendation to our clients and our SP customers is to not use |GoDaddy's mail services. Pick a mail provider that's known for being |responsive. ============= I would add that Yahoo email should also be on that list of email providers to tell one's customers to avoid, for all the reasons mentioned above. Yahoo's email is especially bad around the area I live because the local DSL provider uses a re-branded Yahoo email service. It has become easier for me to walk to my neighbor's house and hand-deliver a letter, than to try sending an email to that neighbor's Yahoo email inbox. From nanog at headcandy.org Mon Oct 6 07:24:06 2008 From: nanog at headcandy.org (Steve Church) Date: Mon, 6 Oct 2008 08:24:06 -0400 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> References: <20081005162019.135541F8056@smtp01.swalter.com> <33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> Message-ID: I'm surprised that no one has made a Skynet reference yet, perhaps because such a reference would be trite and predictable. I'm feeling trite and predictable this morning, so allow me to be the first. Homeland Security is planning to launch Skynet. I hope you guys have your nuclear bunkers stocked with Ensure. We on this list might be all that's left after Judgement Day. > If it's going to "literally" shot down an attack like an AA weapon, are > they planning on physically launching projectiles at compromised machines > across the world and destroying them? Bill, they're probably planning on physically launching explosive projectiles at compromised users. /me dons his tinfoil hat Steve From hcb at netcases.net Mon Oct 6 07:40:35 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Mon, 6 Oct 2008 08:40:35 -0400 Subject: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: References: <20081005162019.135541F8056@smtp01.swalter.com><33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> Message-ID: -----Original Message----- From: Steve Church [mailto:nanog at headcandy.org] Sent: Monday, October 06, 2008 8:24 AM To: nanog at nanog.org Subject: Re: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) > If it's going to "literally" shot down an attack like an AA weapon, are > they planning on physically launching projectiles at compromised machines > across the world and destroying them? Bill, they're probably planning on physically launching explosive projectiles at compromised users. /me dons his tinfoil hat Steve [Howard C. Berkowitz] Not being able to resist, they may be thinking of physically launching compromised users at the assumed servers. As the circus owner pleaded with the Man Shot Out of the Cannon not to leave the show, he pointed out "It's very difficult to find a man of your caliber." (While that's Pythonesque rather than canonical Python, is there an equivalent to Godwin's Law for pythonisms? Alas, would it be applicable if the pythonism were issued by a government official?) Seriously, see U.S. Joint Publication 3-13, "Information Operations", p. 33 of the PDF at http://www.dtic.mil/doctrine/jel/new_pubs/jp3_13.pdf That is intended, of course, for an actual war situation. The more open literature on electronic warfare is also relevant to understand the less silly military views -- and I emphasize a warfare situation, not a persistent spammer, may the fleas of ten thousand camels infest his armpits. From rcorbin at TRAFFIQ.com Mon Oct 6 08:12:32 2008 From: rcorbin at TRAFFIQ.com (Raymond Corbin) Date: Mon, 6 Oct 2008 09:12:32 -0400 Subject: Go daddy mail services admin In-Reply-To: <200810060742450568.003753E1@sentry.24cl.com> Message-ID: GoDaddy never was that large of a problem..maybe things have changed in the passed few months? Every now and then they would do a /24 listing but usually removed it fairly easily. Maybe it wasn't noticeable in the environment that my old company had setup. 2.5million emails sent to a load balancer which sent to 1 of 8 outbound spam filtering gateways that rotated through a pool of ips once an hour (5ip's each). So if an IP was blacklisted usually we would get the complaint, take it out of rotation, and contact the party to find out why it was listed and take action to correct it. Or we will see one hour the queue gets huge and take a look at the emails that are sitting in the queue...if they are mostly directed at yahoo/Comcast/godaddy then they are likely blocking that IP address... Yahoo is tougher to get a hold of that's for sure...they use a different type of anti-spam system (not that I'm saying its really effective) that prioritizing / deprioritizing senders emails. At my old company I had dedicated/colo customer's setup domain keys, spf records, rDNS, and set their retry times to be short intervals at first then progressively longer ones so they retry for about two days. I found that over several days (if you aren't sending spam) the reputation seemed to start getting better and your emails were being delivered without 'depriortization' (which is those annoying 451 Message temporarily deferred notices). Now if you have a system where 360,000 pop3 users send mail through your network, generating about 2-2.5million emails a day, then a lot of those are likely towards Yahoo!. Make sure to separate forwarded mail (into your users inbox and then auto forwarded to user at freemail.com) from your customers manually sent emails. In some servers it is not really possible, so run some reports through the logs to find out who the top 10 recipients at yahoo is for a few days. Those are likely the ones receiving the spam and causing your system to have problems. Grep through your logs and find out who those emails were originally sent to and then forwarded & fix. Yahoo doesn't tell the difference between spam/forwarded spam :) Alternatively google around...the director of Anti-Spam at Yahoo has his email address on some mailing lists and posts to them....he's actually responsive (2days ish) and quite helpful (me != proxy). There are also several yahoo employees on nanog who are also tired of the issues sending email to Yahoo and can get some stuff done. -r -----Original Message----- From: Mike M [mailto:the.lists at mgm51.com] Sent: Monday, October 06, 2008 7:43 AM To: NANOG Subject: Re: Go daddy mail services admin On 10/3/2008 at 1:13 PM Justin Shore wrote: |Jeff Kinz wrote: |> Based on their long term refusal to adjust their policy to |> conform to PBL intended usage of the list I suspect this |> issue cannot be corrected. The only answer I have found is |> to inform the affected people they have to move from GoDaddy |> to a company that does a better job to correct the problem. | |GoDaddy is about as worthless of a mail provider and it gets. I can't |count the number of times I've had customers get themselves blacklisted |by GoDaddy and not be able to get unlisted. Finding a contact number |for them used to be damn near impossible. Finding a competent mail |admin on the other end actually was impossible. My own company got |blacklisted by GoDaddy a little over a year ago. A user with an |infected laptop relayed infected email out through the corporate |firewall's NAT pool (no longer blindly permitted). GoDaddy's response? | The entire /24 used by our corporate firewall was blacklisted |intermittently for about 6 months. | |Our recommendation to our clients and our SP customers is to not use |GoDaddy's mail services. Pick a mail provider that's known for being |responsive. ============= I would add that Yahoo email should also be on that list of email providers to tell one's customers to avoid, for all the reasons mentioned above. Yahoo's email is especially bad around the area I live because the local DSL provider uses a re-branded Yahoo email service. It has become easier for me to walk to my neighbor's house and hand-deliver a letter, than to try sending an email to that neighbor's Yahoo email inbox. From brandon at rd.bbc.co.uk Mon Oct 6 08:21:13 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 6 Oct 2008 14:21:13 +0100 (BST) Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) Message-ID: <200810061321.OAA09410@sunf10.rd.bbc.co.uk> > I'm feeling trite and > predictable this morning, so allow me to be the first. Homeland Security is > planning to launch Skynet. Too late, we did that already http://en.wikipedia.org/wiki/Skynet_(satellites) brandon From fergdawgster at gmail.com Mon Oct 6 12:17:37 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 6 Oct 2008 10:17:37 -0700 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: References: <20081005162019.135541F8056@smtp01.swalter.com> <33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> Message-ID: <6cd462c00810061017g6bfebac0vaaea7dc6e7e89e2e@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Oct 6, 2008 at 5:24 AM, Steve Church wrote: > I'm surprised that no one has made a Skynet reference yet, perhaps > because such a reference would be trite and predictable. I'm feeling > trite and > predictable this morning, so allow me to be the first. Homeland Security > is planning to launch Skynet. I hope you guys have your nuclear bunkers > stocked with Ensure. We on this list might be all that's left after > Judgement Day. > I guess you haven't heard about the "Server in the Sky": http://www.technovelgy.com/ct/Science-Fiction-News.asp?NewsNum=1405 :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI6kgoq1pz9mNUZTMRAs/3AKD02p1Mt+UL8SSEKnl0H/3Lx0lpYwCg06GM zZnHo2DydtR8ho/ZgcA41Js= =zpoo -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From warren at kumari.net Mon Oct 6 13:05:51 2008 From: warren at kumari.net (Warren Kumari) Date: Mon, 6 Oct 2008 14:05:51 -0400 Subject: NANOG 44 (Los Angeles): ISP Security BOF In-Reply-To: References: Message-ID: Hello all, NANOG 44 is now less than a week away. Here is the current program for the ISP Security BOF (NANOG 44, October 13, 2008, 4:30 PM - 6:00 PM) -- as always, the program at this point is still somewhat fluid and subject to change. ------------------------------------ 16:30 - 16:45: "Stealing the Internet" -- Anton Kapela In "Stealing the Internet" Kapela will describe a method where an attacker exploits the BGP routing system to facilitate transparent interception of IP packets. The method will be shown to function at a scale previously thought by many as unavailable. The talk highlights a new twist in sub-prefix hijacking that he demonstrated at Defcon 16: using intrinsic BGP logic to hijack network traffic and simultaneously create a 'bgp shunt towards the target network. This method will be shown to preserve end-to-end reachability while creating a virtual 'wire tap' at the attackers network. He'll cover additive TTL modification and transparent-origin-AS as a means for the attacker to obscure the interception. There will not be a live demonstration of the hijack or interception methods. -------------------------------------- 16:45 - 17:00: "An interim solution to the threat of DNS cache poisoning while waiting for DNSSEC". -- Rodney Joffe -------------------------------------- 17:00 - 17:15: "Next steps in IRR/X509" --Barry Raveendran Greene, Jason Schiller. ------------------------------------- 17:15 - 17:30: "Esthost's response to the 'Hostexploit report'" -- Konstantin Poltev (Esthost, Inc). We are still waiting for the official title / abstract for this talk, so this is a temporary title.... ------------------------------------ 17:30 - 17:45: "Early Survey Results and Some Attack Statistics" -- Danny McPherson. ------------------------------------- There are 15 minutes left over at the end of the agenda as I'm sure some talks will run over their alloted time. Hopefully this agenda is interesting and you are looking forward to the BOF.... See you there, W From Valdis.Kletnieks at vt.edu Mon Oct 6 13:37:44 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Oct 2008 14:37:44 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: Your message of "Sun, 05 Oct 2008 18:30:11 BST." <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> References: <20081005162019.135541F8056@smtp01.swalter.com> <4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> Message-ID: <48127.1223318264@turing-police.cc.vt.edu> On Sun, 05 Oct 2008 18:30:11 BST, n3td3v said: > You guys are living in cloud cuckoo land. The rogue government > wouldn't have their bot nets in home computers that you could shut > down easily. Which is easier to shut down, an attack coming from a relatively small number of /16s that belong to the government, or one coming from the same number of source nodes scattered *all* over Comcast and Verizon and BT and a few other major providers? Hint 1: Consider the number of entry points into your network for the two cases, especially if you are heavily peered with one or more of the source ISPs. Consider also the "shoot self in foot" outcome if you decide to block *all* of Comcast, Verizon, BT and the others.... Hint 2: If botnets in home computers were so easy to shut down, why are there so many miscreants still using them for nefarious purposes? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jfmezei at vaxination.ca Mon Oct 6 14:24:22 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Mon, 06 Oct 2008 15:24:22 -0400 Subject: cnn.com - Homeland Security seeks cyber counterattack system (Einstein 3.0) In-Reply-To: <33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> References: <20081005162019.135541F8056@smtp01.swalter.com> <33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> Message-ID: <48EA65E6.7010705@vaxination.ca> William Hamilton wrote: > If it's going to "literally" shot down an attack like an AA weapon, are > they planning on physically launching projectiles at compromised machines > across the world and destroying them? The politician saw the episode of Star Trek where "7 of 9" typed in a few computer commands which caused some massive electrical jolt to be emitted by the bad dude's keyboard a few light years away, knocking him out. So they immediately think that they can do the same to incapacitate those making attacks on USA govt systems :-) Of course, this means the USA government will require all the world's keyboards to be equipped with the 50,000 volt "this will shock you" devices that only the uSA government can trigger :-) In other words, the politician's words should be included in some comic book, but shouldn't be discussed seriously. From MatlockK at exempla.org Mon Oct 6 14:35:50 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 6 Oct 2008 13:35:50 -0600 Subject: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <48EA65E6.7010705@vaxination.ca> References: <20081005162019.135541F8056@smtp01.swalter.com><33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> <48EA65E6.7010705@vaxination.ca> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7037AF88E@LMC-MAIL2.exempla.org> "The system "would literally, like an anti-aircraft weapon, shoot down an attack before it hits its target," he said. "And that's what we call Einstein 3.0." Correct me if I'm wrong, but doesn't even a basic firewall or ACL provide the same functionality? Drop the packet, drop the attack? I'm in the wrong business if implementing a firewall can net me $millions$ by using appropriate buzzwords..... Ken Matlock Network Analyst (303) 467-4671 matlockk at exempla.org From matthew at eeph.com Mon Oct 6 14:57:39 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 06 Oct 2008 12:57:39 -0700 Subject: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7037AF88E@LMC-MAIL2.exempla.org> References: <20081005162019.135541F8056@smtp01.swalter.com><33939.83.104.210.137.1223293144.squirrel@shiva.edisys.co.uk> <48EA65E6.7010705@vaxination.ca> <4288131ED5E3024C9CD4782CECCAD2C7037AF88E@LMC-MAIL2.exempla.org> Message-ID: <48EA6DB3.6010404@eeph.com> Matlock, Kenneth L wrote: > "The system "would literally, like an anti-aircraft weapon, shoot down > an attack before it hits its target," he said. "And that's what we call > Einstein 3.0." > > Correct me if I'm wrong, but doesn't even a basic firewall or ACL > provide the same functionality? Drop the packet, drop the attack? I'm in > the wrong business if implementing a firewall can net me $millions$ by > using appropriate buzzwords..... It sounds like the first step for such a firewall vendor would be to pay the appropriate license fees for the Einstein name and likeness... Then a little IP address geo-location coupled to the launch system and you're set. Any collateral damage would be no worse than the sort that's been caused by real anti-aircraft weapons. Matthew Kaufman matthew at eeph.com http://www.matthew.at From gtb at slac.stanford.edu Mon Oct 6 15:09:38 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Mon, 6 Oct 2008 13:09:38 -0700 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <48127.1223318264@turing-police.cc.vt.edu> References: <20081005162019.135541F8056@smtp01.swalter.com><4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> <48127.1223318264@turing-police.cc.vt.edu> Message-ID: > Which is easier to shut down, an attack coming from a relatively small > number of /16s that belong to the government, or one coming from the > same number of source nodes scattered *all* over Comcast and Verizon > and BT and a few other major providers? > > Hint 1: Consider the number of entry points into your network > for the two cases, especially if you are heavily peered with one or more > of the source ISPs. The Federal Government (through its "Trusted Internet Connection" initiative) is trying to limit the number of entry points into the US Government networks. (As I recall from 4000 interconnects to around 50, where both numbers have a high percentage of politics in the error bar.) From shawn.somers at gmail.com Mon Oct 6 19:05:48 2008 From: shawn.somers at gmail.com (Shawn Somers) Date: Mon, 6 Oct 2008 17:05:48 -0700 Subject: NANOG Digest, Vol 9, Issue 18 In-Reply-To: References: Message-ID: <78ca0ff10810061705g39973ecem87deb2f27ff4ffa3@mail.gmail.com> Here's your Skynet Reference... I WORK for Skynet. And Yes, the parent company is Cyberdyne. -- Shawn Somers Systems Administrator Skynet BroadBand http://www.skynetbb.com > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Oct 2008 08:24:06 -0400 > From: "Steve Church" > Subject: Re: cnn.com - Homeland Security seeks cyber counterattack > system (Einstein 3.0) > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I'm surprised that no one has made a Skynet reference yet, perhaps because > such a reference would be trite and predictable. I'm feeling trite and > predictable this morning, so allow me to be the first. Homeland Security is > planning to launch Skynet. I hope you guys have your nuclear bunkers > stocked with Ensure. We on this list might be all that's left after > Judgement Day. > >> If it's going to "literally" shot down an attack like an AA weapon, are >> they planning on physically launching projectiles at compromised machines >> across the world and destroying them? > > Bill, they're probably planning on physically launching explosive > projectiles at compromised users. > > /me dons his tinfoil hat > > Steve > > > ------------------------------ From patrick at zill.net Mon Oct 6 22:45:15 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 06 Oct 2008 23:45:15 -0400 Subject: contracts and survivability of telecom sector Message-ID: <48EADB4B.3080509@zill.net> This evening I looked over the telecom companies that are my suppliers, or who supply my suppliers, etc. I noticed that all of them, including Level3 (stock symbol LVLT) have a lot of debt (finance.yahoo.com numbers): Company Name | Cash | Debt ATT | 1.63B | 80.13B Level3 | 666M | 6.84B Verizon | 2.07B | 43.11B Cogent | 129M | 330M Obviously there are other, important numbers and ratios, but I won't go into that here. As you know, there are supposedly huge problems with companies, even top-rated ones, in borrowing from the usual channels. If you assume for example, that Verizon has notes of 10-year terms, then (if the notes are spread evenly) they will need to borrow some $4Billion in the next 12 months. If the terms are a lot shorter, then the amount to borrow goes up significantly of course... My question: Are there any recommendations from an operational perspective, should one or more of these or other telecom companies have such problems? My belief at the moment, is that the risk is low, as operations will always continue running even during bankruptcies (as some may have already seen with other companies). I am not interested in financial prognostications, I am solely focused on operational issues that might affect e.g. connectivity. Cordially Patrick Giagnocavo patrick at zill.net From Valdis.Kletnieks at vt.edu Mon Oct 6 23:16:37 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 00:16:37 -0400 Subject: contracts and survivability of telecom sector In-Reply-To: Your message of "Mon, 06 Oct 2008 23:45:15 EDT." <48EADB4B.3080509@zill.net> References: <48EADB4B.3080509@zill.net> Message-ID: <75451.1223352997@turing-police.cc.vt.edu> On Mon, 06 Oct 2008 23:45:15 EDT, Patrick Giagnocavo said: > If you assume for example, that Verizon has notes of 10-year terms, then > (if the notes are spread evenly) they will need to borrow some $4Billion > in the next 12 months. Close but no cee-gar. They'll need to come up with $4B to pay off the notes. There's no requirement that they borrow to do it. They can do it out of their revenue stream, for instance, just like most people who have to make a mortgage payment will do so out of their paychecks, rather than borrowing to do it (and in fact, if a person or company is relying on borrowing to pay off previous debt, that's a Bad Sign). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From tomb at byrneit.net Tue Oct 7 01:21:58 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 6 Oct 2008 23:21:58 -0700 Subject: contracts and survivability of telecom sector In-Reply-To: <75451.1223352997@turing-police.cc.vt.edu> References: <48EADB4B.3080509@zill.net> <75451.1223352997@turing-police.cc.vt.edu> Message-ID: <70D072392E56884193E3D2DE09C097A9F6A9@pascal.zaphodb.org> To some extent, you're both right. I actually have some background in this, so bear with me. The telecom business is, fundamentally, about wringing as much marginal additional cash flow out of your fixed infrastructure and operations costs as possible. There are variances around the margins, such as contribution margin of new services as they are marketed, but, fundamentally, it's about constraining fixed costs and driving revenue. One of the most important fixed costs is the leasing of the equipment, fees for rights of way, etc. Effectively, what has been the primary factor that drives the profitability of facilities based providers has been the spread between the leasing rates and the rates of return on capital their regulators have allowed them. Hence the description of facilities telcos as "rate factoring" businesses. When the cost of money goes up, as it does in the current credit crunch, it makes it next to impossible for facilities based providers to economically improve their facilities, given the relatively inelastic ROIC allowed by the PUCs. VZ has the cash flow, but they'll use it to pay off the notes, as opposed to roll over the notes and invest in the business, if the rate factor on the new credit is uneconomic. IOW, those selling gear to Telcos are in deep doo-doo. >-----Original Message----- >From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >Sent: Monday, October 06, 2008 9:17 PM >To: Patrick Giagnocavo >Cc: nanog at nanog.org >Subject: Re: contracts and survivability of telecom sector > >On Mon, 06 Oct 2008 23:45:15 EDT, Patrick Giagnocavo said: > >> If you assume for example, that Verizon has notes of 10-year terms, >> then (if the notes are spread evenly) they will need to borrow some >> $4Billion in the next 12 months. > >Close but no cee-gar. > >They'll need to come up with $4B to pay off the notes. There's no >requirement that they borrow to do it. They can do it out of their >revenue stream, for instance, just like most people who have to make a >mortgage payment will do so out of their paychecks, rather than >borrowing to do it (and in fact, if a person or company is relying on >borrowing to pay off previous debt, that's a Bad Sign). From michael.dillon at bt.com Tue Oct 7 05:00:20 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 7 Oct 2008 11:00:20 +0100 Subject: contracts and survivability of telecom sector In-Reply-To: <48EADB4B.3080509@zill.net> Message-ID: > Are there any recommendations from an operational > perspective, should one or more of these or other telecom > companies have such problems? Make sure that you have more than one upstream provider, preferably three providers minimum so that if one of them is suddenly shut off, you still have resiliency. In general, your upstream providers' operational networks and you, the customer connected to that operational network, are considered to be valuable assets so if a company falls into Chapter 11, there is a good chance that another company will acquire the assets. At the operational level, this is practically invisible until they start to consolidate data centers, prune unprofitable customers, etc. But, sometimes the financial community looks at an industry and decides that there is too much capacity chasing too few dollars, and the best solution for all concerned is for one of more companies to fail hard. This happened in Europe a few years ago when KPN-Qwest bought Ebone's pan-European backbone and then promptly declared bankruptcy. The receivers sent everyone home, shut down the power to all the sites, NOC included, and auctioned off all the equipment piecemeal, except for the fibre network. That went to another company that was also building a competing pan-European fibre network and which also went through a bankruptcy process, shed all its employees, and then was reborn. Not sure what happened to the customers in that case. So this could happen in the USA, and the solution is to spread the operational risk by maintaining 3, 4 or 5 upstream relationships. Don't risk losing 100% or even 50% of your connectivity. Get it down to 33% or 25% or 20% depending on what you can afford. Having a connection to a local Internet Exchange of some sort is probably a darn good idea. If you aren't peering with your local competitors, maybe you should start to do so, and reduce the risk to your community. In smaller markets, not NFL cities, maybe you should consider using different upstreams than your competitor to reduce the risk on a community-wide basis. Also, remember that this whole crisis could blow over in a few months, and if it does, you need to be prepared for increased traffic on your network, increased customer connections, etc. That too, is a risk to evaluate. --Michael Dillon From eric at roxanne.org Tue Oct 7 08:32:38 2008 From: eric at roxanne.org (Eric Gauthier) Date: Tue, 7 Oct 2008 09:32:38 -0400 Subject: Cogent backbone issue Message-ID: <20081007133238.GA22928@roxanne.org> Hello, Around 7:45am this morning, we started to see intermittent issues for some sites across Cogent's backbone. Their internal tracking number appears to be #800535. Does anyone have more information? Eric :) From zak at yellowfiber.net Tue Oct 7 09:15:24 2008 From: zak at yellowfiber.net (Zak Thompson) Date: Tue, 7 Oct 2008 10:15:24 -0400 Subject: Cogent backbone issue In-Reply-To: <20081007133238.GA22928@roxanne.org> References: <20081007133238.GA22928@roxanne.org> Message-ID: We started seeing issues around 6am in reston VA -Zak -----Original Message----- From: Eric Gauthier [mailto:eric at roxanne.org] Sent: Tuesday, October 07, 2008 9:33 AM To: nanog at nanog.org Subject: Cogent backbone issue Hello, Around 7:45am this morning, we started to see intermittent issues for some sites across Cogent's backbone. Their internal tracking number appears to be #800535. Does anyone have more information? Eric :) From Valdis.Kletnieks at vt.edu Tue Oct 7 09:45:07 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 10:45:07 -0400 Subject: contracts and survivability of telecom sector In-Reply-To: Your message of "Tue, 07 Oct 2008 11:00:20 BST." References: Message-ID: <13007.1223390707@turing-police.cc.vt.edu> On Tue, 07 Oct 2008 11:00:20 BST, michael.dillon at bt.com said: > In general, your upstream providers' operational networks > and you, the customer connected to that operational network, > are considered to be valuable assets so if a company falls > into Chapter 11, there is a good chance that another company > will acquire the assets. At the operational level, this is > practically invisible until they start to consolidate data > centers, prune unprofitable customers, etc. One special case to consider - your provider gets taken over, and the new owner regrooms the combined fiber networks, such that formerly physically diverse paths no longer are... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From joelja at bogus.com Tue Oct 7 10:25:48 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 07 Oct 2008 08:25:48 -0700 Subject: JANOG's English Page Update In-Reply-To: <20081006175150.599F.8FE1F57E@jpix.ad.jp> References: <20081006175150.599F.8FE1F57E@jpix.ad.jp> Message-ID: <48EB7F7C.6070304@bogus.com> Thank you, it is appreciated. Joel MAWATARI Masataka wrote: > Dear NANOG Colleagues, > > > We have updated JANOG (Japan Network Operators' Group) English wiki > page. > > > Recent additions include presentation titles and abstracts for the > JANOG22 meeting, which was held July 2008. > > You can view the contents via the link below. > > http://www.janog.gr.jp/en/index.php?JANOG22%20Programs > > > For us to bring better content, your comments and feedbacks are greatly > appreciated. > > > Regards, > MAWATARI Masataka, for JANOG i18n Team > > From sean at donelan.com Tue Oct 7 11:18:35 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 7 Oct 2008 12:18:35 -0400 (EDT) Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: References: <20081005162019.135541F8056@smtp01.swalter.com><4b6ee9310810051030q5bdffe58rc0d3cdb0cd8bbef9@mail.gmail.com> <48127.1223318264@turing-police.cc.vt.edu> Message-ID: <200810071215150.32BF5B92.25440@clifden.donelan.com> On Mon, 6 Oct 2008, Buhrmaster, Gary wrote: > The Federal Government (through its "Trusted Internet > Connection" initiative) is trying to limit the number > of entry points into the US Government networks. > (As I recall from 4000 interconnects to around 50, > where both numbers have a high percentage of politics > in the error bar.) Assuming you were on an advisory panel, what advice would you give the US Government how to protect and defend its networks and ability to maintain service? Most government networks and services depend on private network operators at some level. From sil at infiltrated.net Tue Oct 7 11:30:11 2008 From: sil at infiltrated.net (J. Oquendo) Date: Tue, 7 Oct 2008 11:30:11 -0500 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <200810071215150.32BF5B92.25440@clifden.donelan.com> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> Message-ID: <20081007163011.GA59690@infiltrated.net> On Tue, 07 Oct 2008, Sean Donelan wrote: > On Mon, 6 Oct 2008, Buhrmaster, Gary wrote: > >The Federal Government (through its "Trusted Internet > >Connection" initiative) is trying to limit the number > >of entry points into the US Government networks. > >(As I recall from 4000 interconnects to around 50, > >where both numbers have a high percentage of politics > >in the error bar.) > > Assuming you were on an advisory panel, what advice would you give > the US Government how to protect and defend its networks and ability > to maintain service? > > Most government networks and services depend on private network operators > at some level. > > Here is my take on this, recycling something I answered in similar context earlier today. Too many companies and individuals rely far too heavily on a false and outdated concept of the definition of "minimum requirements" when it comes to security. They tend to think they need to implement the minimum requirements and all will be fine. This is evident in almost all security management material I read where the goal is to offer a "mininum" set of requirements to meet guidelines and regulatory controls. What about exceeding the minimum requirements for a change. I associate "minimum requirements" with laziness especially when it comes to security. If companies structured their business a little better, it could be more beneficial for them to speak out and capitalize on security costs instead of worrying about the ROI on implementing security technologies and practices. This whole consensus about security not "making money" is flawed and the more people stick with their confirmation and status quo biases, the more businesses will NOT dish out for security causing headaches and financial misery along the way, it's self-induced. Can't wholly blame managers, a lot has to be weighed on the organizations around the world whose wordings have been taken out of context: e.g. "Under the proposal being considered, an independent audit would ensure that their networks are secure," he explained. "This audit process would work across business sectors, and would require companies to meet a minimum standard of security competency." (http://www.net-security.org/secworld.php?id=1731) Many have taken the attitude to implement enough to meet MINIMUM standards and this seems to be enough for them. Then some wonder why systems get compromised. Concepts are taken out of context. Just because an organization makes a recommendation on what should be a "minimum", shouldn't mean companies or governments should put in solely enough to meet compliance and guidelines. Businesses and governments in this day and age should be going above and beyond to protect not only themselves, but their clients, infrastructure, investors, etc. Until then, we'll see the same, putting out *just* enough to flaunt a piece of paper: "Minimum requirements met" and nothing more. How is this security again? How is minimizing the connection points going to really stop someone from launching exploit A against a machine that hasn't been properly patched? Might stop someone from somewhere in China or so, but once an alternative entry point is found, that vulnerability is still ripe for the "hacking". =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, CNDA, CHFI, OSCP "A good district attorney can indict a ham sandwich if he wants to ... The accusations harm as much as the convictions ... they're obviously harmful or it wouldn't be news.." - John Carter wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From Valdis.Kletnieks at vt.edu Tue Oct 7 12:39:43 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 13:39:43 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: Your message of "Tue, 07 Oct 2008 11:30:11 CDT." <20081007163011.GA59690@infiltrated.net> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> Message-ID: <23112.1223401183@turing-police.cc.vt.edu> On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: > What about exceeding the minimum requirements for a change. It's like any other field - the customer wants more than the minimum, they'll have to pay more. Almost all contractors will at least act like they're trying to meet the local building codes, because that's a minimum requirement. It's the rare contractor indeed who will throw in the upgraded appliance package and real marble flooring for free... (I think you'll find that if somebody is actually willing to *pay* for more security, there's plenty of outfits who are more than happy to make it happen) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From tme at multicasttech.com Tue Oct 7 13:00:54 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 7 Oct 2008 14:00:54 -0400 Subject: Cogent backbone issue In-Reply-To: References: <20081007133238.GA22928@roxanne.org> Message-ID: <5E7D5D0D-5B91-43D8-AAF1-E7AE86737469@multicasttech.com> I had no connectivity to Cogent (not even the web site) at 6:59 to 7:15 AM EDT from Sprint EVD0 at National Airport in (near) DC. (That was all the time I had while I was trying onboard the plane.) At the same time, Netnod in Sweden did have connectivity to Cogent. Regards Marshall On Oct 7, 2008, at 10:15 AM, Zak Thompson wrote: > We started seeing issues around 6am in reston VA > > -Zak > > -----Original Message----- > From: Eric Gauthier [mailto:eric at roxanne.org] > Sent: Tuesday, October 07, 2008 9:33 AM > To: nanog at nanog.org > Subject: Cogent backbone issue > > Hello, > > Around 7:45am this morning, we started to see intermittent > issues for some sites across Cogent's backbone. Their > internal tracking number appears to be #800535. Does anyone > have more information? > > Eric :) > > From sean at donelan.com Tue Oct 7 13:07:04 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 7 Oct 2008 14:07:04 -0400 (EDT) Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <23112.1223401183@turing-police.cc.vt.edu> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> Message-ID: <200810071405120.32BF5B92.25928@clifden.donelan.com> On Tue, 7 Oct 2008, Valdis.Kletnieks at vt.edu wrote: > On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: >> What about exceeding the minimum requirements for a change. > (I think you'll find that if somebody is actually willing to *pay* for more > security, there's plenty of outfits who are more than happy to make it happen) What should the US Government buy for more security? And how can the US Government make sure they actually get what they are paying? From smb at cs.columbia.edu Tue Oct 7 13:13:08 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 7 Oct 2008 14:13:08 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <200810071405120.32BF5B92.25928@clifden.donelan.com> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> Message-ID: <20081007141308.585f09b7@cs.columbia.edu> On Tue, 7 Oct 2008 14:07:04 -0400 (EDT) Sean Donelan wrote: > On Tue, 7 Oct 2008, Valdis.Kletnieks at vt.edu wrote: > > On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: > >> What about exceeding the minimum requirements for a change. > > (I think you'll find that if somebody is actually willing to *pay* > > for more security, there's plenty of outfits who are more than > > happy to make it happen) > > What should the US Government buy for more security? And how can the > US Government make sure they actually get what they are paying? > > Right. The US government is a *huge* operation. Suppose you were the CIO or the CSO for the US government (excluding the classified stuff) -- what is the proper cybersecurity strategy? --Steve Bellovin, http://www.cs.columbia.edu/~smb From sil at infiltrated.net Tue Oct 7 13:23:20 2008 From: sil at infiltrated.net (J. Oquendo) Date: Tue, 7 Oct 2008 13:23:20 -0500 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <200810071405120.32BF5B92.25928@clifden.donelan.com> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> Message-ID: <20081007182320.GA63228@infiltrated.net> On Tue, 07 Oct 2008, Sean Donelan wrote: > On Tue, 7 Oct 2008, Valdis.Kletnieks at vt.edu wrote: > >On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: > >>What about exceeding the minimum requirements for a change. > >(I think you'll find that if somebody is actually willing to *pay* for more > >security, there's plenty of outfits who are more than happy to make it > >happen) > > What should the US Government buy for more security? And how can the US > Government make sure they actually get what they are paying? > > I apologize for being naive. I guess 1.5 billion allocated to one state's Cybersecurity initiative *really* isn't enough to purchase the necessary load balancers, firewalls and personnel to audit the infrastructure for that one state. Quote: "These include positions funded for Cyber Security (Public Service Account); the federal Disaster Preparedness Program (Weapons of Mass Destruction) through which the agency has granted over $1.5 billion in federal grant funds across the state; " http://www.budget.state.ny.us/budgetFP/spendingReductions/agencyPlansPDF/NYSOHS_FMP.pdf So much so (not enough) they've not looked into ramping UP their budget, but ramping it DOWN. My thought would be to review the entire network as a whole, instead of the bandaid approach we've been taking, start fresh. Look at what's currently in place, audit, assess, re-do until they get it right. Contractors should be held accountable for breaches in an infrastructure. Before awarding a contract, I would do my best to have the wording changed from "minimum requirements" to securest implementation. Whether this securest implementation took 5 new engineers to give a closer review, so be it. I'd have some form of interagency strategy of tiger teams in differing realms of government and perform war games testing amongst each others' networks. The theory would be if the best of the best in government can find a hole, so will an attacker. It could be incentive based where a monthly "DefGovCon" capture the flag like training would take place to ensure that security issues are discovered internally and defended against. Teams would get prizes or recognition. Our government has so many resources at its disposal there is no real reason I can see them not protecting themselves. What I do see is shifting of blame and responsibility. Ye old "Cover Your Ass" attitude. Accountability - it goes a long way with accounts receivable and accounts payable. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, CNDA, CHFI, OSCP "Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense." - Buddha http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From bburke at merit.edu Tue Oct 7 13:30:23 2008 From: bburke at merit.edu (Betty Burke) Date: Tue, 7 Oct 2008 14:30:23 -0400 (EDT) Subject: [NANOG-announce] Program Committee Nominations Message-ID: <909862128.2009731223404223525.JavaMail.root@crono> All: Just a reminder to get your Program Committee nominations into nominations at nanog.org. In just a few days the Merit team will be off to LA and NANOG44. While at the meeting we have many tasks that will take us away from email for a bit. We do not want to miss any one, so please take a moment in the next day or two to get those nominations and offers to serve into us!! Thanks in advance for your consideration and support. Sincerely, Betty Burke Merit/NANOG Project Manager Merit Network Inc. _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From hcb at netcases.net Tue Oct 7 13:44:21 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Tue, 7 Oct 2008 14:44:21 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattacksystem(Einstein 3.0) In-Reply-To: <23112.1223401183@turing-police.cc.vt.edu> References: <48127.1223318264@turing-police.cc.vt.edu><200810071215150.32BF5B92.25440@clifden.donelan.com><20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> Message-ID: <3BCC541AE9424EDCA5F2E6381E080B31@HDESK1> Superficially, one difference between government and business security programs is that government has intelligence agencies that they can draw upon for threat assessment. It is a separate question if intelligence agencies accurately determine certain threats, or if politicians pay attention to accurate assessments if the assessment conflicts with ideology or generic preconceptions. Seriously, one of the major problems in convincing businesses about a need for security is that many managers, sensitive to cost, do not see a real threat. If one broadens that to continuity of operations in general, those managers whose firms have survived major disasters tend to be far more in favor of disaster recovery planning. Unfortuately, many security technologists are in the unfortunate position of the parent trying to convince a child not to touch a hot stove, when they have never been burned. In my case, that is convincing a dearly beloved cat that the stovetop is not on the feasible route from point A to point B. While some use the analogy of herding cats, that is more appropriate with technical people than top managers. In the case of the latter, the analogy may be more akin to the lion, who woke one day, and strode through his domain. Encountering an antelope, he roared, "WHO IS KING OF THE JUNGLE?" The antelope quivered and said "you, mighty lion." He next encountered a gnu (no, it's not Gnu). Again, even the tougher beast said "You are the great one." The lion walked further, and met an elephant. As he started to say "WHO IS...", the elephant wrapped his trunk around him, whopped him into several trees, juggled him on his tusks, and then threw him into a mud wallow. Scrambling to avoid an indignant hippopotamus, the lion looked at the elephant and said "Gee, your Majesty, could you chill out a little?" -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, October 07, 2008 1:40 PM To: J. Oquendo Cc: nanog at nanog.org Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber counterattacksystem(Einstein 3.0) On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: > What about exceeding the minimum requirements for a change. It's like any other field - the customer wants more than the minimum, they'll have to pay more. Almost all contractors will at least act like they're trying to meet the local building codes, because that's a minimum requirement. It's the rare contractor indeed who will throw in the upgraded appliance package and real marble flooring for free... (I think you'll find that if somebody is actually willing to *pay* for more security, there's plenty of outfits who are more than happy to make it happen) From todd at renesys.com Tue Oct 7 13:47:06 2008 From: todd at renesys.com (Todd Underwood) Date: Tue, 7 Oct 2008 18:47:06 +0000 Subject: NANOG44 lightning talk -- submission open Message-ID: <20081007184706.GV20914@renesys.com> NANOG44 is fast approaching and I hope to see many of you in LA this weekend and next week. As many of you know, Lightning talks are an important part of NANOG. They are short talks, often topical or late-breaking, accepted just prior to or at the conference. Total time is 10 minutes, including questions. Lightning talks are a perfect opportunity to add something topical to the program, or get feedback on preliminary work that is not ready for a full half-hour presentation yet. Lightning talks can be sumbitted at: https://www.nanogpc.org/lightning/ using your nanogpc.org speaker account. The only thing required is a compelling abstract and the willingness to put together some slides at the last second. The program committee will select the first talks for monday's lightning talk session on sunday night, so now is the time to submit your talk. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog From Valdis.Kletnieks at vt.edu Tue Oct 7 13:55:46 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 14:55:46 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: Your message of "Tue, 07 Oct 2008 14:13:08 EDT." <20081007141308.585f09b7@cs.columbia.edu> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007141308.585f09b7@cs.columbia.edu> Message-ID: <27001.1223405746@turing-police.cc.vt.edu> On Tue, 07 Oct 2008 14:13:08 EDT, "Steven M. Bellovin" said: > Right. The US government is a *huge* operation. Suppose you were the > CIO or the CSO for the US government (excluding the classified stuff) > -- what is the proper cybersecurity strategy? Step 1: Figure out what I actually *have* already. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Oct 7 13:59:33 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 14:59:33 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: Your message of "Tue, 07 Oct 2008 13:23:20 CDT." <20081007182320.GA63228@infiltrated.net> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007182320.GA63228@infiltrated.net> Message-ID: <27146.1223405973@turing-police.cc.vt.edu> On Tue, 07 Oct 2008 13:23:20 CDT, "J. Oquendo" said: > Contractors should be held accountable for breaches in an > infrastructure. Before awarding a contract, I would do my best > to have the wording changed from "minimum requirements" to > securest implementation. Whether this securest implementation > took 5 new engineers to give a closer review, so be it. You don't want "the securest implementation". You want one that's "secure enough" while still allowing the job to get done. You also don't want to be *paying* for more security than you actually need. Note that the higher price paid to the vendor isn't the only added cost of too much security. (Consider - the *securest* firewall is a true airgap, where files are dropped on one side, and then must be manually vetted, copied to media, and physically transferred to the other side. Feel free to try to deploy a webserver in that environment - on *either* side of the airgap....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From fergdawgster at gmail.com Tue Oct 7 14:01:07 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 7 Oct 2008 12:01:07 -0700 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <27001.1223405746@turing-police.cc.vt.edu> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007141308.585f09b7@cs.columbia.edu> <27001.1223405746@turing-police.cc.vt.edu> Message-ID: <6cd462c00810071201q51265b2bocec4cb15f4b2552@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 7, 2008 at 11:55 AM, wrote: > On Tue, 07 Oct 2008 14:13:08 EDT, "Steven M. Bellovin" said: > >> Right. The US government is a *huge* operation. Suppose you were the >> CIO or the CSO for the US government (excluding the classified stuff) >> -- what is the proper cybersecurity strategy? > > Step 1: Figure out what I actually *have* already. > Step 2: Baseline your traffic patterns/usage. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI67Hsq1pz9mNUZTMRAmZ8AJ4laDWWB3fwLxxoh/UPcztosaJVagCeI6fL d+wsLTa0XlDQkE5LV/vtSOo= =J9y/ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From tme at multicasttech.com Tue Oct 7 14:05:00 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 7 Oct 2008 15:05:00 -0400 Subject: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <6cd462c00810071201q51265b2bocec4cb15f4b2552@mail.gmail.com> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007141308.585f09b7@cs.columbia.edu> <27001.1223405746@turing-police.cc.vt.edu> <6cd462c00810071201q51265b2bocec4cb15f4b2552@mail.gmail.com> Message-ID: <28C05421-3FA4-4C3B-9704-05E4AAD39461@multicasttech.com> On Oct 7, 2008, at 3:01 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Oct 7, 2008 at 11:55 AM, wrote: > >> On Tue, 07 Oct 2008 14:13:08 EDT, "Steven M. Bellovin" said: >> >>> Right. The US government is a *huge* operation. Suppose you were >>> the >>> CIO or the CSO for the US government (excluding the classified >>> stuff) >>> -- what is the proper cybersecurity strategy? Step 0. DON"T PANIC. >>> >> >> Step 1: Figure out what I actually *have* already. >> > > Step 2: Baseline your traffic patterns/usage. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFI67Hsq1pz9mNUZTMRAmZ8AJ4laDWWB3fwLxxoh/UPcztosaJVagCeI6fL > d+wsLTa0XlDQkE5LV/vtSOo= > =J9y/ > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > From darden at armc.org Tue Oct 7 14:18:05 2008 From: darden at armc.org (Patrick Darden) Date: Tue, 07 Oct 2008 15:18:05 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <20081007163011.GA59690@infiltrated.net> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> Message-ID: <48EBB5ED.9030108@armc.org> J. Oquendo wrote: > Too many companies and individuals rely far > too heavily on a false and outdated concept of the definition of > "minimum requirements" when it comes to security. They tend to > think they need to implement the minimum requirements and all will > be fine. This is evident in almost all security management material > I read where the goal is to offer a "mininum" set of requirements > to meet guidelines and regulatory controls. > > What about exceeding the minimum requirements for a change. What about an entirely different concept? I see a lot of network router/firewall admins make the mistake of closing certain known bad ports off. This mostly happens in a University-type situation, where it is necessary--or at least traditional--to have an open network. A network able to handle myriad new and changing protocols and services. This is the black-list approach. It is a fundamental approach to security that ends up with "minimum requirements" either met or exceeded, without any real effectiveness no matter what certain experts may claim. The acknowledged better path is using a white-list instead. Turn everything off by default. Turn off all ports on the router/firewall. Turn the ones back on that can be trusted, with as much control as you can throw in there--specifying endpoints and ports, using content inspection and ensuring protocols using higher layer proxy-type protocols. Modern firewalls can do all of this. This would lead to "maximum possible" security, regulated only by realities. Layer 9 and 10 being the biggies, although layer 1 and 2 are also important (money and politics). This would not work in an open environment with 30,000 new laptops coming in at the start of every summer, each running a different brand of Doom (pun intended). But if we are talking about a smaller number of stable networks that are meant primarily to interface with one-another and only network outside of themselves... (wait for it, not secondarily, not tertially, not even quartnearilly but instead) perhaps as the least important function, then we have something we can work with. These networks would be of Working machines. Primary purpose: work. Stability, functionality, security of data and communications.... Here you go, my incredibly naive take on it: 0. white list as the fundamental principle. maximum security. 1. you are starting with a mess. turn off all internetworking on a network, until it is compliant with the below. 2. separate the networks into discrete logical units (via function would be best, if realities such as location/bandwidth permit). 3. separate the workstations. 4. harden the workstations. turn off extra services. only install certain programs. make an image. shoot that image down every now and then to ensure compliance. 5. harden the networks. allow communication between networks only for certain services. specify endpoints and ports, use content inspection ensure protocol regulation. check logs for unregulated attempts to communicate between networks. 6. make sure you have adequate pc/networking/security admins to do this--and maintain it. Keeping it all up to date will be a big part of making sure it stays functional. 7. probably this should be #1 instead of #7--start with clear documentation for each of the above points, including assignation of responsibilities with job titles. --Patrick Darden From fergdawgster at gmail.com Tue Oct 7 14:31:07 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 7 Oct 2008 12:31:07 -0700 Subject: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <28C05421-3FA4-4C3B-9704-05E4AAD39461@multicasttech.com> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007141308.585f09b7@cs.columbia.edu> <27001.1223405746@turing-police.cc.vt.edu> <6cd462c00810071201q51265b2bocec4cb15f4b2552@mail.gmail.com> <28C05421-3FA4-4C3B-9704-05E4AAD39461@multicasttech.com> Message-ID: <6cd462c00810071231o50f02dd7l543612d64ab44050@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 7, 2008 at 12:05 PM, Marshall Eubanks wrote: > Step 0. DON"T PANIC. > Good point. Along the same line, I would like to point out this Ira Winkler article on the topic: "Not Much Genius in DHS's Einstein 3.0 Plan" http://www.internetevolution.com/author.asp?section_id=515&doc_id=165249 Especially the closing paragraph: "For everyone's protection, there should be requirements on the appropriate parties to remove offending systems from the Internet. Nobody has the right to endanger others. However, until Chertoff decides to push for this necessary measure, I recommend he pick up a few books on basic firewall security in the meantime." - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI67jzq1pz9mNUZTMRAs7FAJ4x4W5c3BziZU35R6FQvJXI5z2IZQCgrLm5 HwyiU+h4wElXQGLsN7O+Pao= =2OhO -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From deepak at ai.net Tue Oct 7 14:53:58 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 07 Oct 2008 15:53:58 -0400 Subject: contracts and survivability of telecom sector In-Reply-To: <13007.1223390707@turing-police.cc.vt.edu> References: <13007.1223390707@turing-police.cc.vt.edu> Message-ID: <48EBBE56.4050602@ai.net> > One special case to consider - your provider gets taken over, and the new owner > regrooms the combined fiber networks, such that formerly physically diverse > paths no longer are... These are lessons many learned 7 years ago... No circuit is "set and forget", including so-called "protected" services. The way long distance and international capacity is swapped/bartered/remarketed reminds me of the complaints about the current credit-default swap market (with all of the opacity!) If you care about your reliability/survivability, you have to watch all of the motions that an acquisition/transition will have on your infrastructure [not just your future needs, but your current ones]. In BK's, we've seen plenty of fiber providers hand over entrance facilities that they had previously constructed to new entities and contract back for the capacity they need. So it *looks* like the provider X build out to your facility is completely diverse from provider Y, but they are no longer diverse [with little -> no internal to the facility change]. Be careful out there... Deepak Jain AiNET From todd at renesys.com Tue Oct 7 15:07:43 2008 From: todd at renesys.com (Todd Underwood) Date: Tue, 7 Oct 2008 20:07:43 +0000 Subject: NANOG 45 Jan 25-28 in Santo Domingo, Dominican Republic Message-ID: <20081007200743.GY20914@renesys.com> NANOG45 will be held in the middle of the North American Winter in beautiful Santo Domingo in the Dominican republic on January 25-28. http://nanog.org/meetings/nanog45/ This is the first time that a NANOG has been held outside of the US or Canada and everyone involved is excited about the opportunity. It's just like Toronto in February (which was actually fantastic) but it's the Caribbean in January. :-) The Call for Presentations is already up: http://nanog.org/meetings/nanog45/callforpresent.php Presentations can be submitted at [4]http://www.nanogpc.org/ (please ignore the references to NANOG44--we'll change those references over to NANOG45 at the close of the NANOG44 conference). If you have a good idea for a presentation but need some feedback or some help developing it, please contact me and I'll be happy to either work directly with you or find someone else on the program committee to help you put together a presentation. We have already received a number of early submissions for NANOG45 so for the best chance to be accepted, please begin working on your presentations now. Thanks, Todd Underwood NANOG Program Committee Chair -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From Valdis.Kletnieks at vt.edu Tue Oct 7 15:14:17 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 16:14:17 -0400 Subject: OK, who's the idiot using tcwireless.us? Message-ID: <34803.1223410457@turing-police.cc.vt.edu> Somebody on the NANOG mailing list has their mail pointing to tcwireless.us, which is throwing challenge/response mail like the following: Your message From: Valdis.Kletnieks at vt.edu To: n3td3v Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber counterattack system ( Einstein 3.0) Date: 10/6/2008 has been just received by gmail.com mailserver. To prove that your message was sent by a human and not a computer, please visit the URL below and type in the alphanumeric text you will see in the image. You will be asked to do this only once for this recipient. http://mail.tcwireless.us/challenge/?folder=2008100614384085099427 Your message will be automatically deleted in a few days if you do not confirm this request. ===================================================== DO NOT REPLY TO THIS MESSAGE. NO ONE WILL RECEIVE IT. ===================================================== Note it says 'gmail.com mailserver'. Paul Ferguson reported to me that the one he saw said 'received by vt.edu mailserver'. Also note that the From/To has lost nanog at nanog.org - for both my note and Paul's (in fact, looking at Paul's actual posting and mine show nanog at nanog.org as being the only common link, thus the "must be a nanog subscriber" conclusion). Please, if you're going to use a C/R, at least learn how to whitelist the mailing lists you're on. And if you can't figure out how to do that, please do us all a favor and not try to run an operational network... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From hcb at netcases.net Tue Oct 7 15:16:22 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Tue, 7 Oct 2008 16:16:22 -0400 Subject: Some odd harvesting going on? Message-ID: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> I just received the following: Your message From: "Howard C. Berkowitz" To: Subject: RE: Fwd: cnn.com - Homeland Security seeks cyber counterattacksystem(Einstein 3.0) Date: 10/7/2008 has been just received by nanog.org mailserver. To prove that your message was sent by a human and not a computer, please visit the URL below and type in the alphanumeric text you will see in the image. You will be asked to do this only once for this recipient. http://mail.tcwireless.us/challenge/?folder=2008100714452628877295 Your message will be automatically deleted in a few days if you do not confirm this request. ===================================================== DO NOT REPLY TO THIS MESSAGE. NO ONE WILL RECEIVE IT. ===================================================== I don't have an appropriately air-gapped browser to visit that link, which rather screams "scam phish". Anyone know anythig about it? From chaim.rieger at gmail.com Tue Oct 7 15:19:48 2008 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Tue, 07 Oct 2008 13:19:48 -0700 Subject: OK, who's the idiot using tcwireless.us? In-Reply-To: <34803.1223410457@turing-police.cc.vt.edu> References: <34803.1223410457@turing-police.cc.vt.edu> Message-ID: <48EBC464.3030501@gmail.com> Valdis.Kletnieks at vt.edu wrote: > Somebody on the NANOG mailing list has their mail pointing to tcwireless.us, > which is throwing challenge/response mail like the following: > > > Your message > > From: Valdis.Kletnieks at vt.edu > To: n3td3v > Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber counterattack system ( > Einstein 3.0) > Date: 10/6/2008 > > has been just received by gmail.com mailserver. > i doubt that that person will see it, as you have yet to authenticate thyself. -- -- Chaim Rieger From tme at multicasttech.com Tue Oct 7 15:29:06 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 7 Oct 2008 16:29:06 -0400 Subject: Some odd harvesting going on? In-Reply-To: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> Message-ID: I received the same message Subject : Challenge Response Received: from mail.tcwireless.us ([67.108.86.20] verified) Your message ... has been just received by gmail.com mailserver. I assumed that this is a phishing scam due to the from / mailserver mismatch, which I think this confirms. Regards Marshall On Oct 7, 2008, at 4:16 PM, Howard C. Berkowitz wrote: > I just received the following: > > > > Your message > > > > From: "Howard C. Berkowitz" > > To: > > Subject: RE: Fwd: cnn.com - Homeland Security seeks cyber > counterattacksystem(Einstein 3.0) > > Date: 10/7/2008 > > > > has been just received by nanog.org mailserver. > > > > To prove that your message was sent by a human and not a computer, > please > visit the URL below and type in the alphanumeric text you will see > in the > image. You will be asked to do this only once for this recipient. > > > > http://mail.tcwireless.us/challenge/?folder=2008100714452628877295 > > > > Your message will be automatically deleted in a few days if you do not > confirm this request. > > > > ===================================================== > > DO NOT REPLY TO THIS MESSAGE. NO ONE WILL RECEIVE IT. > > ===================================================== > > > > I don't have an appropriately air-gapped browser to visit that link, > which > rather screams "scam phish". Anyone know anythig about it? > From fmoses at tctimes.com Tue Oct 7 16:02:12 2008 From: fmoses at tctimes.com (Fred Moses) Date: Tue, 7 Oct 2008 17:02:12 -0400 Subject: Some odd harvesting going on? In-Reply-To: Message-ID: cfdf01ac45f3fae2834bb6d8795e5fcb Apology to NANOG for the whitelist failing.. -------------------------------------------- Fredric S. Moses Chief Technology Officer,Tri-County Times fred.moses at tcwireless.us -----Original Message----- From: Marshall Eubanks [mailto:tme at multicasttech.com] Sent: Tuesday, October 07, 2008 4:29 PM To: Howard C. Berkowitz Cc: nanog at nanog.org Subject: Re: Some odd harvesting going on? I received the same message Subject : Challenge Response From mehmet at icann.org Tue Oct 7 16:09:44 2008 From: mehmet at icann.org (Mehmet Akcin) Date: Tue, 7 Oct 2008 14:09:44 -0700 Subject: NANOG 45 Jan 25-28 in Santo Domingo, Dominican Republic In-Reply-To: <20081007200743.GY20914@renesys.com> Message-ID: Finally a caribbean host.. :) and great timing of the year! Tried few years ago a meeting in San Juan, PR unfortunately couldn?t make it possible. Very well knowing how hard to satisfy certain needs of these kind of meetings, all kudos to the sponsors and merit! See ya all in santa domingo! Ohh wait, see you in la on Sunday first :-) -Mehmet From: Todd Underwood Date: Tue, 7 Oct 2008 13:07:43 -0700 To: Subject: NANOG 45 Jan 25-28 in Santo Domingo, Dominican Republic NANOG45 will be held in the middle of the North American Winter in beautiful Santo Domingo in the Dominican republic on January 25-28. http://nanog.org/meetings/nanog45/ This is the first time that a NANOG has been held outside of the US or Canada and everyone involved is excited about the opportunity. It's just like Toronto in February (which was actually fantastic) but it's the Caribbean in January. :-) The Call for Presentations is already up: http://nanog.org/meetings/nanog45/callforpresent.php Presentations can be submitted at [4]http://www.nanogpc.org/ (please ignore the references to NANOG44--we'll change those references over to NANOG45 at the close of the NANOG44 conference). If you have a good idea for a presentation but need some feedback or some help developing it, please contact me and I'll be happy to either work directly with you or find someone else on the program committee to help you put together a presentation. We have already received a number of early submissions for NANOG45 so for the best chance to be accepted, please begin working on your presentations now. Thanks, Todd Underwood NANOG Program Committee Chair -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3392 bytes Desc: not available URL: From hobbit at avian.org Tue Oct 7 15:11:26 2008 From: hobbit at avian.org (*Hobbit*) Date: Tue, 7 Oct 2008 20:11:26 +0000 (GMT) Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) Message-ID: <20081007201126.52EB87809@relayer.avian.org> We've got plenty of military toyz we could level at Redmond... _H* From hcb at netcases.net Tue Oct 7 16:25:04 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Tue, 7 Oct 2008 17:25:04 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cybercounterattack system(Einstein 3.0) In-Reply-To: <20081007201126.52EB87809@relayer.avian.org> References: <20081007201126.52EB87809@relayer.avian.org> Message-ID: This one? http://www.wired.com/science/discoveries/news/1998/07/13987 -----Original Message----- From: *Hobbit* [mailto:hobbit at avian.org] Sent: Tuesday, October 07, 2008 4:11 PM To: nanog at nanog.org Subject: Re: Fwd: cnn.com - Homeland Security seeks cybercounterattack system(Einstein 3.0) We've got plenty of military toyz we could level at Redmond... _H* From jfmezei at vaxination.ca Tue Oct 7 16:41:46 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Tue, 07 Oct 2008 17:41:46 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <200810071405120.32BF5B92.25928@clifden.donelan.com> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> Message-ID: <48EBD79A.5000902@vaxination.ca> I think I may have found a spin for the political statements: With the USA government so focused on blaming "axis of evil" countries for all its woes, perhaps the statement was really meant to say that should setup some botnet attack against our systems, the USA would retaliate by setting up a botnet attack against the own systems. Basically, if Canada were to send 6 billion mosquitoes to the USA to annoy the hell out of americans, the USA wouldn't bother attacking the mosquitoes, but would attack something valuable to canadians (like DDOS attack against the Tim Horton's web site). In other words, once they have concucted evidence that is behind a botnet attack against www.house.gov, then the USA would "attack" www.government. instead of attacking the individual computers that attack the USA. From surfer at mauigateway.com Tue Oct 7 16:54:33 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 7 Oct 2008 14:54:33 -0700 Subject: Fwd: cnn.com - Homeland Security seeks cybercounterattack system(Einstein 3.0) Message-ID: <20081007145433.D8404D96@resin18.mta.everyone.net> -------Original Message------- From: *Hobbit* [mailto:hobbit at avian.org] We've got plenty of military toyz we could level at Redmond... ------------------------------- ----- hcb at netcases.net wrote: ----- From: "Howard C. Berkowitz" This one? http://www.wired.com/science/discoveries/news/1998/07/13987 -------------------------------- This: http://upload.wikimedia.org/wikipedia/commons/5/57/USS_Yorktown.jpg was rendered unusable by a sh!++y OS? !!! BWAHAHAHAHA! GREAT link! I needed to smile as I constantly go through Micro$loth vs. *nix arguments here. :-) "Using Microsoft's Windows NT operating system in such a critical environment, some engineers said, was a bad move. " - The sky is blue, too. "Technically, Windows NT Server 4.0 is no match for any Unix operating system." - DUH! From Valdis.Kletnieks at vt.edu Tue Oct 7 17:00:08 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2008 18:00:08 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cybercounterattack system(Einstein 3.0) In-Reply-To: Your message of "Tue, 07 Oct 2008 14:54:33 PDT." <20081007145433.D8404D96@resin18.mta.everyone.net> References: <20081007145433.D8404D96@resin18.mta.everyone.net> Message-ID: <40741.1223416808@turing-police.cc.vt.edu> On Tue, 07 Oct 2008 14:54:33 PDT, Scott Weeks said: > http://upload.wikimedia.org/wikipedia/commons/5/57/USS_Yorktown.jpg > > was rendered unusable by a sh!++y OS? !!! To be fair, designing a system that could be dead in the water if one component bluescreened probably wasn't a wise idea either, and one totally separate from the actual choice of operating system. Even Solaris and AIX crash if sufficiently provoked. But it's no surprise that the same designers who created it with a single point of failure then turned around and implemented the critical component with likely-to-fail thechnology. "Windows NT 4.0 - the choice of unclued systems designers everywhere" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jeffshultz at wvi.com Tue Oct 7 17:04:05 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Tue, 07 Oct 2008 15:04:05 -0700 Subject: Fwd: cnn.com - Homeland Security seeks cybercounterattack system(Einstein 3.0) In-Reply-To: <20081007145433.D8404D96@resin18.mta.everyone.net> References: <20081007145433.D8404D96@resin18.mta.everyone.net> Message-ID: <48EBDCD5.8030302@wvi.com> Scott Weeks wrote: > > This: > > http://upload.wikimedia.org/wikipedia/commons/5/57/USS_Yorktown.jpg > > was rendered unusable by a sh!++y OS? !!! > > > > Um, no, that one was rendered unusable by Japanese bombs and torpedoes at Midway in 1942. This: http://en.wikipedia.org/wiki/USS_Yorktown_(CG-48) was what was taken down by Windows NT. -- Jeff Shultz From hcb at netcases.net Tue Oct 7 17:18:49 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Tue, 7 Oct 2008 18:18:49 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cybercounterattacksystem(Einstein 3.0) In-Reply-To: <20081007145433.D8404D96@resin18.mta.everyone.net> References: <20081007145433.D8404D96@resin18.mta.everyone.net> Message-ID: Ah, it's a bit worse. This is the ship that ran Windows. http://upload.wikimedia.org/wikipedia/commons/thumb/a/a1/USS_Yorktown_%28CG- 48%29%3B04014806.jpg/300px-USS_Yorktown_%28CG-48%29%3B04014806.jpg You have a picture of the World War II carrier. Now, this one, the second ship of the class, has been retired, but that's because it had old-style missile launchers that were not cost-effective to update. -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Tuesday, October 07, 2008 5:55 PM To: nanog at nanog.org Subject: RE: Fwd: cnn.com - Homeland Security seeks cybercounterattacksystem(Einstein 3.0) -------Original Message------- From: *Hobbit* [mailto:hobbit at avian.org] We've got plenty of military toyz we could level at Redmond... ------------------------------- ----- hcb at netcases.net wrote: ----- From: "Howard C. Berkowitz" This one? http://www.wired.com/science/discoveries/news/1998/07/13987 -------------------------------- This: http://upload.wikimedia.org/wikipedia/commons/5/57/USS_Yorktown.jpg was rendered unusable by a sh!++y OS? !!! BWAHAHAHAHA! GREAT link! I needed to smile as I constantly go through Micro$loth vs. *nix arguments here. :-) "Using Microsoft's Windows NT operating system in such a critical environment, some engineers said, was a bad move. " - The sky is blue, too. "Technically, Windows NT Server 4.0 is no match for any Unix operating system." - DUH! From hcb at netcases.net Tue Oct 7 17:19:59 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Tue, 7 Oct 2008 18:19:59 -0400 Subject: Fwd: cnn.com - Homeland Security seeks cybercounterattacksystem(Einstein 3.0) In-Reply-To: <40741.1223416808@turing-police.cc.vt.edu> References: <20081007145433.D8404D96@resin18.mta.everyone.net> <40741.1223416808@turing-police.cc.vt.edu> Message-ID: <15CF9F4F0DAE4EF5B9DCA33071CA0AEA@HDESK1> In patient care systems, we would convince the doctors that didn't want Linux by saying "would you like a blue screen of death to be literal?" -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, October 07, 2008 6:00 PM To: surfer at mauigateway.com Cc: nanog at nanog.org Subject: Re: Fwd: cnn.com - Homeland Security seeks cybercounterattacksystem(Einstein 3.0) On Tue, 07 Oct 2008 14:54:33 PDT, Scott Weeks said: > http://upload.wikimedia.org/wikipedia/commons/5/57/USS_Yorktown.jpg > > was rendered unusable by a sh!++y OS? !!! To be fair, designing a system that could be dead in the water if one component bluescreened probably wasn't a wise idea either, and one totally separate from the actual choice of operating system. Even Solaris and AIX crash if sufficiently provoked. But it's no surprise that the same designers who created it with a single point of failure then turned around and implemented the critical component with likely-to-fail thechnology. "Windows NT 4.0 - the choice of unclued systems designers everywhere" :) From markjr at easydns.com Tue Oct 7 17:57:20 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 07 Oct 2008 18:57:20 -0400 Subject: Yahoo postmaster around? Message-ID: <48EBE950.90908@easydns.com> Argghhh, the downside to migrating to new mailserver IPs is rebuilding your rep on the new IPs. Are there any Yahoo postmaster's around? Please contact me offlist, thx -mark -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From ge at linuxbox.org Tue Oct 7 19:31:07 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 7 Oct 2008 19:31:07 -0500 (CDT) Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <20081007141308.585f09b7@cs.columbia.edu> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007141308.585f09b7@cs.columbia.edu> Message-ID: On Tue, 7 Oct 2008, Steven M. Bellovin wrote: > On Tue, 7 Oct 2008 14:07:04 -0400 (EDT) > Sean Donelan wrote: > >> On Tue, 7 Oct 2008, Valdis.Kletnieks at vt.edu wrote: >>> On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: >>>> What about exceeding the minimum requirements for a change. >>> (I think you'll find that if somebody is actually willing to *pay* >>> for more security, there's plenty of outfits who are more than >>> happy to make it happen) >> >> What should the US Government buy for more security? And how can the >> US Government make sure they actually get what they are paying? >> >> > Right. The US government is a *huge* operation. Suppose you were the > CIO or the CSO for the US government (excluding the classified stuff) > -- what is the proper cybersecurity strategy? Quit. More seriously though, you are far more likely to be in charge of certifying products for acquisition, and run after the different offices, agencies and organizations for cooperation. So a first step would be to try and make yourself useful to them, and develop personal relationships with those who do want to work with you, in order to start facilitating information sharing and incident response. I'd also try and get as many logs, flows, etc. I can get and build a main monitoring system. Being in "charge" is simply not possible or practical. Following the networks is indeed the first step. Gadi. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From cdl at asgaard.org Tue Oct 7 17:05:20 2008 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Tue, 7 Oct 2008 15:05:20 -0700 Subject: OK, who's the idiot using tcwireless.us? In-Reply-To: <34803.1223410457@turing-police.cc.vt.edu> References: <34803.1223410457@turing-police.cc.vt.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I agree with Howard here, I don't think this is a mis-configuration, but a harvest attempt. The "mailserver" is in different messages, and I can't see how that could get misconfigured in a honest validation server. My guess is that someone is trolling the archives, and sending this back? Why, I have no idea, given they already can see the sending address. Chris On 07 Oct 2008, at 13.14, Valdis.Kletnieks at vt.edu wrote: > Somebody on the NANOG mailing list has their mail pointing to > tcwireless.us, > which is throwing challenge/response mail like the following: > > > Your message > > From: Valdis.Kletnieks at vt.edu > To: n3td3v > Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber > counterattack system ( > Einstein 3.0) > Date: 10/6/2008 > > has been just received by gmail.com mailserver. > > To prove that your message was sent by a human and not a computer, > please > visit the URL below and type in the alphanumeric text you will see > in the > image. You will be asked to do this only once for this recipient. > > http://mail.tcwireless.us/challenge/?folder=2008100614384085099427 > > Your message will be automatically deleted in a few days if you do not > confirm this request. > > ===================================================== > DO NOT REPLY TO THIS MESSAGE. NO ONE WILL RECEIVE IT. > ===================================================== > > Note it says 'gmail.com mailserver'. Paul Ferguson reported to me > that the one > he saw said 'received by vt.edu mailserver'. Also note that the > From/To > has lost nanog at nanog.org - for both my note and Paul's (in fact, > looking at > Paul's actual posting and mine show nanog at nanog.org as being the > only common > link, thus the "must be a nanog subscriber" conclusion). > > Please, if you're going to use a C/R, at least learn how to > whitelist the > mailing lists you're on. And if you can't figure out how to do > that, please > do us all a favor and not try to run an operational network... - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJI690kAAoJEGmx2Mt/+Iw/awkH/j/goIY2MuQYfMkGVCmBVlMx vrFACJFUdM3kFSw1KuB5l0s7U62JIuxoCMkIFuEU1xtXQzNMbmYytlkIq/oNY31q VEaEcG6khM7oxDrbbc4TgFVHm195o1mKYhK8TMPr5WBq9RIgY+n2iWFYfi/kIR0x R5VgKG2LUFOJr2i/400X8UGbq5DJAbStJf7FrqIWAQCsgtEVPSSp/cMrjujG4iPD 1mH4x76q3RrrMfUpcELs/LAE55eBPMFXAUx4lk13QKVhp7xkK5lkQWlUvEOUQKmQ zDCsj0Lu2sOPldZFszcKUQNuHQE3Bp8j3MNJ1vMBqSH2m+Gdh+Wwu3TRq8F1QaM= =flGu -----END PGP SIGNATURE----- From owen at delong.com Tue Oct 7 20:11:23 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Oct 2008 18:11:23 -0700 Subject: OK, who's the idiot using tcwireless.us? In-Reply-To: References: <34803.1223410457@turing-police.cc.vt.edu> Message-ID: <401FED2F-5491-47ED-B736-42B894C93DE0@delong.com> Active address validation, perhaps? Owen On Oct 7, 2008, at 3:05 PM, Christopher LILJENSTOLPE wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings, > > I agree with Howard here, I don't think this is a mis- > configuration, but a harvest attempt. The "mailserver" is in > different messages, and I can't see how that could get misconfigured > in a honest validation server. My guess is that someone is trolling > the archives, and sending this back? Why, I have no idea, given > they already can see the sending address. > > Chris > > On 07 Oct 2008, at 13.14, Valdis.Kletnieks at vt.edu wrote: > >> Somebody on the NANOG mailing list has their mail pointing to >> tcwireless.us, >> which is throwing challenge/response mail like the following: >> >> >> Your message >> >> From: Valdis.Kletnieks at vt.edu >> To: n3td3v >> Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber >> counterattack system ( >> Einstein 3.0) >> Date: 10/6/2008 >> >> has been just received by gmail.com mailserver. >> >> To prove that your message was sent by a human and not a computer, >> please >> visit the URL below and type in the alphanumeric text you will see >> in the >> image. You will be asked to do this only once for this recipient. >> >> http://mail.tcwireless.us/challenge/?folder=2008100614384085099427 >> >> Your message will be automatically deleted in a few days if you do >> not >> confirm this request. >> >> ===================================================== >> DO NOT REPLY TO THIS MESSAGE. NO ONE WILL RECEIVE IT. >> ===================================================== >> >> Note it says 'gmail.com mailserver'. Paul Ferguson reported to me >> that the one >> he saw said 'received by vt.edu mailserver'. Also note that the >> From/To >> has lost nanog at nanog.org - for both my note and Paul's (in fact, >> looking at >> Paul's actual posting and mine show nanog at nanog.org as being the >> only common >> link, thus the "must be a nanog subscriber" conclusion). >> >> Please, if you're going to use a C/R, at least learn how to >> whitelist the >> mailing lists you're on. And if you can't figure out how to do >> that, please >> do us all a favor and not try to run an operational network... > > - --- > ??? > Check my PGP key here: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B > > > > > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBAgAGBQJI690kAAoJEGmx2Mt/+Iw/awkH/j/goIY2MuQYfMkGVCmBVlMx > vrFACJFUdM3kFSw1KuB5l0s7U62JIuxoCMkIFuEU1xtXQzNMbmYytlkIq/oNY31q > VEaEcG6khM7oxDrbbc4TgFVHm195o1mKYhK8TMPr5WBq9RIgY+n2iWFYfi/kIR0x > R5VgKG2LUFOJr2i/400X8UGbq5DJAbStJf7FrqIWAQCsgtEVPSSp/cMrjujG4iPD > 1mH4x76q3RrrMfUpcELs/LAE55eBPMFXAUx4lk13QKVhp7xkK5lkQWlUvEOUQKmQ > zDCsj0Lu2sOPldZFszcKUQNuHQE3Bp8j3MNJ1vMBqSH2m+Gdh+Wwu3TRq8F1QaM= > =flGu > -----END PGP SIGNATURE----- From Skywing at valhallalegends.com Tue Oct 7 20:28:58 2008 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 7 Oct 2008 20:28:58 -0500 Subject: OK, who's the idiot using tcwireless.us? In-Reply-To: <401FED2F-5491-47ED-B736-42B894C93DE0@delong.com> References: <34803.1223410457@turing-police.cc.vt.edu> <401FED2F-5491-47ED-B736-42B894C93DE0@delong.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC5EC@caralain.haven.nynaeve.net> The person responsible already posted about this about 4 hours ago, BTW; further speculation is obsolete. :) - S -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, October 07, 2008 9:11 PM To: Christopher LILJENSTOLPE Cc: nanog at nanog.org Subject: Re: OK, who's the idiot using tcwireless.us? Active address validation, perhaps? Owen On Oct 7, 2008, at 3:05 PM, Christopher LILJENSTOLPE wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings, > > I agree with Howard here, I don't think this is a mis- > configuration, but a harvest attempt. The "mailserver" is in > different messages, and I can't see how that could get misconfigured > in a honest validation server. My guess is that someone is trolling > the archives, and sending this back? Why, I have no idea, given > they already can see the sending address. > > Chris > > On 07 Oct 2008, at 13.14, Valdis.Kletnieks at vt.edu wrote: > >> Somebody on the NANOG mailing list has their mail pointing to >> tcwireless.us, >> which is throwing challenge/response mail like the following: >> >> >> Your message >> >> From: Valdis.Kletnieks at vt.edu >> To: n3td3v >> Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber >> counterattack system ( >> Einstein 3.0) >> Date: 10/6/2008 >> >> has been just received by gmail.com mailserver. >> >> To prove that your message was sent by a human and not a computer, >> please >> visit the URL below and type in the alphanumeric text you will see >> in the >> image. You will be asked to do this only once for this recipient. >> >> http://mail.tcwireless.us/challenge/?folder=2008100614384085099427 >> >> Your message will be automatically deleted in a few days if you do >> not >> confirm this request. >> >> ===================================================== >> DO NOT REPLY TO THIS MESSAGE. NO ONE WILL RECEIVE IT. >> ===================================================== >> >> Note it says 'gmail.com mailserver'. Paul Ferguson reported to me >> that the one >> he saw said 'received by vt.edu mailserver'. Also note that the >> From/To >> has lost nanog at nanog.org - for both my note and Paul's (in fact, >> looking at >> Paul's actual posting and mine show nanog at nanog.org as being the >> only common >> link, thus the "must be a nanog subscriber" conclusion). >> >> Please, if you're going to use a C/R, at least learn how to >> whitelist the >> mailing lists you're on. And if you can't figure out how to do >> that, please >> do us all a favor and not try to run an operational network... > > - --- > ??? > Check my PGP key here: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B > > > > > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBAgAGBQJI690kAAoJEGmx2Mt/+Iw/awkH/j/goIY2MuQYfMkGVCmBVlMx > vrFACJFUdM3kFSw1KuB5l0s7U62JIuxoCMkIFuEU1xtXQzNMbmYytlkIq/oNY31q > VEaEcG6khM7oxDrbbc4TgFVHm195o1mKYhK8TMPr5WBq9RIgY+n2iWFYfi/kIR0x > R5VgKG2LUFOJr2i/400X8UGbq5DJAbStJf7FrqIWAQCsgtEVPSSp/cMrjujG4iPD > 1mH4x76q3RrrMfUpcELs/LAE55eBPMFXAUx4lk13QKVhp7xkK5lkQWlUvEOUQKmQ > zDCsj0Lu2sOPldZFszcKUQNuHQE3Bp8j3MNJ1vMBqSH2m+Gdh+Wwu3TRq8F1QaM= > =flGu > -----END PGP SIGNATURE----- From ralphw at interworld.net Tue Oct 7 23:20:57 2008 From: ralphw at interworld.net (Ralph E. Whitmore, III) Date: Tue, 7 Oct 2008 21:20:57 -0700 Subject: Nanog 44 Hockey Event -- Last Call Message-ID: For those that are attending NANOG 44 and interested in catching the: Los Angeles Kings vs. the San Jose Sharks NHL Hockey game If you are interested in going and have not already contacted me about the game please be sure to do so Before 3PM today Wednesday Oct. 8th at either 310-856-0550. You may speak to Myself Ralph or my Assistant Nancy. Tickets are $90.50 each and we will be sitting In sections 112-114 based on the total number of people that go. Thus far we have a group of 10 people going to the game. Be sure to let me ASAP. Ralph Whitmore InterWorld Communications, Inc. 310-856-0550 M-F 9A-6P From fergdawgster at gmail.com Tue Oct 7 23:25:26 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 7 Oct 2008 21:25:26 -0700 Subject: Nanog 44 Hockey Event -- Last Call In-Reply-To: References: Message-ID: <6cd462c00810072125k458901b0nd74b5702d656fd1b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Go sharks. :-) - - ferg On Tue, Oct 7, 2008 at 9:20 PM, Ralph E. Whitmore, III wrote: > For those that are attending NANOG 44 and interested in catching the: > > Los Angeles Kings vs. the San Jose Sharks NHL Hockey game -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI7DYyq1pz9mNUZTMRAqFwAJ0Y072Gu3QIgJ8KafO6NsDaqe8UUACeLHEt Jxe4cJn7pulvJLt6FnHoF/o= =pk5R -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From oberman at es.net Tue Oct 7 23:48:28 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 07 Oct 2008 21:48:28 -0700 Subject: Nanog 44 Hockey Event -- Last Call In-Reply-To: Your message of "Tue, 07 Oct 2008 21:25:26 PDT." <6cd462c00810072125k458901b0nd74b5702d656fd1b@mail.gmail.com> Message-ID: <20081008044828.A37D14500F@ptavv.es.net> > Date: Tue, 7 Oct 2008 21:25:26 -0700 > From: "Paul Ferguson" > > Go sharks. :-) All Right! Maybe we can have a nice teal-clad group down in LA. Sharks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From tomb at byrneit.net Wed Oct 8 01:48:00 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 7 Oct 2008 23:48:00 -0700 Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattacksystem(Einstein 3.0) In-Reply-To: <200810071405120.32BF5B92.25928@clifden.donelan.com> References: <48127.1223318264@turing-police.cc.vt.edu><200810071215150.32BF5B92.25440@clifden.donelan.com><20081007163011.GA59690@infiltrated.net><23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F6B3@pascal.zaphodb.org> People, and manage them appropriately. >-----Original Message----- >From: Sean Donelan [mailto:sean at donelan.com] >Sent: Tuesday, October 07, 2008 11:07 AM >To: Valdis.Kletnieks at vt.edu >Cc: nanog at nanog.org >Subject: Re: Fwd: cnn.com - Homeland Security seeks cyber >counterattacksystem(Einstein 3.0) > >On Tue, 7 Oct 2008, Valdis.Kletnieks at vt.edu wrote: >> On Tue, 07 Oct 2008 11:30:11 CDT, "J. Oquendo" said: >>> What about exceeding the minimum requirements for a change. >> (I think you'll find that if somebody is actually willing to *pay* for >more >> security, there's plenty of outfits who are more than happy to make it >happen) > >What should the US Government buy for more security? And how can the US >Government make sure they actually get what they are paying? > From rsk at gsp.org Wed Oct 8 06:21:22 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 8 Oct 2008 07:21:22 -0400 Subject: Some odd harvesting going on? In-Reply-To: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> Message-ID: <20081008112122.GA3237@gsp.org> On Tue, Oct 07, 2008 at 04:16:22PM -0400, Howard C. Berkowitz wrote: > To prove that your message was sent by a human and not a computer, please > visit the URL below and type in the alphanumeric text you will see in the > image. You will be asked to do this only once for this recipient. This doesn't look to me like phishing (although I can see the similarities); it looks like yet another severely clueless site engaged in challenge-response spamming. (C-R has long since been not only completely discredited as an anti-spam tactic, but has been recognized as a spam vector. Hosts emitting it are subject to blacklisting, in the same way and for much the same reason that hosts emitting backscatter/outscatter are.) ---Rsk From smb at cs.columbia.edu Wed Oct 8 08:06:49 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 8 Oct 2008 09:06:49 -0400 Subject: Nanog 44 Hockey Event -- Last Call In-Reply-To: References: Message-ID: <20081008090649.019f83ef@cs.columbia.edu> Just no self-styled hockey moms, please... From warren at kumari.net Wed Oct 8 08:43:33 2008 From: warren at kumari.net (Warren Kumari) Date: Wed, 8 Oct 2008 09:43:33 -0400 Subject: NANOG 44 (Los Angeles): ISP Security BOF In-Reply-To: References: Message-ID: Hi all, Well, Esthost has decided that they no longer wish to present their side of the story, and so their talk has been removed from the agenda :-) This also means that that the more, erm, operational talks have been lengthened and so won't feel quite as rushed... The revised agenda is below: 4:30 - 4:50: "Stealing the Internet" -- Anton Kapela -------------------------------------- 4:50 - 5:10: "An interim solution to the threat of DNS cache poisoning while waiting for DNSSEC". -- Rodney Joffe -------------------------------------- 5:10 - 5:30: "Next steps in IRR/X509" --Barry Raveendran Greene, Jason Schiller. -------------------------------------- 5:30 - 5:50: "Early Survey Results and Some Attack Statistics" -- Danny McPherson. I will get this (with some abstracts) posted on the NANOG 44 site soon. Thanks to everyone who will be presenting, and I look forward to seeing y'all there! W On Oct 6, 2008, at 2:05 PM, Warren Kumari wrote: > Hello all, > > NANOG 44 is now less than a week away. > Here is the current program for the ISP Security BOF (NANOG 44, > October 13, 2008, 4:30 PM - 6:00 PM) -- as always, the program at > this point is still somewhat fluid and subject to change. > > ------------------------------------ > 16:30 - 16:45: "Stealing the Internet" -- Anton Kapela > > In "Stealing the Internet" Kapela will describe a method where an > attacker exploits the BGP routing system to facilitate transparent > interception of IP packets. > The method will be shown to function at a scale previously thought > by many as unavailable. > The talk highlights a new twist in sub-prefix hijacking that he > demonstrated at Defcon 16: > using intrinsic BGP logic to hijack network traffic and > simultaneously create a 'bgp shunt towards > the target network. This method will be shown to preserve end-to-end > reachability while creating > a virtual 'wire tap' at the attackers network. He'll cover additive > TTL modification and > transparent-origin-AS as a means for the attacker to obscure the > interception. > > There will not be a live demonstration of the hijack or interception > methods. > > -------------------------------------- > > 16:45 - 17:00: "An interim solution to the threat of DNS cache > poisoning while waiting for DNSSEC". -- Rodney Joffe > > -------------------------------------- > > 17:00 - 17:15: "Next steps in IRR/X509" --Barry Raveendran Greene, > Jason Schiller. > > ------------------------------------- > > 17:15 - 17:30: "Esthost's response to the 'Hostexploit report'" -- > Konstantin Poltev (Esthost, Inc). > > We are still waiting for the official title / abstract for this > talk, so this is a temporary title.... > > ------------------------------------ > > 17:30 - 17:45: "Early Survey Results and Some Attack Statistics" -- > Danny McPherson. > > ------------------------------------- > > There are 15 minutes left over at the end of the agenda as I'm sure > some talks will run over their alloted time. > > Hopefully this agenda is interesting and you are looking forward to > the BOF.... > > > See you there, > W > > From darcy at druid.net Wed Oct 8 09:51:14 2008 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Wed, 8 Oct 2008 10:51:14 -0400 Subject: Some odd harvesting going on? In-Reply-To: <20081008112122.GA3237@gsp.org> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> <20081008112122.GA3237@gsp.org> Message-ID: <20081008105114.038334ca.darcy@druid.net> On Wed, 8 Oct 2008 07:21:22 -0400 Rich Kulawiec wrote: > This doesn't look to me like phishing (although I can see the > similarities); it looks like yet another severely clueless site engaged > in challenge-response spamming. (C-R has long since been not only > completely discredited as an anti-spam tactic, but has been recognized > as a spam vector. Hosts emitting it are subject to blacklisting, > in the same way and for much the same reason that hosts emitting > backscatter/outscatter are.) C-R *is* spam. Interestingly, proponents use the same argument for it that spammers do. It works for them. Spammers feel that .0001% response is reason enough to load the rest of us with with work for no pay. Proponents of C-R feel that reducing their spam load justifies having the rest of us work as their spam filter for free. It's the "I got mine, Jack" mentality which is sadly way too ubiquitous. Personally I think that the answer to this problem is to simply reply automatically to these challenges positively no matter what. Puts the job of filtering spam back on the first person. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From yahoo at jimpop.com Wed Oct 8 10:33:49 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Wed, 8 Oct 2008 11:33:49 -0400 Subject: Nanog 44 Hockey Event -- Last Call In-Reply-To: <20081008090649.019f83ef@cs.columbia.edu> References: <20081008090649.019f83ef@cs.columbia.edu> Message-ID: <7ff145960810080833l536658a2j30c832f9b5b0e7e5@mail.gmail.com> On Wed, Oct 8, 2008 at 09:06, Steven M. Bellovin wrote: > Just no self-styled hockey moms, please... You Maverick you. ;-) -Jim P. From andrey.gordon at gmail.com Wed Oct 8 11:37:06 2008 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Wed, 8 Oct 2008 12:37:06 -0400 Subject: UltraDNS mail admin around? Message-ID: <90ccfc90810080937r2bb61a5bufcd7561c8bfc921f@mail.gmail.com> I'm getting bombarded by these Received: from 80.224.33.155.static.user.ono.com ([80.224.33.155])by mxb2eqsj.ultradns.net with esmtp (Exim 4.43)id 1J7YZc-0007qU-4ifor mason_johnn at i2c.com; Wed, 26 Dec 2007 15:53:36 +0000 Message-ID: <000701c847d7$0379bd21$79a237a3 at muffejda> From: "Handbags" To: "Replica Watches" ----- Andrey Gordon [andrey.gordon at gmail.com] From randy at psg.com Wed Oct 8 11:40:09 2008 From: randy at psg.com (Randy Bush) Date: Wed, 08 Oct 2008 09:40:09 -0700 Subject: UltraDNS mail admin around? In-Reply-To: <90ccfc90810080937r2bb61a5bufcd7561c8bfc921f@mail.gmail.com> References: <90ccfc90810080937r2bb61a5bufcd7561c8bfc921f@mail.gmail.com> Message-ID: <48ECE269.2060005@psg.com> Andrey Gordon wrote: > I'm getting bombarded by these > > Received: from 80.224.33.155.static.user.ono.com ([80.224.33.155])by > mxb2eqsj.ultradns.net with esmtp (Exim 4.43)id 1J7YZc-0007qU-4ifor > mason_johnn at i2c.com; Wed, 26 Dec 2007 15:53:36 +0000 > Message-ID: <000701c847d7$0379bd21$79a237a3 at muffejda> > From: "Handbags" > To: "Replica Watches" get a clue 155.33.224.80.in-addr.arpa domain name pointer 80.224.33.155.static.user.ono.com. randy From randy at psg.com Wed Oct 8 11:42:31 2008 From: randy at psg.com (Randy Bush) Date: Wed, 08 Oct 2008 09:42:31 -0700 Subject: UltraDNS mail admin around? In-Reply-To: <48ECE269.2060005@psg.com> References: <90ccfc90810080937r2bb61a5bufcd7561c8bfc921f@mail.gmail.com> <48ECE269.2060005@psg.com> Message-ID: <48ECE2F7.4070208@psg.com> Randy Bush wrote: > Andrey Gordon wrote: >> I'm getting bombarded by these >> >> Received: from 80.224.33.155.static.user.ono.com ([80.224.33.155])by >> mxb2eqsj.ultradns.net with esmtp (Exim 4.43)id 1J7YZc-0007qU-4ifor >> mason_johnn at i2c.com; Wed, 26 Dec 2007 15:53:36 +0000 >> Message-ID: <000701c847d7$0379bd21$79a237a3 at muffejda> >> From: "Handbags" >> To: "Replica Watches" > > get a clue > > 155.33.224.80.in-addr.arpa domain name pointer > 80.224.33.155.static.user.ono.com. sorry. first cuppa. was ultra really the next hop? randy From clewis at nortel.com Wed Oct 8 12:18:16 2008 From: clewis at nortel.com (Chris Lewis) Date: Wed, 08 Oct 2008 13:18:16 -0400 Subject: UltraDNS mail admin around? In-Reply-To: <48ECE2F7.4070208@psg.com> References: <90ccfc90810080937r2bb61a5bufcd7561c8bfc921f@mail.gmail.com> <48ECE269.2060005@psg.com> <48ECE2F7.4070208@psg.com> Message-ID: <48ECEB58.3080107@nortel.com> Randy Bush wrote: > Randy Bush wrote: >> Andrey Gordon wrote: >>> I'm getting bombarded by these >>> >>> Received: from 80.224.33.155.static.user.ono.com ([80.224.33.155])by >>> mxb2eqsj.ultradns.net with esmtp (Exim 4.43)id 1J7YZc-0007qU-4ifor >>> mason_johnn at i2c.com; Wed, 26 Dec 2007 15:53:36 +0000 >>> Message-ID: <000701c847d7$0379bd21$79a237a3 at muffejda> >>> From: "Handbags" >>> To: "Replica Watches" > was ultra really the next hop? Either Ultradns is Andrey's mail server, or he appears to have left out his perimeter's Received line. More likely the latter. Without seeing the final received line, can't tell whether this really went thru UltraDNS. Many BOTS forge headers. It's not at all unusual to see: Received: from a by b (b is my server) Received: from c by d where d != a. Meaning the second Received line is entirely fabricated. From andrey.gordon at gmail.com Wed Oct 8 12:43:36 2008 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Wed, 8 Oct 2008 13:43:36 -0400 Subject: UltraDNS mail admin around? In-Reply-To: <48ECEF1D.1060607@psg.com> References: <90ccfc90810080937r2bb61a5bufcd7561c8bfc921f@mail.gmail.com> <48ECE269.2060005@psg.com> <48ECE2F7.4070208@psg.com> <48ECEB58.3080107@nortel.com> <48ECEF1D.1060607@psg.com> Message-ID: <90ccfc90810081043n187aa63etae226a68a95549f2@mail.gmail.com> we are actually not using ultraDNS for email. DNS only. It does awfully close to some local host spamming. tx for the help to y'all ----- Andrey Gordon [andrey.gordon at gmail.com] On Wed, Oct 8, 2008 at 1:34 PM, Randy Bush wrote: > Rodney Joffe wrote: > > I suspect that Andrey/his $workplace uses UltraDNS and uses the Ultra > > mail forwarder, which forwards and does not filter. > > > > I can't tell from the minimal headers what his workplace is, so can't > > really conform for him. > > in private email, andrey said no received: line above that one. so, > unless his mail spool is on one of your servers, it's a local forge. > > randy > > From kris.foster at gmail.com Wed Oct 8 13:20:48 2008 From: kris.foster at gmail.com (kris foster) Date: Wed, 8 Oct 2008 11:20:48 -0700 Subject: Nanog 44 Hockey Event -- Last Call In-Reply-To: References: Message-ID: <4385D139-5B2A-495E-B540-713BA67C1D22@gmail.com> On Oct 7, 2008, at 9:20 PM, Ralph E. Whitmore, III wrote: > For those that are attending NANOG 44 and interested in catching the: Hi Everyone A new list has been created for NANOG 44 attendees called nanog- attendee. You are automatically joined to this list if you registered for the conference (unless you selected to opt-out). If you would like to join manually you can do so here: http://mailman.nanog.org/mailman/listinfo/nanog-attendee Please help to keep the NANOG list operational in nature, and post other topics related to NANOG 44 (especially social events) to the nanog-attendee list. Thanks Kris Mail List Committee > > > > > Los Angeles Kings vs. the San Jose Sharks NHL Hockey game > > > > > > If you are interested in going and have not already contacted me about > the game please be sure to do so > > Before 3PM today Wednesday Oct. 8th at either 310-856-0550. You may > speak to Myself Ralph or my Assistant Nancy. > > Tickets are $90.50 each and we will be sitting In sections 112-114 > based > on the total number of people that go. > > > > Thus far we have a group of 10 people going to the game. > > > > Be sure to let me ASAP. > > > > Ralph Whitmore > > InterWorld Communications, Inc. > > 310-856-0550 M-F 9A-6P > > > > > > > > > > > From Valdis.Kletnieks at vt.edu Wed Oct 8 16:30:38 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 08 Oct 2008 17:30:38 -0400 Subject: OK, who's the idiot using tcwireless.us? In-Reply-To: Your message of "Tue, 07 Oct 2008 15:05:20 PDT." References: <34803.1223410457@turing-police.cc.vt.edu> Message-ID: <41549.1223501438@turing-police.cc.vt.edu> On Tue, 07 Oct 2008 15:05:20 PDT, Christopher LILJENSTOLPE said: > I agree with Howard here, I don't think this is a mis-configuration, > but a harvest attempt. The "mailserver" is in different messages, and > I can't see how that could get misconfigured in a honest validation > server. Turns out it was indeed a C/R system rather than a harvest attempt, and after seeing several other people's versions of the message, it was pretty obvious what was wrong - some fool programmer coded: printf("has just been received by %s mailserver\n", from->domain); when they wanted our->domain instead. So that's a double-whammy - (a) they didn't use their own server's domain, and (b) they used the From: address rather than the Return-Path: address (which is why it showed up as the poster's mailserver rather than nanog.org as the source). When you test it from your own domain, source->domain and from->domain are the same as our->domain so you don't notice. Presumably, nobody ever carefully tested from outside the local domain, which means their QA process isn't the strictest either - makes one wonder what other bugs and vulnerabilities are in there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nanog at freshdot.net Thu Oct 9 02:39:47 2008 From: nanog at freshdot.net (Sander Smeenk) Date: Thu, 9 Oct 2008 09:39:47 +0200 Subject: Some odd harvesting going on? In-Reply-To: <20081008105114.038334ca.darcy@druid.net> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> <20081008112122.GA3237@gsp.org> <20081008105114.038334ca.darcy@druid.net> Message-ID: <20081009073947.GJ17918@dot.freshdot.net> Quoting D'Arcy J.M. Cain (darcy at druid.net): > Personally I think that the answer to this problem is to simply reply > automatically to these challenges positively no matter what. Puts the > job of filtering spam back on the first person. I tend to click on the 'authorize' links i see in any ticket-queue that gets loaded with these messages at my job. Usually resulted by a joe-job run of some sort. I too think C-R spam 'prevention' is the lazy-mans approach at filtering spam. People can easily create their own whitelists based on their maillogs or mailhistory. -Sndr. -- | Bakers trade bread recipes on a knead to know basis. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D From mdixon at nkc.org Thu Oct 9 08:37:51 2008 From: mdixon at nkc.org (Michienne Dixon) Date: Thu, 9 Oct 2008 08:37:51 -0500 Subject: Some odd harvesting going on? References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1><20081008112122.GA3237@gsp.org><20081008105114.038334ca.darcy@druid.net> <20081009073947.GJ17918@dot.freshdot.net> Message-ID: <6316CD198EC8BC44A9D200F375869F1E25DA69@nkc-mailsrv.nkc.org> I too think C-R spam 'prevention' is the lazy-mans approach at filtering spam. People can easily create their own whitelists based on their maillogs or mailhistory. Unfortunately, I feel the majority of the solutions offered cater to the non-technical. The process of simplifying often results in a product that requires the least amount of hands-on from the end-user. Coupled with the fact that the average end-user is not interested in learning a process that takes more then 5 paragraphs to explain and more than 10 minutes to implement (without some sort of "wizard") and I think we have a good idea why the layman's approach is so prevalent. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 From darcy at druid.net Thu Oct 9 08:44:57 2008 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Thu, 9 Oct 2008 09:44:57 -0400 Subject: Some odd harvesting going on? In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E25DA69@nkc-mailsrv.nkc.org> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> <20081008112122.GA3237@gsp.org> <20081008105114.038334ca.darcy@druid.net> <20081009073947.GJ17918@dot.freshdot.net> <6316CD198EC8BC44A9D200F375869F1E25DA69@nkc-mailsrv.nkc.org> Message-ID: <20081009094457.37724c69.darcy@druid.net> On Thu, 9 Oct 2008 08:37:51 -0500 "Michienne Dixon" wrote: > > I too think C-R spam 'prevention' is the lazy-mans approach at filtering > spam. People can easily create their own whitelists based on their > maillogs or mailhistory. > > > Unfortunately, I feel the majority of the solutions offered cater to the > non-technical. The process of simplifying often results in a product > that requires the least amount of hands-on from the end-user. Coupled I don't have any argument with making the end-user's experience simpler and easier. I do complain when that simplification is at the expense of others. It's the difference between software that does some of your work and software that moves your work onto someone else's shoulders. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From Valdis.Kletnieks at vt.edu Thu Oct 9 08:50:13 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 09 Oct 2008 09:50:13 -0400 Subject: Some odd harvesting going on? In-Reply-To: Your message of "Thu, 09 Oct 2008 09:44:57 EDT." <20081009094457.37724c69.darcy@druid.net> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1> <20081008112122.GA3237@gsp.org> <20081008105114.038334ca.darcy@druid.net> <20081009073947.GJ17918@dot.freshdot.net> <6316CD198EC8BC44A9D200F375869F1E25DA69@nkc-mailsrv.nkc.org> <20081009094457.37724c69.darcy@druid.net> Message-ID: <56456.1223560213@turing-police.cc.vt.edu> On Thu, 09 Oct 2008 09:44:57 EDT, "D'Arcy J.M. Cain" said: > I don't have any argument with making the end-user's experience simpler > and easier. I do complain when that simplification is at the expense > of others. It's the difference between software that does some of your > work and software that moves your work onto someone else's shoulders. The problem being solved is that the average end-user is proving that CM Kornbluth was right. The meta-problem is that the average developer is *also* proving Kornbluth correct... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From chort at smtps.net Thu Oct 9 09:36:55 2008 From: chort at smtps.net (Brian Keefer) Date: Thu, 9 Oct 2008 07:36:55 -0700 Subject: Some odd harvesting going on? In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E25DA69@nkc-mailsrv.nkc.org> References: <25BCB151A9084F08AFC3F4D12C0B6F15@HDESK1><20081008112122.GA3237@gsp.org><20081008105114.038334ca.darcy@druid.net> <20081009073947.GJ17918@dot.freshdot.net> <6316CD198EC8BC44A9D200F375869F1E25DA69@nkc-mailsrv.nkc.org> Message-ID: On Oct 9, 2008, at 6:37 AM, Michienne Dixon wrote: > > I too think C-R spam 'prevention' is the lazy-mans approach at > filtering > spam. People can easily create their own whitelists based on their > maillogs or mailhistory. > > > Unfortunately, I feel the majority of the solutions offered cater > to the > non-technical. The process of simplifying often results in a product > that requires the least amount of hands-on from the end-user. Coupled > with the fact that the average end-user is not interested in > learning a > process that takes more then 5 paragraphs to explain and more than 10 > minutes to implement (without some sort of "wizard") and I think we > have > a good idea why the layman's approach is so prevalent. There are many, many other solutions that satisfy these requirements without massively inconveniencing everyone who tries to send you e-mail. I can only attribute the persistence of C-R as a method for combating spam to the fact that a sufficiently small percentage of humans will believe in *anything*, no matter how ludicrous it is. Hopefully this provides some motivation to those few who still cling uselessly to C-R to go out and spend 15 minutes researching advances in anti-spam technology in the last 5 years. Perhaps they will pull themselves out of the stone ages and stop irritating everyone. -- bk From scubacuda at gmail.com Thu Oct 9 10:31:07 2008 From: scubacuda at gmail.com (Rogelio) Date: Thu, 09 Oct 2008 08:31:07 -0700 Subject: Rackmount Vendors In-Reply-To: <48DCF680.2000105@thewybles.com> References: <48DC7278.9000103@sandboxitsolutions.com> <48DCF680.2000105@thewybles.com> Message-ID: <48EE23BB.9000709@gmail.com> Charles Wyble wrote: > > I second that. Worked at several places that used them. Also check out > Graybar. They have a will call office in Van Nuys. http://www.graybar.com/ > PDU search results for example: http://tinyurl.com/4xh4wg If you're looking for a "one stop place", Graybar is great. But if you need better prices, it's often better to shop around and get the stuff individually at other shops. From jackson.tim at gmail.com Thu Oct 9 10:35:21 2008 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 9 Oct 2008 10:35:21 -0500 Subject: Rackmount Vendors In-Reply-To: <48EE23BB.9000709@gmail.com> References: <48DC7278.9000103@sandboxitsolutions.com> <48DCF680.2000105@thewybles.com> <48EE23BB.9000709@gmail.com> Message-ID: <4407932e0810090835h3523af16ma42c9be87c01301d@mail.gmail.com> http://www.racksolutions.com/ On Thu, Oct 9, 2008 at 10:31 AM, Rogelio wrote: > Charles Wyble wrote: > >> >> I second that. Worked at several places that used them. Also check out >> Graybar. They have a will call office in Van Nuys. >> http://www.graybar.com/ >> PDU search results for example: http://tinyurl.com/4xh4wg >> > > > If you're looking for a "one stop place", Graybar is great. > > But if you need better prices, it's often better to shop around and get the > stuff individually at other shops. > > From sean at donelan.com Thu Oct 9 11:13:29 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 9 Oct 2008 12:13:29 -0400 (EDT) Subject: Fwd: cnn.com - Homeland Security seeks cyber counterattack system(Einstein 3.0) In-Reply-To: <27146.1223405973@turing-police.cc.vt.edu> References: <48127.1223318264@turing-police.cc.vt.edu> <200810071215150.32BF5B92.25440@clifden.donelan.com> <20081007163011.GA59690@infiltrated.net> <23112.1223401183@turing-police.cc.vt.edu> <200810071405120.32BF5B92.25928@clifden.donelan.com> <20081007182320.GA63228@infiltrated.net> <27146.1223405973@turing-police.cc.vt.edu> Message-ID: <200810091202140.32BF5B92.1904@clifden.donelan.com> On Tue, 7 Oct 2008, Valdis.Kletnieks at vt.edu wrote: > You don't want "the securest implementation". You want one that's > "secure enough" while still allowing the job to get done. You also don't > want to be *paying* for more security than you actually need. Note that > the higher price paid to the vendor isn't the only added cost of too much > security. The most recent (September 15 2008) US Government DNI directive about IT systems security includes the concept of appropriate risk management. http://www.dni.gov/electronic_reading_room/ICD_503.pdf D. POLICY 1. Risk Management a. The principal goal of an IC element's information technology risk management process shall be to protect the element's ability to perform its mission, not just its information assets. [...] b. [...] For example, a very high level of security may reduce risk to a very low level, but can be extremely expensive, and may unacceptably impede essential operations. In practice, it often turns out a "secure" system that is unusable for its mission is both insecure and unused because people start using other ways that bypass the "secure" system just to get the job done. So back to my original questions, what advice would you give to the US Government about protecting and defending its networks to maintain its capability to perform. And how can it be sure its getting what it paid for. From darkuncle at gmail.com Thu Oct 9 13:48:14 2008 From: darkuncle at gmail.com (Scott Francis) Date: Thu, 9 Oct 2008 11:48:14 -0700 Subject: NTIA/DOC requesting comments on root DNSSEC deployment Message-ID: <171423de0810091148u51149247w336891aae517bd7a@mail.gmail.com> http://www.ntia.doc.gov/DNS/DNSSEC.html vote early, vote often. -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From cidr-report at potaroo.net Fri Oct 10 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Oct 2008 22:00:02 +1000 (EST) Subject: BGP Update Report Message-ID: <200810101200.m9AC02Rv067873@wattle.apnic.net> BGP Update Report Interval: 08-Sep-08 -to- 09-Oct-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 238199 3.0% 195.7 -- SIFY-AS-IN Sify Limited 2 - AS1803 117148 1.5% 85.5 -- ICMNET-5 - Sprint 3 - AS20255 79393 1.0% 2561.1 -- Tecnowind S.A. 4 - AS5691 78741 1.0% 6057.0 -- MITRE-AS-5 - The MITRE Corporation 5 - AS4538 72727 0.9% 14.4 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS8151 61709 0.8% 25.4 -- Uninet S.A. de C.V. 7 - AS9051 61564 0.8% 389.6 -- IDM Autonomous System 8 - AS10986 53459 0.7% 614.5 -- Intermedia Comunicaciones S.A. 9 - AS14593 52003 0.7% 52003.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 10 - AS30890 48547 0.6% 36.1 -- EVOLVA Evolva Telecom 11 - AS10396 48464 0.6% 850.2 -- COQUI-NET - DATACOM CARIBE, INC. 12 - AS209 44861 0.6% 14.9 -- ASN-QWEST - Qwest Communications Corporation 13 - AS4274 43711 0.6% 642.8 -- ERX-AU-NET Assumption University 14 - AS11971 43380 0.6% 6197.1 -- PFIZERNET-GROTON - PFIZER INC. 15 - AS6389 41956 0.5% 9.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 16 - AS4184 40597 0.5% 20298.5 -- STORTEK-WHQ - Storage Technology Corporation 17 - AS17974 37938 0.5% 46.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS6458 37076 0.5% 103.9 -- Telgua 19 - AS14846 36603 0.5% 831.9 -- CGNOGE - NBC Internet 20 - AS7046 36113 0.5% 124.1 -- UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 52003 0.7% 52003.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 40597 0.5% 20298.5 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS8266 17640 0.2% 17640.0 -- NEXUSTEL Nexus Telecommunications 4 - AS38180 6358 0.1% 6358.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 5 - AS11971 43380 0.6% 6197.1 -- PFIZERNET-GROTON - PFIZER INC. 6 - AS5691 78741 1.0% 6057.0 -- MITRE-AS-5 - The MITRE Corporation 7 - AS29910 5975 0.1% 5975.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 8 - AS22492 13879 0.2% 4626.3 -- 9 - AS43299 4399 0.1% 4399.0 -- TELECONTACT-AS Telecontact Ltd. 10 - AS4557 7873 0.1% 3936.5 -- EP0-BLK-ASNBLOCK-7 - EP.NET, LLC. 11 - AS23082 18868 0.2% 3773.6 -- MPHI - Michigan Public Health Institute 12 - AS30969 29091 0.4% 3636.4 -- TAN-NET TransAfrica Networks 13 - AS44194 2887 0.0% 2887.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 14 - AS20255 79393 1.0% 2561.1 -- Tecnowind S.A. 15 - AS23917 2341 0.0% 2341.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 16 - AS39105 1929 0.0% 1929.0 -- CLASS-AS SC Class Computers And Service SRL 17 - AS42521 1539 0.0% 1539.0 -- COFUND-AS Fundacja Fundusz Wspolpracy 18 - AS41007 7567 0.1% 1513.4 -- CTCASTANA CTC ASTANA, KZ 19 - AS10221 5672 0.1% 1418.0 -- HEWLETT-PACKARD Multi-homed connections to multiple ISP's providing 20 - AS9747 11087 0.1% 1385.9 -- EZINTERNET-AS-AP EZInternet Pty Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 78689 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 210.214.151.0/24 62057 0.7% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.134.222.0/24 58932 0.7% AS9583 -- SIFY-AS-IN Sify Limited 4 - 12.8.7.0/24 52003 0.6% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 5 - 221.135.80.0/24 47252 0.6% AS9583 -- SIFY-AS-IN Sify Limited 6 - 194.126.143.0/24 46733 0.6% AS9051 -- IDM Autonomous System 7 - 12.18.36.0/24 43156 0.5% AS11971 -- PFIZERNET-GROTON - PFIZER INC. 8 - 200.108.200.0/24 40036 0.5% AS20255 -- Tecnowind S.A. 9 - 200.108.220.0/24 39041 0.5% AS20255 -- Tecnowind S.A. 10 - 210.210.112.0/24 33861 0.4% AS9583 -- SIFY-AS-IN Sify Limited 11 - 221.128.192.0/18 27607 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 12 - 196.42.0.0/20 23583 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 13 - 72.50.96.0/20 23578 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 199.117.144.0/22 20303 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 15 - 129.80.0.0/16 20294 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 16 - 221.135.251.0/24 19158 0.2% AS9583 -- SIFY-AS-IN Sify Limited 17 - 193.93.148.0/22 17640 0.2% AS8266 -- NEXUSTEL Nexus Telecommunications 18 - 83.228.71.0/24 15348 0.2% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 19 - 89.4.131.0/24 14913 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 196.27.108.0/22 14426 0.2% AS30969 -- TAN-NET TransAfrica Networks Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 10 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Oct 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200810101200.m9AC00os067803@wattle.apnic.net> This report has been generated at Fri Oct 10 21:18:20 2008 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 03-10-08 282818 172077 04-10-08 283038 172781 05-10-08 283068 172691 06-10-08 283255 172580 07-10-08 283354 171945 08-10-08 281623 173006 09-10-08 283615 173718 10-10-08 283780 174293 AS Summary 29644 Number of ASes in routing system 12561 Number of ASes announcing only one prefix 5035 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88349184 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 10Oct08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 284095 174352 109743 38.6% All ASes AS4538 5035 884 4151 82.4% ERX-CERNET-BKB China Education and Research Network Center AS6389 4299 351 3948 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2941 1335 1606 54.6% ASN-QWEST - Qwest Communications Corporation AS1785 1672 175 1497 89.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 2010 776 1234 61.4% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS4755 1478 280 1198 81.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1420 311 1109 78.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1551 659 892 57.5% TWTC - tw telecom holdings, inc. AS8151 1417 553 864 61.0% Uninet S.A. de C.V. AS11492 1216 449 767 63.1% CABLEONE - CABLE ONE AS19262 948 201 747 78.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 316 746 70.2% COVAD - Covad Communications Co. AS18101 781 102 679 86.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1310 662 648 49.5% ATT-INTERNET3 - AT&T WorldNet Services AS2386 1563 916 647 41.4% INS-AS - AT&T Data Communications Services AS9498 686 71 615 89.7% BBIL-AP BHARTI Airtel Ltd. AS22773 996 489 507 50.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS3356 1034 548 486 47.0% LEVEL3 Level 3 Communications AS855 589 103 486 82.5% CANET-ASN-4 - Bell Aliant AS4766 923 442 481 52.1% KIXS-AS-KR Korea Telecom AS4808 616 145 471 76.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS20115 1878 1408 470 25.0% CHARTER-NET-HKY-NC - Charter Communications AS17676 524 63 461 88.0% GIGAINFRA BB TECHNOLOGY Corp. AS9443 528 81 447 84.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7545 592 154 438 74.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 564 128 436 77.3% VTR BANDA ANCHA S.A. AS24560 593 157 436 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1435 1004 431 30.0% ATT-INTERNET4 - AT&T WorldNet Services AS4134 843 415 428 50.8% CHINANET-BACKBONE No.31,Jin-rong Street AS7011 913 500 413 45.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 41417 13678 27739 67.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 31.31.31.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.200.192.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.193.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.194.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.195.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.207.102.0/23 AS43647 LINK-NET-ASN SC. Link Net SRL. 91.209.7.0/24 AS31477 DUOCAST-AS Duocast 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 124.109.16.0/21 AS38137 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest Communications Corporation 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.25.240.0/21 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.173.252.0/22 AS40470 PROTECTED-CA - Protected.CA Inc. 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 208.115.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From joshm at apid.com Fri Oct 10 09:31:51 2008 From: joshm at apid.com (Josh Marchant) Date: Fri, 10 Oct 2008 09:31:51 -0500 Subject: LVL3 Issues? Message-ID: <48EF6757.5000807@apid.com> Any one else noticing routing Issues with LVL3? I have customers that cannot get to some of my IP's that are in the same block coming though LVL3. From pstewart at nexicomgroup.net Fri Oct 10 09:33:20 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 10 Oct 2008 10:33:20 -0400 Subject: LVL3 Issues? In-Reply-To: <48EF6757.5000807@apid.com> References: <48EF6757.5000807@apid.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01A9563D@nexus.nexicomgroup.net> A city, IP address or something along those lines would be helpful ;) We have a level(3) connection and haven't seen anything yet today.... Paul -----Original Message----- From: Josh Marchant [mailto:joshm at apid.com] Sent: October 10, 2008 10:32 AM To: nanog at nanog.org Subject: LVL3 Issues? Any one else noticing routing Issues with LVL3? I have customers that cannot get to some of my IP's that are in the same block coming though LVL3. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From smb at cs.columbia.edu Fri Oct 10 09:59:49 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 10 Oct 2008 10:59:49 -0400 Subject: NTIA/DOC requesting comments on root DNSSEC deployment In-Reply-To: <171423de0810091148u51149247w336891aae517bd7a@mail.gmail.com> References: <171423de0810091148u51149247w336891aae517bd7a@mail.gmail.com> Message-ID: <20081010105949.481451ae@cs.columbia.edu> On Thu, 9 Oct 2008 11:48:14 -0700 "Scott Francis" wrote: > http://www.ntia.doc.gov/DNS/DNSSEC.html > > vote early, vote often. And note that you have to use the procedure in the Federal Register notice for you comment to count. --Steve Bellovin, http://www.cs.columbia.edu/~smb From kin-wei.lee at hp.com Fri Oct 10 11:16:47 2008 From: kin-wei.lee at hp.com (Lee, Steven (NSG Malaysia)) Date: Fri, 10 Oct 2008 16:16:47 +0000 Subject: Help needed - Cisco Netflow Message-ID: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> Hi all, I have a customer who has a MPLS network for E/// Media Gateway (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR traffic is fixed size 110 bytes. During the high load period, it can reaches 450Kpps on a STM-1 link. The router platform is Cisco 12000 series, can the router generate 100% netflow data with such traffic load? Also can someone suggest a carrier class netflow collector for mobile service provider environment. Thanks in advance. Regards, Steven Lee From cmills at accessdc.com Fri Oct 10 11:46:24 2008 From: cmills at accessdc.com (Mills, Charles) Date: Fri, 10 Oct 2008 12:46:24 -0400 Subject: Help needed - Cisco Netflow In-Reply-To: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB0DCA8B2A@adc-prd-exch1.internal.accessdc.com> Lee, The question would be do you want a self contained appliance or a piece of software? I have used Advent Network's Net Flow Analyzer. There are others out there but I've had some decent amount of luck with these guys and they have an "Enterprise" license that will many, many (thousands?) interfaces. For the traffic load and the number of flows/second I'm guessing you'll need a really high end Linux box with lots and lots of disk space. There are open source netflow collectors too you could deal with if cost is an issue or you have the talent on staff to maintain it. Chuck -----Original Message----- From: Lee, Steven (NSG Malaysia) [mailto:kin-wei.lee at hp.com] Sent: Friday, October 10, 2008 12:17 PM To: nanog at nanog.org Subject: Help needed - Cisco Netflow Hi all, I have a customer who has a MPLS network for E/// Media Gateway (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR traffic is fixed size 110 bytes. During the high load period, it can reaches 450Kpps on a STM-1 link. The router platform is Cisco 12000 series, can the router generate 100% netflow data with such traffic load? Also can someone suggest a carrier class netflow collector for mobile service provider environment. Thanks in advance. Regards, Steven Lee This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From Jeremy_Lunsford at playstation.sony.com Fri Oct 10 12:06:10 2008 From: Jeremy_Lunsford at playstation.sony.com (Jeremy_Lunsford at playstation.sony.com) Date: Fri, 10 Oct 2008 10:06:10 -0700 Subject: LVL3 Issues? In-Reply-To: <48EF6757.5000807@apid.com> Message-ID: It sounds like an issue that we've seen twice with them. They'll be routing an entire block for us just fine, but traffic for one IP will get stuck in a routing loop and never makes it to us. The one time that it happened the technician ended up doing a few soft clears on their BGP, and the other time it was fixed before we could contact them about it.. It always seems to happen after we have a problem with our connection to them.. From Keith.Kocher at JTV.com Fri Oct 10 12:17:32 2008 From: Keith.Kocher at JTV.com (Kocher, Keith) Date: Fri, 10 Oct 2008 13:17:32 -0400 Subject: Help needed - Cisco Netflow In-Reply-To: <58E0B21FC367B24485855A1DBD96B0BB0DCA8B2A@adc-prd-exch1.internal.accessdc.com> References: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> <58E0B21FC367B24485855A1DBD96B0BB0DCA8B2A@adc-prd-exch1.internal.accessdc.com> Message-ID: <92D6698730931D48A3AFDC938D05BBDE07A65CBFE7@KPMSPW02.jewelry.acn> Open source netlow collector NTOP: http://www.ntop.org -----Original Message----- From: Mills, Charles [mailto:cmills at accessdc.com] Sent: Friday, October 10, 2008 12:46 PM To: Lee, Steven (NSG Malaysia); nanog at nanog.org Subject: RE: Help needed - Cisco Netflow Lee, The question would be do you want a self contained appliance or a piece of software? I have used Advent Network's Net Flow Analyzer. There are others out there but I've had some decent amount of luck with these guys and they have an "Enterprise" license that will many, many (thousands?) interfaces. For the traffic load and the number of flows/second I'm guessing you'll need a really high end Linux box with lots and lots of disk space. There are open source netflow collectors too you could deal with if cost is an issue or you have the talent on staff to maintain it. Chuck -----Original Message----- From: Lee, Steven (NSG Malaysia) [mailto:kin-wei.lee at hp.com] Sent: Friday, October 10, 2008 12:17 PM To: nanog at nanog.org Subject: Help needed - Cisco Netflow Hi all, I have a customer who has a MPLS network for E/// Media Gateway (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR traffic is fixed size 110 bytes. During the high load period, it can reaches 450Kpps on a STM-1 link. The router platform is Cisco 12000 series, can the router generate 100% netflow data with such traffic load? Also can someone suggest a carrier class netflow collector for mobile service provider environment. Thanks in advance. Regards, Steven Lee This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From kin-wei.lee at hp.com Fri Oct 10 12:20:30 2008 From: kin-wei.lee at hp.com (Lee, Steven (NSG Malaysia)) Date: Fri, 10 Oct 2008 17:20:30 +0000 Subject: Help needed - Cisco Netflow In-Reply-To: <48EF85FD.7070506@jarruda.com> References: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> <48EF85FD.7070506@jarruda.com> Message-ID: <084962C061414240A0CDB4BE328A9B2D097FCBC294@GVW1100EXC.americas.hpqcorp.net> Hi all, the LC on 12000 series is 12000-SIP-601 (engine 5) with multiple STM-1 SPA card. As far as I know the engine 5 card cannot do 450Kpps on netflow. Since the STM-1 is mainly for NB-AMR traffic (95%), do you recommend the sampled netflow instead? Does anyone aware of the sampled netflow accuracy? -----Original Message----- From: Julio Arruda [mailto:jarruda-cnsp at jarruda.com] Sent: Saturday, October 11, 2008 12:43 AM To: Lee, Steven (NSG Malaysia) Subject: Re: Help needed - Cisco Netflow Lee, Steven (NSG Malaysia) wrote: > Hi all, I have a customer who has a MPLS network for E/// Media Gateway (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR traffic is fixed size 110 bytes. During the high load period, it can reaches 450Kpps on a STM-1 link. The router platform is Cisco 12000 series, can the router generate 100% netflow data with such traffic load? Also can someone suggest a carrier class netflow collector for mobile service provider environment. Just a quick note.. You may want to post the Line Cards they have...Distinct LC have distinct Netflow capabilities (and impact). From pauldotwall at gmail.com Fri Oct 10 12:56:35 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 10 Oct 2008 13:56:35 -0400 Subject: LVL3 Issues? In-Reply-To: References: <48EF6757.5000807@apid.com> Message-ID: <620fd17c0810101056l1daaeb17s5570da8be19e5b10@mail.gmail.com> I've seen these a few times, usually traced back to LAG issues on their Force10s (ebr in traceroute). Drive Slow, Paul Wall On 10/10/08, Jeremy_Lunsford at playstation.sony.com wrote: > It sounds like an issue that we've seen twice with them. They'll be > routing an entire block for us just fine, but traffic for one IP will get > stuck in a routing loop and never makes it to us. The one time that it > happened the technician ended up doing a few soft clears on their BGP, and > the other time it was fixed before we could contact them about it.. > > It always seems to happen after we have a problem with our connection to > them.. > > From cscora at apnic.net Fri Oct 10 13:09:08 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Oct 2008 04:09:08 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200810101809.m9AI98dY028474@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Oct, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 270790 Prefixes after maximum aggregation: 130670 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131713 Total ASes present in the Internet Routing Table: 29477 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25621 Origin ASes announcing only one prefix: 12506 Transit ASes present in the Internet Routing Table: 3856 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 569 Unregistered ASNs in the Routing Table: 208 Number of 32-bit ASNs allocated by the RIRs: 61 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 755 Number of addresses announced to Internet: 1911844672 Equivalent to 113 /8s, 244 /16s and 111 /24s Percentage of available address space announced: 51.6 Percentage of allocated address space announced: 62.6 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.7 Total number of prefixes smaller than registry allocations: 132945 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62393 Total APNIC prefixes after maximum aggregation: 23186 APNIC Deaggregation factor: 2.69 Prefixes being announced from the APNIC address blocks: 59270 Unique aggregates announced from the APNIC address blocks: 26697 APNIC Region origin ASes present in the Internet Routing Table: 3402 APNIC Prefixes per ASN: 17.42 APNIC Region origin ASes announcing only one prefix: 903 APNIC Region transit ASes present in the Internet Routing Table: 543 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 378110880 Equivalent to 22 /8s, 137 /16s and 131 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/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, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123078 Total ARIN prefixes after maximum aggregation: 64823 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92344 Unique aggregates announced from the ARIN address blocks: 35062 ARIN Region origin ASes present in the Internet Routing Table: 12519 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4856 ARIN Region transit ASes present in the Internet Routing Table: 1197 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 365498400 Equivalent to 21 /8s, 201 /16s and 16 /24s Percentage of available ARIN address space announced: 75.1 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 ARIN Address Blocks 24/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, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 58965 Total RIPE prefixes after maximum aggregation: 35511 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 54163 Unique aggregates announced from the RIPE address blocks: 36250 RIPE Region origin ASes present in the Internet Routing Table: 12011 RIPE Prefixes per ASN: 4.51 RIPE Region origin ASes announcing only one prefix: 6332 RIPE Region transit ASes present in the Internet Routing Table: 1842 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 375037856 Equivalent to 22 /8s, 90 /16s and 159 /24s Percentage of available RIPE address space announced: 86.0 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-49151 RIPE Address Blocks 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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 21825 Total LACNIC prefixes after maximum aggregation: 5399 LACNIC Deaggregation factor: 4.04 Prefixes being announced from the LACNIC address blocks: 19874 Unique aggregates announced from the LACNIC address blocks: 11074 LACNIC Region origin ASes present in the Internet Routing Table: 1010 LACNIC Prefixes per ASN: 19.68 LACNIC Region origin ASes announcing only one prefix: 332 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 57342720 Equivalent to 3 /8s, 106 /16s and 251 /24s Percentage of available LACNIC address space announced: 57.0 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3963 Total AfriNIC prefixes after maximum aggregation: 1310 AfriNIC Deaggregation factor: 3.03 Prefixes being announced from the AfriNIC address blocks: 4229 Unique aggregates announced from the AfriNIC address blocks: 2056 AfriNIC Region origin ASes present in the Internet Routing Table: 261 AfriNIC Prefixes per ASN: 16.20 AfriNIC Region origin ASes announcing only one prefix: 83 AfriNIC Region transit ASes present in the Internet Routing Table: 56 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12835328 Equivalent to 0 /8s, 195 /16s and 218 /24s Percentage of available AfriNIC address space announced: 38.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1476 522 197 TATA Communications formerly 17488 1420 96 103 Hathway IP Over Cable Interne 9583 1108 87 476 Sify Limited 4766 885 6407 362 Korea Telecom (KIX) 4134 843 13664 346 CHINANET-BACKBONE 23577 811 34 694 Korea Telecom (ATM-MPLS) 18101 781 167 26 Reliance Infocom Ltd Internet 4780 716 355 61 Digital United Inc. 9498 686 295 54 BHARTI BT INTERNET LTD. 4808 627 1164 142 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4296 3416 339 bellsouth.net, inc. 209 2938 4033 621 Qwest 6298 2011 319 711 Cox Communicatons 20115 1878 1424 715 Charter Communications 1785 1670 717 154 PaeTec Communications, Inc. 2386 1558 699 896 AT&T Data Communications Serv 4323 1553 1084 376 Time Warner Telecom 7018 1410 5859 988 AT&T WorldNet Services 6478 1312 273 197 AT&T Worldnet Services 11492 1216 152 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 435 1777 384 TDC Tele Danmark 30890 348 94 188 SC Kappa Invexim SRL 3215 328 2756 107 France Telecom Transpac 3301 328 1428 299 TeliaNet Sweden 3320 325 7063 274 Deutsche Telekom AG 8866 324 79 22 Bulgarian Telecommunication C 8452 308 188 11 TEDATA 5462 301 794 27 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1419 2849 219 UniNet S.A. de C.V. 11830 669 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 10620 504 122 61 TVCABLE BOGOTA 7303 490 241 69 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 420 85 49 ENTEL CHILE S.A. 11172 407 118 71 Servicios Alestra S.A de C.V 28573 372 460 23 NET Servicos de Comunicao S.A 14117 343 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 543 71 39 LINKdotNET AS number 3741 267 856 225 The Internet Solution 2018 235 215 139 Tertiary Education Network 20858 194 34 3 EgyNet 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 119 555 69 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited 29571 109 13 9 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4296 3416 339 bellsouth.net, inc. 209 2938 4033 621 Qwest 6298 2011 319 711 Cox Communicatons 20115 1878 1424 715 Charter Communications 1785 1670 717 154 PaeTec Communications, Inc. 2386 1558 699 896 AT&T Data Communications Serv 4323 1553 1084 376 Time Warner Telecom 4755 1476 522 197 TATA Communications formerly 17488 1420 96 103 Hathway IP Over Cable Interne 8151 1419 2849 219 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2938 2317 Qwest 1785 1670 1516 PaeTec Communications, Inc. 17488 1420 1317 Hathway IP Over Cable Interne 6298 2011 1300 Cox Communicatons 4755 1476 1279 TATA Communications formerly 11492 1216 1205 Cable One 8151 1419 1200 UniNet S.A. de C.V. 4323 1553 1177 Time Warner Telecom 20115 1878 1163 Charter Communications 6478 1312 1115 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. Complete listing at http://thyme.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:18 /9:9 /10:17 /11:46 /12:148 /13:297 /14:536 /15:1063 /16:10150 /17:4411 /18:7643 /19:16360 /20:19220 /21:18775 /22:23634 /23:24603 /24:141184 /25:820 /26:989 /27:763 /28:87 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2843 4296 bellsouth.net, inc. 6298 1985 2011 Cox Communicatons 209 1696 2938 Qwest 2386 1238 1558 AT&T Data Communications Serv 17488 1213 1420 Hathway IP Over Cable Interne 11492 1192 1216 Cable One 1785 1131 1670 PaeTec Communications, Inc. 6478 1098 1312 AT&T Worldnet Services 18566 1043 1062 Covad Communications 20115 987 1878 Charter Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:140 12:2182 13:2 15:22 16:3 17:5 18:13 20:35 24:1135 31:1 32:58 38:508 40:92 41:710 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:517 59:527 60:452 61:980 62:1098 63:2032 64:3227 65:2407 66:3518 67:1277 68:802 69:2320 70:861 71:275 72:2030 73:7 74:1239 75:188 76:275 77:816 78:843 79:266 80:907 81:871 82:600 83:392 84:553 85:1008 86:400 87:708 88:340 89:1376 90:22 91:1582 92:274 93:895 94:235 95:3 96:79 97:97 98:340 99:8 113:10 114:95 115:118 116:1007 117:374 118:237 119:517 120:93 121:599 122:855 123:440 124:867 125:1193 128:356 129:204 130:135 131:415 132:72 133:9 134:184 135:32 136:223 137:97 138:143 139:81 140:509 141:108 142:403 143:301 144:327 145:50 146:373 147:156 148:529 149:211 150:128 151:181 152:148 153:136 154:10 155:282 156:174 157:301 158:170 159:304 160:275 161:138 162:255 163:133 164:519 165:510 166:364 167:337 168:637 169:143 170:450 171:33 172:10 173:50 187:16 188:1 189:325 190:2299 192:5750 193:4130 194:3243 195:2584 196:1009 198:3740 199:3294 200:5553 201:1422 202:7771 203:8077 204:3923 205:2143 206:2341 207:2757 208:3666 209:3433 210:2564 211:1100 212:1482 213:1544 214:169 215:50 216:4393 217:1237 218:346 219:440 220:1054 221:416 222:290 End of report From bedard.phil at gmail.com Fri Oct 10 13:17:18 2008 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 10 Oct 2008 14:17:18 -0400 Subject: Help needed - Cisco Netflow In-Reply-To: <084962C061414240A0CDB4BE328A9B2D097FCBC294@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> <48EF85FD.7070506@jarruda.com> <084962C061414240A0CDB4BE328A9B2D097FCBC294@GVW1100EXC.americas.hpqcorp.net> Message-ID: <10B38098-C152-4FC1-8819-16D1F2D5DD15@gmail.com> It depends on how many active flows you have at any one time. Also, I don't think the SIP-601 supports full netflow V5 in hardware, only V8, which is aggregated netflow, which may not be what you want. It does do V5/V9 sampled netflow in hardware. The sampled netflow on that platform is better than on say the 6500/7600, so I would just go with that. Phil On Oct 10, 2008, at 1:20 PM, Lee, Steven (NSG Malaysia) wrote: > Hi all, the LC on 12000 series is 12000-SIP-601 (engine 5) with > multiple STM-1 SPA card. As far as I know the engine 5 card cannot > do 450Kpps on netflow. Since the STM-1 is mainly for NB-AMR traffic > (95%), do you recommend the sampled netflow instead? Does anyone > aware of the sampled netflow accuracy? > > -----Original Message----- > From: Julio Arruda [mailto:jarruda-cnsp at jarruda.com] > Sent: Saturday, October 11, 2008 12:43 AM > To: Lee, Steven (NSG Malaysia) > Subject: Re: Help needed - Cisco Netflow > > Lee, Steven (NSG Malaysia) wrote: >> Hi all, I have a customer who has a MPLS network for E/// Media >> Gateway (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR >> traffic is fixed size 110 bytes. During the high load period, it >> can reaches 450Kpps on a STM-1 link. The router platform is Cisco >> 12000 series, can the router generate 100% netflow data with such >> traffic load? Also can someone suggest a carrier class netflow >> collector for mobile service provider environment. > Just a quick note.. > You may want to post the Line Cards they have...Distinct LC have > distinct Netflow capabilities (and impact). > From pfunix at gmail.com Fri Oct 10 13:46:39 2008 From: pfunix at gmail.com (Beavis) Date: Fri, 10 Oct 2008 12:46:39 -0600 Subject: DDoS Attack in Progress. Message-ID: Hi All, DoS attack in progress, any upstream info for these guys? their phone number doesn't respond. This is the RIPE Whois query server #1. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Note: This output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '88.247.0.0 - 88.247.79.255' inetnum: 88.247.0.0 - 88.247.79.255 netname: TurkTelekom descr: TT ADSL-alcatel static_ulus country: tr admin-c: TTBA1-RIPE tech-c: TTBA1-RIPE status: ASSIGNED PA "status:" definitions mnt-by: as9121-mnt source: RIPE # Filtered role: TT Administrative Contact Role address: Turk Telekom address: Bilisim Aglari Dairesi address: Aydinlikevler address: 06103 ANKARA phone: +90 312 313 1950 fax-no: +90 312 313 1949 e-mail: abuse at ttnet.net.tr admin-c: BADB3-RIPE tech-c: ZA66-RIPE tech-c: NO638-RIPE tech-c: SO351-RIPE nic-hdl: TTBA1-RIPE mnt-by: AS9121-MNT source: RIPE # Filtered % Information related to '88.247.0.0/17AS9121' route: 88.247.0.0/17 descr: TurkTelecom origin: AS9121 mnt-by: AS9121-MNT source: RIPE # Filtered From fkittred at staff.gwi.net Fri Oct 10 13:50:11 2008 From: fkittred at staff.gwi.net (Fletcher Kittredge) Date: Fri, 10 Oct 2008 14:50:11 -0400 Subject: transcievers/amplifiers for 150 km fiber run Message-ID: We are looking to light a two strand fiber link of about 95 miles (or 150km). It would be worth a lot to us not to have repeaters. We are hoping for Gigabit Ethernet. Sonet is possible but a less attractive solution. Are there options for this sort of distance? The longest current link we have is about 65 miles. I understand the transmission characteristics of the fiber will effect distance of transmission. regards, Fletcher -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From fergdawgster at gmail.com Fri Oct 10 13:55:41 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 10 Oct 2008 11:55:41 -0700 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: <6cd462c00810101155m2e631938gfc8bef96c02952bc@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not surprising -- TurkTelekom has long been known to be a hotbed of malicious activity, a known hoster for Russian/Ukrainian cyber criminals, and perhaps one of the most botnetted ISPs on the planet: http://itw.trendmicro-europe.com/index.php?id=64 - - ferg On Fri, Oct 10, 2008 at 11:46 AM, Beavis wrote: > Hi All, > > DoS attack in progress, any upstream info for these guys? their > phone number doesn't respond. > > This is the RIPE Whois query server #1. > % The objects are in RPSL format. > % > % Rights restricted by copyright. > % See http://www.ripe.net/db/copyright.html > > % Note: This output has been filtered. > % To receive output for a database update, use the "-B" flag. > > % Information related to '88.247.0.0 - 88.247.79.255' > > inetnum: 88.247.0.0 - 88.247.79.255 > netname: TurkTelekom > descr: TT ADSL-alcatel static_ulus > country: tr > admin-c: TTBA1-RIPE > tech-c: TTBA1-RIPE > status: ASSIGNED PA "status:" definitions > mnt-by: as9121-mnt > source: RIPE # Filtered > > role: TT Administrative Contact Role > address: Turk Telekom > address: Bilisim Aglari Dairesi > address: Aydinlikevler > address: 06103 ANKARA > phone: +90 312 313 1950 > fax-no: +90 312 313 1949 > e-mail: abuse at ttnet.net.tr > admin-c: BADB3-RIPE > tech-c: ZA66-RIPE > tech-c: NO638-RIPE > tech-c: SO351-RIPE > nic-hdl: TTBA1-RIPE > mnt-by: AS9121-MNT > source: RIPE # Filtered > > % Information related to '88.247.0.0/17AS9121' > > route: 88.247.0.0/17 > descr: TurkTelecom > origin: AS9121 > mnt-by: AS9121-MNT > source: RIPE # Filtered > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI76Ucq1pz9mNUZTMRAiJoAJ9v5DTn5TZZtBwno+c4JB/zun0AeQCg7vqz uS4eSff62RIus6Qi1foH8II= =S4jc -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From mehmet at icann.org Fri Oct 10 13:58:29 2008 From: mehmet at icann.org (Mehmet Akcin) Date: Fri, 10 Oct 2008 11:58:29 -0700 Subject: DDoS Attack in Progress. In-Reply-To: <6cd462c00810101155m2e631938gfc8bef96c02952bc@mail.gmail.com> Message-ID: Try, NOC ITMC/NOC +902125209898 itmcistanbul at turktelekom.com.tr Mehmet From: Paul Ferguson Date: Fri, 10 Oct 2008 11:55:41 -0700 To: Beavis Cc: NANOG list Subject: Re: DDoS Attack in Progress. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not surprising -- TurkTelekom has long been known to be a hotbed of malicious activity, a known hoster for Russian/Ukrainian cyber criminals, and perhaps one of the most botnetted ISPs on the planet: http://itw.trendmicro-europe.com/index.php?id=64 - - ferg On Fri, Oct 10, 2008 at 11:46 AM, Beavis wrote: > Hi All, > > DoS attack in progress, any upstream info for these guys? their > phone number doesn't respond. > > This is the RIPE Whois query server #1. > % The objects are in RPSL format. > % > % Rights restricted by copyright. > % See http://www.ripe.net/db/copyright.html > > % Note: This output has been filtered. > % To receive output for a database update, use the "-B" flag. > > % Information related to '88.247.0.0 - 88.247.79.255' > > inetnum: 88.247.0.0 - 88.247.79.255 > netname: TurkTelekom > descr: TT ADSL-alcatel static_ulus > country: tr > admin-c: TTBA1-RIPE > tech-c: TTBA1-RIPE > status: ASSIGNED PA "status:" definitions > mnt-by: as9121-mnt > source: RIPE # Filtered > > role: TT Administrative Contact Role > address: Turk Telekom > address: Bilisim Aglari Dairesi > address: Aydinlikevler > address: 06103 ANKARA > phone: +90 312 313 1950 > fax-no: +90 312 313 1949 > e-mail: abuse at ttnet.net.tr > admin-c: BADB3-RIPE > tech-c: ZA66-RIPE > tech-c: NO638-RIPE > tech-c: SO351-RIPE > nic-hdl: TTBA1-RIPE > mnt-by: AS9121-MNT > source: RIPE # Filtered > > % Information related to '88.247.0.0/17AS9121' > > route: 88.247.0.0/17 > descr: TurkTelecom > origin: AS9121 > mnt-by: AS9121-MNT > source: RIPE # Filtered > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI76Ucq1pz9mNUZTMRAiJoAJ9v5DTn5TZZtBwno+c4JB/zun0AeQCg7vqz uS4eSff62RIus6Qi1foH8II= =S4jc -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3392 bytes Desc: not available URL: From dholmes at mwdh2o.com Fri Oct 10 13:59:28 2008 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 10 Oct 2008 11:59:28 -0700 Subject: transcievers/amplifiers for 150 km fiber run In-Reply-To: References: Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E07AD0B60@usmsxt104.mwd.h2o> MRV Lambda Driver CWDM claims 200km with Raman amplification cards. Atrica, now owned by Nokia, Ethernet switches claim 120 km -----Original Message----- From: Fletcher Kittredge [mailto:fkittred at staff.gwi.net] Sent: Friday, October 10, 2008 11:50 AM To: nanog at nanog.org Subject: transcievers/amplifiers for 150 km fiber run We are looking to light a two strand fiber link of about 95 miles (or 150km). It would be worth a lot to us not to have repeaters. We are hoping for Gigabit Ethernet. Sonet is possible but a less attractive solution. Are there options for this sort of distance? The longest current link we have is about 65 miles. I understand the transmission characteristics of the fiber will effect distance of transmission. regards, Fletcher -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From deepak at ai.net Fri Oct 10 15:10:19 2008 From: deepak at ai.net (Deepak Jain) Date: Fri, 10 Oct 2008 16:10:19 -0400 Subject: transcievers/amplifiers for 150 km fiber run In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E07AD0B60@usmsxt104.mwd.h2o> References: <485ED9BA02629E4BBBA53AC892EDA50E07AD0B60@usmsxt104.mwd.h2o> Message-ID: <48EFB6AB.8060605@ai.net> MRV or Finisar are good places to look for your optics. 120km is no problem for 1G/2.7G. Depending on the qualities of your fiber 150km may be within the 120km budget. Deepak Holmes,David A wrote: > MRV Lambda Driver CWDM claims 200km with Raman amplification cards. > Atrica, now owned by Nokia, Ethernet switches claim 120 km > > -----Original Message----- > From: Fletcher Kittredge [mailto:fkittred at staff.gwi.net] > Sent: Friday, October 10, 2008 11:50 AM > To: nanog at nanog.org > Subject: transcievers/amplifiers for 150 km fiber run > > We are looking to light a two strand fiber link of about 95 miles (or > 150km). It would be worth a lot to us not to have repeaters. We are > hoping for Gigabit Ethernet. Sonet is possible but a less attractive > solution. Are there options for this sort of distance? The longest > current link we have is about 65 miles. I understand the transmission > characteristics of the fiber will effect distance of transmission. > > regards, > Fletcher > From fkittred at staff.gwi.net Fri Oct 10 15:23:12 2008 From: fkittred at staff.gwi.net (Fletcher Kittredge) Date: Fri, 10 Oct 2008 16:23:12 -0400 Subject: transcievers/amplifiers for 150 km fiber run In-Reply-To: References: Message-ID: Thanks to all that replied. A bit more background: By regulation, the local ILEC is required to supply us with dark fiber where available. They have taken the regulatory stance that it is not technically possible to use dark fiber runs of more than 60 miles (prior, their regulatory stance was runs of more than twenty miles were not technically feasible.) Our counter-argument has been that we have existing fiber runs of 63 miles and 59 miles that work well without special equipment. We are now arguing about a particular fiber run in rural Maine of about 91 miles. Our position is it is technically feasible, depending on fiber characteristics, to light 91 miles of fiber. Their position is that runs of more than 60 miles are not feasible. I was hoping to bolster our argument by pointing to data sheets of optical transcievers rated up to 150 km. Then, after we get the fiber, I was hoping to buy said equipment. regards, Fletcher On Fri, Oct 10, 2008 at 2:50 PM, Fletcher Kittredge wrote: > We are looking to light a two strand fiber link of about 95 miles (or > 150km). It would be worth a lot to us not to have repeaters. We are > hoping for Gigabit Ethernet. Sonet is possible but a less attractive > solution. Are there options for this sort of distance? The longest > current link we have is about 65 miles. I understand the transmission > characteristics of the fiber will effect distance of transmission. > > regards, > Fletcher > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From tdurack at gmail.com Fri Oct 10 15:48:31 2008 From: tdurack at gmail.com (Tim Durack) Date: Fri, 10 Oct 2008 16:48:31 -0400 Subject: transcievers/amplifiers for 150 km fiber run In-Reply-To: References: Message-ID: <9e246b4d0810101348w7d56fa01lbe76ff466acb63a6@mail.gmail.com> These guys claim upto 180km: http://www.bookham.com/datasheets/transceivers/IGP-28111.cfm Tim:> On Fri, Oct 10, 2008 at 4:23 PM, Fletcher Kittredge wrote: > Thanks to all that replied. A bit more background: By regulation, the > local ILEC is required to supply us with dark fiber where available. They > have taken the regulatory stance that it is not technically possible to use > dark fiber runs of more than 60 miles (prior, their regulatory stance was > runs of more than twenty miles were not technically feasible.) Our > counter-argument has been that we have existing fiber runs of 63 miles and > 59 miles that work well without special equipment. We are now arguing > about a particular fiber run in rural Maine of about 91 miles. Our > position is it is technically feasible, depending on fiber characteristics, > to light 91 miles of fiber. Their position is that runs of more than 60 > miles are not feasible. I was hoping to bolster our argument by pointing > to data sheets of optical transcievers rated up to 150 km. Then, after we > get the fiber, I was hoping to buy said equipment. > > regards, > Fletcher > > On Fri, Oct 10, 2008 at 2:50 PM, Fletcher Kittredge > wrote: > > > We are looking to light a two strand fiber link of about 95 miles (or > > 150km). It would be worth a lot to us not to have repeaters. We are > > hoping for Gigabit Ethernet. Sonet is possible but a less attractive > > solution. Are there options for this sort of distance? The longest > > current link we have is about 65 miles. I understand the transmission > > characteristics of the fiber will effect distance of transmission. > > > > regards, > > Fletcher > > > > -- > > Fletcher Kittredge > > GWI > > 8 Pomerleau Street > > Biddeford, ME 04005-9457 > > 207-602-1134 > > > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From linford at spamhaus.org Sat Oct 11 03:05:36 2008 From: linford at spamhaus.org (Steve Linford) Date: Sat, 11 Oct 2008 08:05:36 +0000 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: On 10 Oct 2008, at 20:46, Beavis wrote: > Hi All, > > DoS attack in progress, any upstream info for these guys? their > phone number doesn't respond. > > inetnum: 88.247.0.0 - 88.247.79.255 > netname: TurkTelekom > descr: TT ADSL-alcatel static_ulus > country: tr The Spamhaus folk on this list have the address of TurkTelekom's chief security/abuse guy who would take take of this, but we would not be inclined to give his address to someone identifying themselves as "Beavis" with a gmail address. Can you elaborate on who you are, what's being DoSsed (a router, an http server, a mail server?), and whether you can ACL the source (since you know the source is in 88.247.0.0/17, why not ACL the source at your router or at whatever device is being DoSsed). Steve Linford The Spamhaus Project http://www.spamhaus.org From nanog at webazilla.com Sat Oct 11 06:43:19 2008 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Sat, 11 Oct 2008 14:43:19 +0300 Subject: Peering for beginners Message-ID: <48F09157.9030104@webazilla.com> Hi, Our comapny going to build some peering POP across USA, and i really don't know where is the best place to have first POP? Please advice. Thanks - Konstantin N. Bezruchenko From simon at slimey.org Sat Oct 11 07:37:07 2008 From: simon at slimey.org (Simon Lockhart) Date: Sat, 11 Oct 2008 13:37:07 +0100 Subject: Peering for beginners In-Reply-To: <48F09157.9030104@webazilla.com> References: <48F09157.9030104@webazilla.com> Message-ID: <20081011123707.GJ18579@virtual.bogons.net> On Sat Oct 11, 2008 at 02:43:19PM +0300, Konstantin Bezruchenko wrote: > Our comapny going to build some peering POP across USA, and i really > don't know where is the best place to have first POP? Where's you're traffic going to, or coming from? Without knowing that, it's hard to say... Take a look at netflow, flowtools, etc, and work out where large chunks of your traffic is going. Then research at peeringdb.com to work out which networks are likely to peer with you, and which peering exchanges they're present at. Then look at the cost of transport from your existing POPs to the peering points, and work out which ones it's financially viable for you to reach. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From nanog at webazilla.com Sat Oct 11 07:44:49 2008 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Sat, 11 Oct 2008 15:44:49 +0300 Subject: Peering for beginners In-Reply-To: <20081011123707.GJ18579@virtual.bogons.net> References: <48F09157.9030104@webazilla.com> <20081011123707.GJ18579@virtual.bogons.net> Message-ID: <48F09FC1.3000305@webazilla.com> Hi, Simon Lockhart wrote: > > Take a look at netflow, flowtools, etc, and work out where large chunks of > your traffic is going. Then research at peeringdb.com to work out which > networks are likely to peer with you, and which peering exchanges they're > present at. Then look at the cost of transport from your existing POPs to > the peering points, and work out which ones it's financially viable for you > to reach. > Thanks, i will look into peeringdb.com. Basically i just want to know if there is some "must have" locations in US, with a lot of ISP's POP on-site. Like AMS-IX in Europe. From pfunix at gmail.com Sat Oct 11 07:46:04 2008 From: pfunix at gmail.com (Beavis) Date: Sat, 11 Oct 2008 06:46:04 -0600 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: Sorry for the anonymity part Steve This is the only one email i got that is added to the NANOG List. John Lopez NOC Manager Constructora Pura Vida (506)243-018-35 Ext. 2901 On Sat, Oct 11, 2008 at 2:05 AM, Steve Linford wrote: > On 10 Oct 2008, at 20:46, Beavis wrote: > >> Hi All, >> >> DoS attack in progress, any upstream info for these guys? their >> phone number doesn't respond. >> >> inetnum: 88.247.0.0 - 88.247.79.255 >> netname: TurkTelekom >> descr: TT ADSL-alcatel static_ulus >> country: tr > > The Spamhaus folk on this list have the address of TurkTelekom's chief > security/abuse guy who would take take of this, but we would not be inclined > to give his address to someone identifying themselves as "Beavis" with a > gmail address. Can you elaborate on who you are, what's being DoSsed (a > router, an http server, a mail server?), and whether you can ACL the source > (since you know the source is in 88.247.0.0/17, why not ACL the source at > your router or at whatever device is being DoSsed). > > Steve Linford > The Spamhaus Project > http://www.spamhaus.org > > > > From simon at slimey.org Sat Oct 11 07:47:54 2008 From: simon at slimey.org (Simon Lockhart) Date: Sat, 11 Oct 2008 13:47:54 +0100 Subject: Peering for beginners In-Reply-To: <48F09FC1.3000305@webazilla.com> References: <48F09157.9030104@webazilla.com> <20081011123707.GJ18579@virtual.bogons.net> <48F09FC1.3000305@webazilla.com> Message-ID: <20081011124754.GK18579@virtual.bogons.net> On Sat Oct 11, 2008 at 03:44:49PM +0300, Konstantin Bezruchenko wrote: > Thanks, i will look into peeringdb.com. > > Basically i just want to know if there is some "must have" locations in > US, with a lot of ISP's POP on-site. Like AMS-IX in Europe. Personally, I'd suggest LINX if you want to get into Europe :-) PAIX and Equinix are the big facilities in the US, but they have sites across the country - with the biggest concentrations on the East and West coasts. If you need to get into South America, then NAP of the Americas is probably useful. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From nanog at headcandy.org Sat Oct 11 09:22:36 2008 From: nanog at headcandy.org (Steve Church) Date: Sat, 11 Oct 2008 10:22:36 -0400 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: Beavis aka John Lopez: I, for one, am glad you're interested in stopping the abuse at its source. Thank you. Steve Linford: > why not ACL the source at your router or at whatever device is being (packeted). Mr. Lopez is contributing to the welfare of the net as a whole by addressing the cause, rather than applying a bandage locally to lessen the symptom. I sincerely hope your dismissive advice is not characteristic of Spamhaus policy regarding abused hosts, considering the mission statement at the top of your homepage. Steve Church On Sat, Oct 11, 2008 at 4:05 AM, Steve Linford wrote: > On 10 Oct 2008, at 20:46, Beavis wrote: > > Hi All, >> >> DoS attack in progress, any upstream info for these guys? their >> phone number doesn't respond. >> >> inetnum: 88.247.0.0 - 88.247.79.255 >> netname: TurkTelekom >> descr: TT ADSL-alcatel static_ulus >> country: tr >> > > The Spamhaus folk on this list have the address of TurkTelekom's chief > security/abuse guy who would take take of this, but we would not be inclined > to give his address to someone identifying themselves as "Beavis" with a > gmail address. Can you elaborate on who you are, what's being DoSsed (a > router, an http server, a mail server?), and whether you can ACL the source > (since you know the source is in 88.247.0.0/17, why not ACL the source at > your router or at whatever device is being DoSsed). > > Steve Linford > The Spamhaus Project > http://www.spamhaus.org > > > > From nenolod at systeminplace.net Sat Oct 11 09:41:11 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 11 Oct 2008 09:41:11 -0500 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: <1223736071.5275.67.camel@petrie.sacredspiral.co.uk> On Sat, 2008-10-11 at 08:05 +0000, Steve Linford wrote: > On 10 Oct 2008, at 20:46, Beavis wrote: > > > Hi All, > > > > DoS attack in progress, any upstream info for these guys? their > > phone number doesn't respond. > > > > inetnum: 88.247.0.0 - 88.247.79.255 > > netname: TurkTelekom > > descr: TT ADSL-alcatel static_ulus > > country: tr > > The Spamhaus folk on this list have the address of TurkTelekom's > chief security/abuse guy who would take take of this, but we would > not be inclined to give his address to someone identifying themselves > as "Beavis" with a gmail address. Can you elaborate on who you are, > what's being DoSsed (a router, an http server, a mail server?), and > whether you can ACL the source (since you know the source is in > 88.247.0.0/17, why not ACL the source at your router or at whatever > device is being DoSsed). > You do? I can assure you there are several people who would love to have this information. Care to share with the rest of the anti-abuse community? Kind regards, William Pitcock DroneBL From linford at spamhaus.org Sat Oct 11 09:52:31 2008 From: linford at spamhaus.org (Steve Linford) Date: Sat, 11 Oct 2008 14:52:31 +0000 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: On 11 Oct 2008, at 16:22, Steve Church wrote: > Beavis aka John Lopez: > I, for one, am glad you're interested in stopping the abuse at its > source. > Thank you. > > Steve Linford: >> why not ACL the source at your router or at whatever device is being > (packeted). > Mr. Lopez is contributing to the welfare of the net as a whole by > addressing > the cause, rather than applying a bandage locally to lessen the > symptom. I > sincerely hope your dismissive advice is not characteristic of > Spamhaus > policy regarding abused hosts, considering the mission statement at > the top > of your homepage. > > Steve Church OK, you don't know much about Spamhaus. Dealing with network abuse issues is what we do 24/7. John Lopez contacted my privately and I've given him the address of TurkTelekom's security guy, but the reality of things is that today is a Saturday and tomorrow is a Sunday, unless TurkTelekom's guy is working weekends (unlikely) ACL'ing the source is not just an advisable option but is probably until Monday the only option. Steve Linford The Spamhaus Project http://www.spamhaus.org From lowen at pari.edu Sat Oct 11 11:25:23 2008 From: lowen at pari.edu (Lamar Owen) Date: Sat, 11 Oct 2008 12:25:23 -0400 Subject: transcievers/amplifiers for 150 km fiber run In-Reply-To: References: Message-ID: <200810111225.24379.lowen@pari.edu> On Friday 10 October 2008 14:50:11 Fletcher Kittredge wrote: > We are looking to light a two strand fiber link of about 95 miles (or > 150km). It would be worth a lot to us not to have repeaters. We are > hoping for Gigabit Ethernet. Sonet is possible but a less attractive > solution. Are there options for this sort of distance? The longest > current link we have is about 65 miles. I understand the transmission > characteristics of the fiber will effect distance of transmission. EDFA's can extend your power budget a few dB. Chromatic dispersion could still be an issue, though. Used units that had previous homes in CATV supertrunk applications should work well, at least for GigE; up to 120mW is easily possible (I have a few 65mW (18.1dBm) EDFA's that came as part of a donation). You hit the input of the EDFA with your ZX (1550nm) transceiver's transmit on each end, and don't look at the lit fiber or even a reflection of the lit fiber (IOW, wear laser safety goggles). And don't even think about looping the EDFA output back around without many dB of attenuation. At this power level you will have to use angle polish connectors at the EDFA output (the green SC/SPC or FC/APC ones) or you can burn out the pump laser with the reflections. You also will need to notify your carrier's tech department of the power level with which you're lighting that fiber, as even several km down fiber from an EDFA is in Class IIIB laser territory. A bare Cisco ZX GBIC or SFP is rated to light 70km of ordinary singlemoder fiber, and up to 100km of either premium (low-loss) or dispersion-shifted (which is also low-loss) singlemode fiber. The rated output is between 0 and +5dBm (1 and 3.2 mW) for the ZX laser. The link budget is 23dB for the standard ZX optics. With a high-gain EDFA outputting 13 more dBm of power (20 times the power) you can get a link budget for loss of 36dB; which could increase your range 40km, on ordinary fiber. So, in a nutshell, you'd take the TX from a ZX SFP or GBIC, a few feet worth of jumper to an EDFA, and light the fiber (with APC connectors only) from the EDFA output. You do this at both ends. From tvarriale at comcast.net Sat Oct 11 12:11:26 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Sat, 11 Oct 2008 12:11:26 -0500 Subject: Peering for beginners References: <48F09157.9030104@webazilla.com><20081011123707.GJ18579@virtual.bogons.net><48F09FC1.3000305@webazilla.com> <20081011124754.GK18579@virtual.bogons.net> Message-ID: <002101c92bc4$653dc0a0$0100fea9@flamadam> E has a significant presence in Chicago so don't leave us out. :) tv ----- Original Message ----- From: "Simon Lockhart" To: "Konstantin Bezruchenko" Cc: "North American Network Operators Group" Sent: Saturday, October 11, 2008 7:47 AM Subject: Re: Peering for beginners > On Sat Oct 11, 2008 at 03:44:49PM +0300, Konstantin Bezruchenko wrote: >> Thanks, i will look into peeringdb.com. >> >> Basically i just want to know if there is some "must have" locations in >> US, with a lot of ISP's POP on-site. Like AMS-IX in Europe. > > Personally, I'd suggest LINX if you want to get into Europe :-) > > PAIX and Equinix are the big facilities in the US, but they have sites > across the country - with the biggest concentrations on the East and West > coasts. If you need to get into South America, then NAP of the Americas is > probably useful. > > Simon > -- > Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * > Director | * Domain & Web Hosting * Internet Consultancy * > Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * > From fergdawgster at gmail.com Sat Oct 11 13:39:46 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 11 Oct 2008 11:39:46 -0700 Subject: Peering for beginners In-Reply-To: <48F09157.9030104@webazilla.com> References: <48F09157.9030104@webazilla.com> Message-ID: <6cd462c00810111139q4454ae0dle68064048b7304d5@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Oct 11, 2008 at 4:43 AM, Konstantin Bezruchenko wrote: > Hi, > > Our comapny going to build some peering POP across USA, and i really > don't know where is the best place to have first POP? > > Please advice. > > Thanks > > - Konstantin N. Bezruchenko > Out of curiosity, is this for AS35415? http://www.cidr-report.org/cgi-bin/as-report?as=AS35415 Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI8PLfq1pz9mNUZTMRAiJsAKCJG7ZkM4wgV0sNCNKMZW+cFcWGFACgpIT4 J4LVFTsIFXluEmTUQCwfmUY= =y8y3 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nanog at webazilla.com Sat Oct 11 14:29:24 2008 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Sat, 11 Oct 2008 22:29:24 +0300 Subject: Peering for beginners In-Reply-To: <6cd462c00810111139q4454ae0dle68064048b7304d5@mail.gmail.com> References: <48F09157.9030104@webazilla.com> <6cd462c00810111139q4454ae0dle68064048b7304d5@mail.gmail.com> Message-ID: <48F0FE94.6060405@webazilla.com> Hello, Paul Ferguson wrote: > > Out of curiosity, is this for AS35415? > > http://www.cidr-report.org/cgi-bin/as-report?as=AS35415 > Nope. It's for our another AS. AS35415 is for Europe only. From trelane at trelane.net Sat Oct 11 14:35:44 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sat, 11 Oct 2008 15:35:44 -0400 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: <48F10010.9050703@trelane.net> Steve Church wrote: > Beavis aka John Lopez: > I, for one, am glad you're interested in stopping the abuse at its source. > Thank you. > > Steve Linford: > >> why not ACL the source at your router or at whatever device is being >> > (packeted). > Mr. Lopez is contributing to the welfare of the net as a whole by addressing > the cause, rather than applying a bandage locally to lessen the symptom. I > sincerely hope your dismissive advice is not characteristic of Spamhaus > policy regarding abused hosts, considering the mission statement at the top > of your homepage. > > Steve Church Come on, even I think Steve Linford's bonafides are strong enough that this was uncalled for. Andrew From todd at renesys.com Sat Oct 11 15:02:21 2008 From: todd at renesys.com (Todd Underwood) Date: Sat, 11 Oct 2008 20:02:21 +0000 Subject: lighting talks and the program committee Message-ID: <20081011200221.GW20914@renesys.com> two quick reminders as many of us head towards LA for the conference: 1) there have been some excellent lightning talks submitted but there are still more slots availble than talks submitted. if you have an idea and can whip up an abstract by tomorrow and a talk by monday, you still stand an excellent chance of getting to present at this nanog. i've heard lots of good ideas that i have yet to see in lightning talks. so send 'em in! http://www.nanogpc.org/lightning/ has the information on how to submit talks. 2) many slots in the nanog program committee are opening up. the program committee is the group of 16 people responsible for recruiting and selecting the entire set of talks/presentations/bofs you see at nanog. most of you are *positive* you could do a better job than we have been doing. of that i have no doubt. so please submit your name to be considered for a slot. there is a certain amount of work involved (about 4 conference calls per nanog and the requirement to read/vote/comment on almost every submitted talk) but the rewards in fame and infamy are well worth it. more information is here: http://www.nanog.org/governance/elections/2008elections/ you can nominate yourself or someone else by sending mail to: nominations at nanog.org looking forward to seeing many of you in LA tomorrow. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From ops.lists at gmail.com Sat Oct 11 17:23:08 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 12 Oct 2008 03:53:08 +0530 Subject: DDoS Attack in Progress. In-Reply-To: References: Message-ID: On Sat, Oct 11, 2008 at 7:52 PM, Steve Church wrote: > Mr. Lopez is contributing to the welfare of the net as a whole by addressing > the cause, rather than applying a bandage locally to lessen the symptom. I > sincerely hope your dismissive advice is not characteristic of Spamhaus > policy regarding abused hosts, considering the mission statement at the top > of your homepage. Let's put it this way. Contacts given in confidence arent meant to be shared randomly. Or to people who dont identify themselves and post using freemail addresses. Linford seems to have shared this contact offlist with the guy, after he identified himelf, so case closed. srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From tomb at byrneit.net Sat Oct 11 20:03:42 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 11 Oct 2008 18:03:42 -0700 Subject: transceivers/amplifiers for 150 km fiber run In-Reply-To: <9e246b4d0810101348w7d56fa01lbe76ff466acb63a6@mail.gmail.com> References: <9e246b4d0810101348w7d56fa01lbe76ff466acb63a6@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F6F9@pascal.zaphodb.org> http://www.ipitek.com/products/broadband/ethernet.htm used by Cox and others. http://www.ipitek.com/products/subsystems/transceivers.htm Certified to 120Km, you may be able to run it further. >-----Original Message----- >From: Tim Durack [mailto:tdurack at gmail.com] >Sent: Friday, October 10, 2008 1:49 PM >To: Fletcher Kittredge >Cc: nanog at nanog.org >Subject: Re: transcievers/amplifiers for 150 km fiber run > >These guys claim upto 180km: > >http://www.bookham.com/datasheets/transceivers/IGP-28111.cfm > >Tim:> > >On Fri, Oct 10, 2008 at 4:23 PM, Fletcher Kittredge >wrote: > >> Thanks to all that replied. A bit more background: By regulation, >the >> local ILEC is required to supply us with dark fiber where available. >They >> have taken the regulatory stance that it is not technically possible >to use >> dark fiber runs of more than 60 miles (prior, their regulatory stance >was >> runs of more than twenty miles were not technically feasible.) Our >> counter-argument has been that we have existing fiber runs of 63 miles >and >> 59 miles that work well without special equipment. We are now >arguing >> about a particular fiber run in rural Maine of about 91 miles. Our >> position is it is technically feasible, depending on fiber >characteristics, >> to light 91 miles of fiber. Their position is that runs of more than >60 >> miles are not feasible. I was hoping to bolster our argument by >pointing >> to data sheets of optical transcievers rated up to 150 km. Then, >after we >> get the fiber, I was hoping to buy said equipment. >> >> regards, >> Fletcher >> >> On Fri, Oct 10, 2008 at 2:50 PM, Fletcher Kittredge >> wrote: >> >> > We are looking to light a two strand fiber link of about 95 miles >(or >> > 150km). It would be worth a lot to us not to have repeaters. We >are >> > hoping for Gigabit Ethernet. Sonet is possible but a less >attractive >> > solution. Are there options for this sort of distance? The >longest >> > current link we have is about 65 miles. I understand the >transmission >> > characteristics of the fiber will effect distance of transmission. >> > >> > regards, >> > Fletcher >> > >> > -- >> > Fletcher Kittredge >> > GWI >> > 8 Pomerleau Street >> > Biddeford, ME 04005-9457 >> > 207-602-1134 >> > >> >> >> >> -- >> Fletcher Kittredge >> GWI >> 8 Pomerleau Street >> Biddeford, ME 04005-9457 >> 207-602-1134 >> From j at arpa.com Sun Oct 12 05:53:48 2008 From: j at arpa.com (jamie) Date: Sun, 12 Oct 2008 05:53:48 -0500 Subject: Paging Ultradns/neustar neteng Message-ID: UltraDNS / Neustar netengs : There is a routing instability in one view of a small part of your network that?s none the less making my phone blow up. (pdns4) Your noc guys didn?t exactly get what I was trying to explain ; refer to SR 1-48803905 for some data. An off-list ack would be cool in any case; I have an unrelated curiosity or two I?d like to throw at some neustar clue. tia, -jamie From francois at menards.ca Sun Oct 12 07:16:19 2008 From: francois at menards.ca (Francois Menard) Date: Sun, 12 Oct 2008 08:16:19 -0400 Subject: transcievers/amplifiers for 150 km fiber run In-Reply-To: <200810111225.24379.lowen@pari.edu> References: <200810111225.24379.lowen@pari.edu> Message-ID: or you buy some boxes from BTI Photonics that specialize into taking GigE around the world... F. -- Fran?ois D. M?nard francois at menards.ca On 11-Oct-08, at 12:25 PM, Lamar Owen wrote: > On Friday 10 October 2008 14:50:11 Fletcher Kittredge wrote: >> We are looking to light a two strand fiber link of about 95 miles (or >> 150km). It would be worth a lot to us not to have repeaters. We >> are >> hoping for Gigabit Ethernet. Sonet is possible but a less >> attractive >> solution. Are there options for this sort of distance? The longest >> current link we have is about 65 miles. I understand the >> transmission >> characteristics of the fiber will effect distance of transmission. > > EDFA's can extend your power budget a few dB. Chromatic dispersion > could > still be an issue, though. > > Used units that had previous homes in CATV supertrunk applications > should work > well, at least for GigE; up to 120mW is easily possible (I have a > few 65mW > (18.1dBm) EDFA's that came as part of a donation). You hit the > input of the > EDFA with your ZX (1550nm) transceiver's transmit on each end, and > don't look > at the lit fiber or even a reflection of the lit fiber (IOW, wear > laser > safety goggles). And don't even think about looping the EDFA output > back > around without many dB of attenuation. > > At this power level you will have to use angle polish connectors at > the EDFA > output (the green SC/SPC or FC/APC ones) or you can burn out the > pump laser > with the reflections. > > You also will need to notify your carrier's tech department of the > power level > with which you're lighting that fiber, as even several km down fiber > from an > EDFA is in Class IIIB laser territory. > > A bare Cisco ZX GBIC or SFP is rated to light 70km of ordinary > singlemoder > fiber, and up to 100km of either premium (low-loss) or dispersion- > shifted > (which is also low-loss) singlemode fiber. The rated output is > between 0 and > +5dBm (1 and 3.2 mW) for the ZX laser. The link budget is 23dB for > the > standard ZX optics. With a high-gain EDFA outputting 13 more dBm of > power > (20 times the power) you can get a link budget for loss of 36dB; > which could > increase your range 40km, on ordinary fiber. > > So, in a nutshell, you'd take the TX from a ZX SFP or GBIC, a few > feet worth > of jumper to an EDFA, and light the fiber (with APC connectors only) > from the > EDFA output. You do this at both ends. > From max.clark at gmail.com Sun Oct 12 11:07:29 2008 From: max.clark at gmail.com (Max Clark) Date: Sun, 12 Oct 2008 09:07:29 -0700 Subject: IPv6 Wow Message-ID: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> I'm in LA with Time Warner Cable - didn't know they rolled out an IPv6 link to AMS-IX. HOST: macbook.local Loss% Snt Last Avg Best Wrst StDev 1. 2002:4ca6:18c5::21b:63ff:fef 0.0% 10 0.8 1.5 0.7 4.6 1.2 2. 2002:82f4:21::1 50.0% 10 185.4 188.3 185.4 197.1 5.0 3. 2a00:800:0:1::2:2 0.0% 10 219.8 215.3 205.8 229.9 8.6 4. ams-ix.he.net 0.0% 10 200.9 192.0 187.0 201.9 5.6 5. 10gigabitethernet1-4.core1.l 0.0% 10 195.7 198.1 192.8 214.1 6.5 6. 10gigabitethernet2-3.core1.n 0.0% 10 275.4 266.4 261.7 275.4 3.8 7. 10gigabitethernet3-1.core1.s 0.0% 10 344.4 345.1 342.4 351.0 2.4 8. 10gigabitethernet3-2.core1.p 0.0% 10 350.8 350.0 342.4 364.5 7.5 9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 From nenolod at systeminplace.net Sun Oct 12 12:29:31 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Sun, 12 Oct 2008 12:29:31 -0500 Subject: IPv6 Wow In-Reply-To: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> Message-ID: <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> Hello, That is 6to4. You can tell due to the (2002::) prefix. William Pitcock SystemInPlace On Sun, 2008-10-12 at 09:07 -0700, Max Clark wrote: > I'm in LA with Time Warner Cable - didn't know they rolled out an IPv6 > link to AMS-IX. > > HOST: macbook.local Loss% Snt Last Avg Best Wrst StDev > 1. 2002:4ca6:18c5::21b:63ff:fef 0.0% 10 0.8 1.5 0.7 4.6 1.2 > 2. 2002:82f4:21::1 50.0% 10 185.4 188.3 185.4 197.1 5.0 > 3. 2a00:800:0:1::2:2 0.0% 10 219.8 215.3 205.8 229.9 8.6 > 4. ams-ix.he.net 0.0% 10 200.9 192.0 187.0 201.9 5.6 > 5. 10gigabitethernet1-4.core1.l 0.0% 10 195.7 198.1 192.8 214.1 6.5 > 6. 10gigabitethernet2-3.core1.n 0.0% 10 275.4 266.4 261.7 275.4 3.8 > 7. 10gigabitethernet3-1.core1.s 0.0% 10 344.4 345.1 342.4 351.0 2.4 > 8. 10gigabitethernet3-2.core1.p 0.0% 10 350.8 350.0 342.4 364.5 7.5 > 9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > From mohacsi at niif.hu Sun Oct 12 12:48:53 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sun, 12 Oct 2008 19:48:53 +0200 (CEST) Subject: Help needed - Cisco Netflow In-Reply-To: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D097FCBC283@GVW1100EXC.americas.hpqcorp.net> Message-ID: On Fri, 10 Oct 2008, Lee, Steven (NSG Malaysia) wrote: > Hi all, I have a customer who has a MPLS network for E/// Media Gateway > (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR traffic is > fixed size 110 bytes. During the high load period, it can reaches > 450Kpps on a STM-1 link. The router platform is Cisco 12000 series, can > the router generate 100% netflow data with such traffic load? Also can > someone suggest a carrier class netflow collector for mobile service > provider environment. Forget full netflow with 12000. It is not supported.... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > Thanks in advance. > > Regards, > Steven Lee > > From nanog at daork.net Sun Oct 12 13:02:14 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 13 Oct 2008 07:02:14 +1300 Subject: IPv6 Wow In-Reply-To: <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> Message-ID: <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> On 13/10/2008, at 6:29 AM, William Pitcock wrote: > Hello, > > That is 6to4. You can tell due to the (2002::) prefix. And using a relay at Tele2 AB (Sweden). So really Max, all your outbound IPv6 packets are going via Sweden, even if they're going to elsewhere in the US. In order to get around this, encourage your ISP to build a 6to4 relay, which is a couple of commands on a spare Cisco router. For extra points, get them to build out a Teredo relay as well, which is a few commands on a spare Linux box. -- Nathan Ward From swmike at swm.pp.se Sun Oct 12 13:52:16 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 12 Oct 2008 20:52:16 +0200 (CEST) Subject: IPv6 Wow In-Reply-To: <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> Message-ID: On Mon, 13 Oct 2008, Nathan Ward wrote: > And using a relay at Tele2 AB (Sweden). > > So really Max, all your outbound IPv6 packets are going via Sweden, even > if they're going to elsewhere in the US. Well, actually, Tele2 has 6to4 relays in Stockholm, Paris, Amsterdam and Frankfurt. But correct, it's a relay in Europe that is being used. > In order to get around this, encourage your ISP to build a 6to4 relay, which > is a couple of commands on a spare Cisco router. For extra points, get them > to build out a Teredo relay as well, which is a few commands on a spare Linux > box. We have very good experience with 7600 for 6to4 relay usage. This brings up an interesting question, should we stop announcing our 6to4 relays outside of Europe? Is there consensus in the business how this should be done? I have heard opinions both ways. -- Mikael Abrahamsson email: swmike at swm.pp.se From pfs at cisco.com Sun Oct 12 15:36:40 2008 From: pfs at cisco.com (Philip Smith) Date: Mon, 13 Oct 2008 06:36:40 +1000 Subject: [NANOG-announce] NANOG Voting now open! Message-ID: <48F25FD8.604@cisco.com> Hi everyone, Voting for the 2008 NANOG SC and Charter amendments is now open. Please refer to http://www.nanog.org/governance/elections/2008elections/ for full details. The actual voting URL is https://nanog.merit.edu/election/. You will need to use your NANOG id and password to cast your vote. Eligible voters are listed at http://www.nanog.org/governance/elections/2008elections/2008_voters.php. The ballot will close on Tuesday at 1pm PDT and the results will be announced by the end of the day. philip (for the SC) -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From stephen at sprunk.org Sun Oct 12 15:53:13 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 12 Oct 2008 15:53:13 -0500 Subject: IPv6 Wow In-Reply-To: References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> Message-ID: <48F263B9.80007@sprunk.org> Mikael Abrahamsson wrote: > This brings up an interesting question, should we stop announcing our > 6to4 relays outside of Europe? Is there consensus in the business how > this should be done? I have heard opinions both ways. I can understand why some folks would say stop, but unfortunately Europe has the closest public 6to4 relays to the US, and our own providers don't seem to want to put any up. That means 6to4 will break for a great many folks who _are_ trying to use IPv6 (like developers trying to get ahead of the curve and make sure their apps don't break when the transition finally happens) but whose providers haven't clued in yet. (My traceroutes to 192.88.99.1 have a next-to-last hop in Amsterdam, and I'm on one of the largest ISPs in the US, which apparently hasn't figured out 6to4, much less native IPv6.) S From nanog at daork.net Sun Oct 12 17:05:01 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 13 Oct 2008 11:05:01 +1300 Subject: IPv6 Wow In-Reply-To: <48F263B9.80007@sprunk.org> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> Message-ID: <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> On 13/10/2008, at 9:53 AM, Stephen Sprunk wrote: > Mikael Abrahamsson wrote: >> This brings up an interesting question, should we stop announcing >> our 6to4 relays outside of Europe? Is there consensus in the >> business how this should be done? I have heard opinions both ways. > > I can understand why some folks would say stop, but unfortunately > Europe has the closest public 6to4 relays to the US, and our own > providers don't seem to want to put any up. That means 6to4 will > break for a great many folks who _are_ trying to use IPv6 (like > developers trying to get ahead of the curve and make sure their apps > don't break when the transition finally happens) but whose providers > haven't clued in yet. I'm sure I sound like a broken record to some, but whenever I see these comments I feel the need to step up and correct them, until I don't see them anymore. By far the biggest end users of IPv6 are non-experimenters. Real end users, many of whom do not know what an IP address is. 6to4 is enabled by default in Vista - any Vista machine with a non- RFC1918 address will use 6to4. It is also available in some linksys routers, and is enabled by default in Apple Airport Extreme. > (My traceroutes to 192.88.99.1 have a next-to-last hop in Amsterdam, > and I'm on one of the largest ISPs in the US, which apparently > hasn't figured out 6to4, much less native IPv6.) There are public 6to4 relays in the US, I guess your provider just has a shorter ASPATH to somewhere in Europe. Unfortunately BGP had no idea of geography :-) Re. whether to advertise outside your continent, it really depends whether you're trying to achieve 'good enough' connectivity for 100% of people, or really good connectivity for 95% of people. Perhaps a good way to do it is advertise outside Europe, but have the providers that get your advertisement out there prepend their AS a few times as it leaves. That way, US providers will still prefer US 6to4 relays (ie lower latency) but any who don't get a 192.88.99.0/24 route from the US will us your relay in Europe. Kinda gets you best of both worlds. -- Nathan Ward From toasty at dragondata.com Sun Oct 12 18:03:00 2008 From: toasty at dragondata.com (Kevin Day) Date: Sun, 12 Oct 2008 18:03:00 -0500 Subject: IPv6 Wow In-Reply-To: <48F263B9.80007@sprunk.org> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> Message-ID: <6F73DC8D-AEC7-41B9-870C-2D5FAD633831@dragondata.com> On Oct 12, 2008, at 3:53 PM, Stephen Sprunk wrote: > > I can understand why some folks would say stop, but unfortunately > Europe has the closest public 6to4 relays to the US, and our own > providers don't seem to want to put any up. There are quite a few 6to4 relays outside Europe. I think the problem more is that a lot of providers haven't gotten the hang of routing to an anycasted prefix that so many people are announcing. Or making sure 6to4 is fast is so far down their priority list they just don't care. Either way, peering seems to be a lot more dense in Europe, so they're more likely to be peering with someone announcing a 6to4 relay there. Prefer sending traffic to someone you're peering with (even if it's further away) to someone local that you have to pay for, and you don't always get sensible routing on a prefix like this. From the best that I can tell, here's a reasonably complete list of who are running 6to4 relays... Its not easy to tell what country someone's relay is in, but this is probably close. Oceania/Asia: Australia: 1221 Telstra Korea: 17832 NISA Europe: Denmark: 1835 FSK Net Estonia: 3327 Linxtelecom Finland: 1741 FUNET Germany: 286 kpn.de 5430 Freenet 8767 m-net.de 12816 mwn 15598 IP Exchange 20640 Titan 29259 IABG Teleport 35244 kms.de Italy: 12779 itgate.net Netherlands: 1101 SURFNet 8954 InTouch 26943 Your.Org 31383 Computel Portugal: 1930 FCCN Spain: 16206 Abared Sweden: 1257 Tele2 16150 GlobalTransit Switzerland: 559 switch.ch United Kingdom: 5400 BT North America: US: 59 University of Wisconsin 109 Cisco 1239 Sprint 3344 Kewlio 5050 Pittsburgh Supercomputing Center 6175 Sprint 7019 NTT 10533 Ottawa Internet Exchange 19255 Your.Org 19782 Indiana University 25795 ARP Networks From andree+nanog at toonk.nl Sun Oct 12 21:12:57 2008 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 13 Oct 2008 04:12:57 +0200 Subject: BGP (hijack) prefix monitoring Message-ID: <20081013021257.GA4348@toonk.nl> Hi All, Given the recent interest in prefix monitoring (hijack) systems I decided to make my monitoring system publicly accessible for those who would like to use it. The original software was written over the course of 1.5 years, mainly for private use to monitor the stability of our prefixes. After some requests of others I've extended it to make it usable for different users and added some extra features. It has most of the functionality that other alternatives offer, these include: * Prefix hijack detection * support for aspath regex checks (including auto generate regex) * 4byte ASN support * support for auo discovery of prefixes for a specific Origin AS (useful for bulk entries) * Flexible email alerting system * Historical overview of "Interesting" updates * Support for multiple AS's per user * BGP updates (ipv4&ipv6) from over 120 peers, (several RIPE-RIS data sources) * Alert on "mass" withdraw of your prefix I documented most of the features as well as some background info in a FAQ at http://bgpmon.net/faq.php Anyway, for those of you who want to use it, please go ahead and try it. You can create a personal account and add your own prefixes, or browse around using the demo account. The url is: http://bgpmon.net Other things you will find there are the 'BGP weathermap' and some basic bogon detection. Hope you'll find it useful. Cheers, Andree From dts at senie.com Sun Oct 12 21:46:52 2008 From: dts at senie.com (Daniel Senie) Date: Sun, 12 Oct 2008 22:46:52 -0400 Subject: IPv6 Wow In-Reply-To: <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> Message-ID: <200810130246.m9D2kt79010996@parsley.amaranth.net> At 06:05 PM 10/12/2008, Nathan Ward wrote: >On 13/10/2008, at 9:53 AM, Stephen Sprunk wrote: > >>Mikael Abrahamsson wrote: >>>This brings up an interesting question, should we stop announcing >>>our 6to4 relays outside of Europe? Is there consensus in the >>>business how this should be done? I have heard opinions both ways. >> >>I can understand why some folks would say stop, but unfortunately >>Europe has the closest public 6to4 relays to the US, and our own >>providers don't seem to want to put any up. That means 6to4 will >>break for a great many folks who _are_ trying to use IPv6 (like >>developers trying to get ahead of the curve and make sure their apps >>don't break when the transition finally happens) but whose providers >>haven't clued in yet. > >I'm sure I sound like a broken record to some, but whenever I see >these comments I feel the need to step up and correct them, until I >don't see them anymore. > >By far the biggest end users of IPv6 are non-experimenters. Real end >users, many of whom do not know what an IP address is. > >6to4 is enabled by default in Vista - any Vista machine with a non- >RFC1918 address will use 6to4. It is also available in some linksys >routers, and is enabled by default in Apple Airport Extreme. Not to rain on anyone's parade, but it'd be interesting (and difficult, unfortunately) to know how many Vista machines are actually on non-RFC1918 addresses. Corporate users are in many cases staying with XP for a while, but they're more likely to have public space than most. A great many home users have a cheap NAT box that provides RFC1918 addresses. I do wonder whether where the Vista machines on public IPs really are. I also have to wonder if performance is really better when those users are routed over 6to4 in Europe from, say California, or whether they'd actually get better performance if they stuck in a NAT box, resulting in their using IPv4 instead? From nanog at daork.net Sun Oct 12 22:01:54 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 13 Oct 2008 16:01:54 +1300 Subject: IPv6 Wow In-Reply-To: <200810130246.m9D2kt79010996@parsley.amaranth.net> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> <200810130246.m9D2kt79010996@parsley.amaranth.net> Message-ID: On 13/10/2008, at 3:46 PM, Daniel Senie wrote: > At 06:05 PM 10/12/2008, Nathan Ward wrote: >> On 13/10/2008, at 9:53 AM, Stephen Sprunk wrote: >> >>> Mikael Abrahamsson wrote: >>>> This brings up an interesting question, should we stop announcing >>>> our 6to4 relays outside of Europe? Is there consensus in the >>>> business how this should be done? I have heard opinions both ways. >>> >>> I can understand why some folks would say stop, but unfortunately >>> Europe has the closest public 6to4 relays to the US, and our own >>> providers don't seem to want to put any up. That means 6to4 will >>> break for a great many folks who _are_ trying to use IPv6 (like >>> developers trying to get ahead of the curve and make sure their apps >>> don't break when the transition finally happens) but whose providers >>> haven't clued in yet. >> >> I'm sure I sound like a broken record to some, but whenever I see >> these comments I feel the need to step up and correct them, until I >> don't see them anymore. >> >> By far the biggest end users of IPv6 are non-experimenters. Real end >> users, many of whom do not know what an IP address is. >> >> 6to4 is enabled by default in Vista - any Vista machine with a non- >> RFC1918 address will use 6to4. It is also available in some linksys >> routers, and is enabled by default in Apple Airport Extreme. > > Not to rain on anyone's parade, but it'd be interesting (and > difficult, unfortunately) to know how many Vista machines are > actually on non-RFC1918 addresses. Corporate users are in many cases > staying with XP for a while, but they're more likely to have public > space than most. A great many home users have a cheap NAT box that > provides RFC1918 addresses. > > I do wonder whether where the Vista machines on public IPs really > are. I also have to wonder if performance is really better when > those users are routed over 6to4 in Europe from, say California, or > whether they'd actually get better performance if they stuck in a > NAT box, resulting in their using IPv4 instead? Don't worry, you're not raining on my parade if that's what you're concerned about. I don't like Vista/XPSP2 having 6to4, Teredo is the protocol designed to connect end hosts to the IPv6 network. That works through NAT, and is enabled by default on Vista. 6to4 should existing in CPE devices, etc. not in end hosts. Cue religious war. Also, Windows boxes that are part of a domain will only try ISATAP and native IPv6 - they will not attempt to tunnel IPv6 over IPv4 using public relays (ISATAP is an internal thing). I did a bit of stats, and roughly 95% of packets leaving an ISP's aggregation layer were from hosts behind NAT (look at TTL, make assumptions based on initial TTL). So, 6to4 is only on 5% of customers, assuming that % of packets and % of customers are roughly equal. Here's a mini-rant I had about Teredo traffic offlist when someone said they had very little 6to4 traffic. I thought it was on-list. begin. I suspect you'll find that Teredo contributes to a very large amount of it, but you won't be seeing it as you don't have a local Teredo relay (in my understanding of your network, anyway :-) Even then you won't see Teredo<->Teredo, or Teredo<->NonTeredo when NonTeredo is on another network. An interesting way to get a rough idea of how much Teredo<->NotTeredo is going on is to look at the packets going to teredo.ipv6.microsoft.com port 3544/UDP. Every Vista/XPSP2 Teredo client will send a UDP packet there every 30 seconds (IIRC), and then another packet for every new NonTeredo host it wants to talk to. Source UDP port is generally static and unique for each client host, so you can get an idea for unique number of hosts. The periodic packets are going to be 68b (of IPv4+UDP+IPv6 = 68b), whereas the new-connection packets are going to be at least 76b (IPv4+UDP+IPv6+ICMPv6+Echo Request = 76b, then there's also the ICMPv6 Echo Request payload). Obviously you want to add 14b if you've got ethernet headers and what not. If you have netflow anywhere, you should be able to ask it an appropriate question with the above info. That'll tell you number of end-to-end connections there are which may give you some insight there. If you've got a netflow exporter, I'd be more than happy to run stats over the data to figure out what amount of Teredo there is. end. -- Nathan Ward From swmike at swm.pp.se Mon Oct 13 01:18:14 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 13 Oct 2008 08:18:14 +0200 (CEST) Subject: IPv6 Wow In-Reply-To: <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> Message-ID: On Mon, 13 Oct 2008, Nathan Ward wrote: > 6to4 is enabled by default in Vista - any Vista machine with a > non-RFC1918 address will use 6to4. It is also available in some linksys > routers, and is enabled by default in Apple Airport Extreme. I've been told there is a difference between OEM and non-OEM Vista machines when it comes to Teredo being activated or not. > Perhaps a good way to do it is advertise outside Europe, but have the > providers that get your advertisement out there prepend their AS a few > times as it leaves. That way, US providers will still prefer US 6to4 > relays (ie lower latency) but any who don't get a 192.88.99.0/24 route > from the US will us your relay in Europe. Kinda gets you best of both > worlds. Yeah, that's been one option as well, prepending 2-3 times to our peers/transit in the US is probably a good middle way. Regarding some numbers on 6to4 and Teredo usage, I'd like to point people to this thread on the ipv6ops IETF list: If someone has some nice code that'll take a list of IPv6 addresses and break it down to geographical distribution of native/teredo/6to4, I'd be more than happy to run it on my data. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Mon Oct 13 01:24:07 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 13 Oct 2008 08:24:07 +0200 (CEST) Subject: IPv6 Wow In-Reply-To: <200810130246.m9D2kt79010996@parsley.amaranth.net> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> <200810130246.m9D2kt79010996@parsley.amaranth.net> Message-ID: On Sun, 12 Oct 2008, Daniel Senie wrote: > I do wonder whether where the Vista machines on public IPs really are. I > also have to wonder if performance is really better when those users are > routed over 6to4 in Europe from, say California, or whether they'd > actually get better performance if they stuck in a NAT box, resulting in > their using IPv4 instead? I'd say it's very rare where IPv6 will give you better performance than IPv4 right now. Regarding where they are, I'd say all over the place. It's very common in my regional market to hand out one or more public IPs, and if the customer doesn't put their own NAT box there, then their Vista computer(s) will have public IPs and will use 6to4. Regarding 6to4 or Teredo, I've done some testing of my own and the statelessness of 6to4 makes it avoid some of the session setup/NAT travesal magic of Teredo that slows Teredo down. I'd much rather see the NAT boxes do 6to4 and run native on their local LAN segment, than having end hosts do Teredo to get thru the NAT. It'll give the end user a better IPv6 experience. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Mon Oct 13 01:34:31 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 13 Oct 2008 19:34:31 +1300 Subject: IPv6 Wow In-Reply-To: References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> <200810130246.m9D2kt79010996@parsley.amaranth.net> Message-ID: <7EDA8DD1-5205-424B-BA9F-C91EE761A6A3@daork.net> On 13/10/2008, at 7:24 PM, Mikael Abrahamsson wrote: > On Sun, 12 Oct 2008, Daniel Senie wrote: > >> I do wonder whether where the Vista machines on public IPs really >> are. I also have to wonder if performance is really better when >> those users are routed over 6to4 in Europe from, say California, or >> whether they'd actually get better performance if they stuck in a >> NAT box, resulting in their using IPv4 instead? > > I'd say it's very rare where IPv6 will give you better performance > than IPv4 right now. > > Regarding where they are, I'd say all over the place. It's very > common in my regional market to hand out one or more public IPs, and > if the customer doesn't put their own NAT box there, then their > Vista computer(s) will have public IPs and will use 6to4. > > Regarding 6to4 or Teredo, I've done some testing of my own and the > statelessness of 6to4 makes it avoid some of the session setup/NAT > travesal magic of Teredo that slows Teredo down. I'd much rather see > the NAT boxes do 6to4 and run native on their local LAN segment, > than having end hosts do Teredo to get thru the NAT. It'll give the > end user a better IPv6 experience. Long term I agree, but short term I prefer Teredo for regular end users' experience. Where regular end user means an end user communicates with a relatively small number of remote hosts. Several reasons: 1) 6to4 currently lacks a testing mechanism to ensure that it is functioning at startup, and that it is still functioning. Packets are sent and blackholed by the network, resulting in a 90s timeout waiting for a response to the three SYN packets in a TCP connection set up. 90s is a long time for users today, and my experience shows that they consider a service to be 'broken' before they wait for the timeout to expire. 2) If Teredo relays are deployed close to the service (ie. content, etc.) then performance is almost equivalent to IPv4. 6to4 relies on relays being close to both the client and the server, which requires end users' ISPs to build at least *some* IPv6 infrastructure, maintain transit, etc. When you consider that this infrastructure and transit is quite likely to be over long tunnels to weird parts of the world, this is a bad thing. Putting relays close to the content helps for the reverse path (ie. content -> client), however the forward path (client -> content) is likely to perform poorly. -- Nathan Ward From cfriacas at fccn.pt Mon Oct 13 02:06:17 2008 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 13 Oct 2008 08:06:17 +0100 (WEST) Subject: IPv6 Wow In-Reply-To: References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> <200810130246.m9D2kt79010996@parsley.amaranth.net> Message-ID: On Mon, 13 Oct 2008, Mikael Abrahamsson wrote: > On Sun, 12 Oct 2008, Daniel Senie wrote: > >> I do wonder whether where the Vista machines on public IPs really are. I >> also have to wonder if performance is really better when those users are >> routed over 6to4 in Europe from, say California, or whether they'd actually >> get better performance if they stuck in a NAT box, resulting in their using >> IPv4 instead? > > I'd say it's very rare where IPv6 will give you better performance than IPv4 > right now. Rare = Absolutely Yes. Impossible = No :-) > Regarding where they are, I'd say all over the place. It's very common in my > regional market to hand out one or more public IPs, and if the customer > doesn't put their own NAT box there, then their Vista computer(s) will have > public IPs and will use 6to4. > > Regarding 6to4 or Teredo, I've done some testing of my own and the > statelessness of 6to4 makes it avoid some of the session setup/NAT travesal > magic of Teredo that slows Teredo down. I'd much rather see the NAT boxes do > 6to4 and run native on their local LAN segment, than having end hosts do > Teredo to get thru the NAT. It'll give the end user a better IPv6 experience. Fully agree. Unfortunately not every NATbox/cheap-consumer-router is happy to pass on 6to4 packets to its next hop :-( > -- > Mikael Abrahamsson email: swmike at swm.pp.se > Cheers, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.6deploy.org Av. do Brasil, n.101 www.ipv6.eu 1700-066 Lisboa, Portugal, Europe Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (282391/1511), naming (billions) and... people!" Esta mensagem foi enviada de: / This message was sent from: 2001:690:2080:8004:250:daff:fe3b:2830 Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received due to any error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately. From nanog at daork.net Mon Oct 13 02:13:14 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 13 Oct 2008 20:13:14 +1300 Subject: IPv6 Wow In-Reply-To: References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> Message-ID: On 13/10/2008, at 7:18 PM, Mikael Abrahamsson wrote: > On Mon, 13 Oct 2008, Nathan Ward wrote: > >> 6to4 is enabled by default in Vista - any Vista machine with a non- >> RFC1918 address will use 6to4. It is also available in some linksys >> routers, and is enabled by default in Apple Airport Extreme. > > I've been told there is a difference between OEM and non-OEM Vista > machines when it comes to Teredo being activated or not. I've not heard that, I'll be interested if someone can confirm? Perhaps certain vendors disable IPv6 because of the lack of relays etc. in the network causing performance problems. >> Perhaps a good way to do it is advertise outside Europe, but have >> the providers that get your advertisement out there prepend their >> AS a few times as it leaves. That way, US providers will still >> prefer US 6to4 relays (ie lower latency) but any who don't get a >> 192.88.99.0/24 route from the US will us your relay in Europe. >> Kinda gets you best of both worlds. > > Yeah, that's been one option as well, prepending 2-3 times to our > peers/transit in the US is probably a good middle way. > > Regarding some numbers on 6to4 and Teredo usage, I'd like to point > people to this thread on the ipv6ops IETF list: > > > > If someone has some nice code that'll take a list of IPv6 addresses > and break it down to geographical distribution of native/teredo/ > 6to4, I'd be more than happy to run it on my data. Teredo and 6to4 is easy - translate the addresses to IPv4 and geolocate with maxmind geoip or something. IPv6 is harder, you have to build a geolocation database, which I suppose you'd have to build from either origin AS location, or whatever location data the RIR has, for the prefix an address is in. I have been intending on building a map from Teredo and 6to4 using IPv6 addresses from my bittorrent population stuff, and have that as one output of a periodic study. I'm not sure how to do non-Teredo/6to4 addresses though, so if you've got some ideas there I'll whip something up, the Teredo/6to4 stuff is very simple. -- Nathan Ward -- Nathan Ward From mohacsi at niif.hu Mon Oct 13 06:24:41 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 13 Oct 2008 13:24:41 +0200 (CEST) Subject: IPv6 Wow In-Reply-To: <48F263B9.80007@sprunk.org> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> Message-ID: On Sun, 12 Oct 2008, Stephen Sprunk wrote: > Mikael Abrahamsson wrote: >> This brings up an interesting question, should we stop announcing our 6to4 >> relays outside of Europe? Is there consensus in the business how this >> should be done? I have heard opinions both ways. > > I can understand why some folks would say stop, but unfortunately Europe has > the closest public 6to4 relays to the US, and our own providers don't seem to > want to put any up. That means 6to4 will break for a great many folks who > _are_ trying to use IPv6 (like developers trying to get ahead of the curve > and make sure their apps don't break when the transition finally happens) but > whose providers haven't clued in yet. > > (My traceroutes to 192.88.99.1 have a next-to-last hop in Amsterdam, and I'm > on one of the largest ISPs in the US, which apparently hasn't figured out > 6to4, much less native IPv6.) The problem is that every tunneling mechanisms is selecting detination without the real knowldege about the underlying technology/distance etc. It was horrible during the 6bone - documented by Pekka Savola. We are not learning, from the past... 6to4 can generate same amount of problem.... Basically if they would obey the default address selection rules they would use 6to4 addresses only if there would be no global addressess and a resource would be acessible only from IPv6. This is the intended and recommended behaviour which is implemented by Windows (XP, Vista), *BSD systems and recent Linux systems. Unfortunately there is a broken idea of Apple to not implment RFC 3484 style Default Address Selection into the protocol stack, however it is implemented in its ancestors (*BSD + KAME) for more than 4 years now. Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From kokach.esthost at gmail.com Mon Oct 13 09:30:07 2008 From: kokach.esthost at gmail.com (Konstantin Poltev) Date: Mon, 13 Oct 2008 17:30:07 +0300 Subject: Hostexploit report/Intercage/Esthost Message-ID: Hello, My name is Konstantin Poltev and I'm with Esthost. I'd like to ask you to read through this email before hastily replying. As you are probably aware, Esthost has been accused of pretty much every mortal sin - from cybercrime to being KGB-sponsored part of Russian Business Network involved in information warfare against Georgia [R1]. However, that's just one side of the story. I'd like to present our side, in this email, and in person - I am right here at NANOG, ready to answer your questions. I've initially planned to make a short presentation during security BOF, but decided against it - I believe tempers are still too hot to hear our side of the story, also, my English is not quite as good to be able to stand up before 1000 people. However, I'll be around, in the hotel bar, should anyone want to ask me any questions in person - or should any law enforcement officer wish to arrest me :) Now, on to the story: First, few words on the "community police" that is accusing us of all the misdeeds. The accusations initially were made by (anonymous) John Reid from Spamhaus, then continued with anonymous rbnexploit blog, then by Jart Armin from the "hostexploit". All of those are (to my knowledge) are very much anonymous. I'd love to debate the report and their accusations, in public, but, regretfully, I don't see this happening anytime soon - while I'm very much willing to travel to US and subject myself to US jurisdiction, my accuser John Reid in Spamhaus is anonymous, and Spamhaus itself claims not to be subject to any US laws, where it clearly does business. It begs the question - how come the alleged "criminals" are so brazen, and alleged "community police" so anonymous? One possible conclusion is that there's no evidence of a crime, and "community police" is nothing short of a lynch mob, that needs no evidence, heeds no laws, and acts as a judge, jury and executioner. However, more on spamhaus later. Finally, the last point was the publication of an article in Washington Post by Brian Krebs. Brian, as it appears, has commissioned the hostexploit report, and it makes a wonderful media story - you have full-on thriller, with cybercriminals out of Estonia being aided by corporations small and large in US - it doesn't get any better than that. Unfortunately, said report is full of unsubstantiated allegations - in fact, not just unsubstantiated, but clearly known to be false to anyone who is actually in the industry (more on this later). Brian has attempted to ask us for our side of the story. However, the questions asked were "How many EstHost employees have graduated the KGB military public information school?", "How often does KGB/GRU/FSB ask Esthost to implement special measures against Western visitors", "Does Esthost provide GRU/SVR with information about Western visitors", "What percentage of Est's revenue is reinvested by FSB into Est's infrastructure". I'm dead serious - those were the questions - I can't make this up. You can draw your own conclusions on Brian's bias and the desire of a sensational story. I'd like to point out that Esthost doesn't hide behind anonymity - names of the owners of Esthost are well known, and we live in Estonia, which, despite what you think, is as much of a Western-world country with rule of law as, say, France or Germany - with criminal police, extradition treaties, Interpol membership, etc. What is the truth? We have no affiliation with "Russian Business Network" (if there ever was such a thing). We have no affiliation with Emil or Atrivo (other than being an ex-customer). We have no affiliation with HostFresh. We don't know what *they* do with their network, or their abuse complaints - we can only speak for ourselves. Onto the discussion of the "hostexploit report" itself: I am surprised that it appears that nobody actually have taken time to read the report - as inaccuracies are glaring enough to be immediately noticable. Report is hardly "unbiased" - it is a very beautifully typeset piece whose purpose is to smear our company (and our vendors' vendors' vendors, and our customers, and just about anyone else, maybe short of the guys who deliver pizza to our office). As I point out flaws in the report, I'd like to again emphasize, we are not atrivo. I believe Emil and Atrivo were unfairly smeared, and as much as Esthost, they deserve fairness, although I can't speak for the rest of Atrivo's customers, not affiliated with Esthost. Report itself is located at: http://hostexploit.com/downloads/Atrivo%20white%20paper%20082808ac.pdf First part of report is fluff - using spamhaus pages as evidence of wrongdoing. Let's start with obvious: ****** Page 16 - the page with the actual data: Google has 4 times more infections than Atrivo, and approximately same infection rate. Are they also cyber-criminals? Chinanet-backbone - has 48 times number of Atrivo's infections - they are here at NANOG, are they being asked what are *they* doing about the abuse? INETWORK-AS, twice the infections in quarter of Atrivo's space, 65% infection rate - what about them? Theplanet and Softlayer, *three* times the number of infections? EV1, twice the number of infections, and similar infection rate as Atrivo? The only pattern that I can draw is all the other companies are large businesses - who wouldn't take kindly to being smeared. It is far easier to scapegoat a small Estonian company and blame it on them. ****** Page 17: Claims that Broadwing is AS3356 (...!), and is "Atrivo - directly controlled /managed". Claims that Nlayer has control of 5,916,928 IP addresses. While I'm sure this is unintentional copy-paste thing, it shows lack of technical review of this report. ****** Page 13: Claims that "Atrivo requires internet connectivity from ThePlanet". Again, I'm not Emil, but I'd find it unlikely that he'd buy from his direct competitor. Claims that 1546 of privacyprotect sites are "ThePlanet sponsored" - I assume they meant hosted at ThePlanet. How does it demonstrate Planet's complicity, I don't know. ****** Page 6: Claims that "AS 4657 Singapore based providing collocation for Atrivo". That's a naked assertion, and fails the "oh really" test. (Again, not speaking for Emil, he *might* have colocation in China, but that's pretty damn unlikely!) ****** Page 7: "AS 36445 a newer Autonomous Server apparently used by Cernal". I assume the author meant "Autonomous System", just another questionable "technical" moment. Claims that "Estdomains is an anonymous registrar and "Esthost" is anonymous hosting" - I don't really know where to start. We don't provide anonymous hosting, any more than Yahoo! does. ****** Page 26: "It should be further noted some of the adult sites hosted are either border line or are within known blacklists of pedo-pornographic web sites (Note: this topic is outside the remit of this study, however details have been passed to appropriate third parties)". This is a very serious accusation - and it seems to be thrown very lightly with disregard for possible consequences. If it is actual child pornography, knowingly hosted by Atrivo, it has very direct consequences for Emil. Across the entire report, Hostexploit has made allegations of Esthost being affiliated with DirectI, and of DirectI being a willing participant in our "crimes". Within a week, Hostexploit had to withdraw those claims - I can only presume due to pressure from DirectI and its lawyers. Regarding "cybercriminals" and calls for community to "take action" against those who allegedly "provide transit" to cybercriminals - I'd like to point note that neither we, nor any of our customers, have been convicted (or even accused) in any court of law of any misdeeds. Spamhaus made claims [1] that: "We assume that every law enforcement agency with a cyber-crimes division has a dossier bursting at the seams on Atrivo/Intercage and its tentacles such as Esthost, Estdomains, Cernel, Hostfresh". Well, I'm right here in LA - if there's actual evidence, I have no doubt that law enforcement will act. However, I think this is highly unlikely. I won't deny that we *did* have abuse issues - that is the problem when your customers are mostly located in Eastern Europe - there are quite a few bad apples. Payment systems used in Eastern Europe tend to favor anonymity - which, obviously is also favored by criminals. However, it's the exception and not a rule. We've stopped accepting all anonymous payment systems quite awhile ago, and have new arrangement with one of Russia's largest payment systems where, if we report abuse, they will lock the criminal's account and accounts linked to it. We've always reacted expediously against abuse - every email that we received we've reacted to. We've implemented a anti-fraud system that links billing accounts to hosting accounts to domains, and if one domain is involved in abuse, everything "linked" to it is investigated and suspended/terminated. This is hard for a small company to do - due to intense competition in the registrar arena, profit margins are very slim. I'd like to finish with this - cybercrime is our common enemy. We'd like to be a part of a solution - and we are playing our part, as much as a small organization can do. If anyone wishes to discuss any of the above, or give us suggestions on what more could we do to fight spam/etc, I'll be around later on in the hotel bar area, just look for my nametag. However, I won't be there at all the time, in case you want to talk, kindly drop me an email and we'll figure out a time to meet. Thanks for reading so far, I know it's a long email. I hope to see you later at the conference. Kind regards, Konstantin [R1] http://rbnexploit.blogspot.com/2008/08/rbn-georgia-cyberwarfare-continuation .html [1] http://www.spamhaus.org/news.lasso?article=636 From jloiacon at csc.com Mon Oct 13 10:10:17 2008 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 13 Oct 2008 11:10:17 -0400 Subject: Help needed - Cisco Netflow In-Reply-To: <084962C061414240A0CDB4BE328A9B2D097FCBC294@GVW1100EXC.americas.hpqcorp.net> Message-ID: "Lee, Steven (NSG Malaysia)" wrote on 10/10/2008 01:20:30 PM: > Does anyone aware of the sampled netflow accuracy? If you mean how well you can extrapolate "real" numbers from "samples" by multiplying by the inverse sample rate, my (initial and somewhat limited) testing showed a surprising correlation. A pretty good first approximation. Joe From simonw at zynet.net Mon Oct 13 11:06:18 2008 From: simonw at zynet.net (Simon Waters) Date: Mon, 13 Oct 2008 17:06:18 +0100 Subject: Hostexploit report/Intercage/Esthost In-Reply-To: References: Message-ID: <200810131706.19070.simonw@zynet.net> On Monday 13 October 2008 15:30:07 Konstantin Poltev wrote: > > and Spamhaus itself claims not to be > subject to any US laws, where it clearly does business. The Spamhaus website lists addresses in the UK and Switzerland. They appear to operate from the UK, and they claim to be subject to UK law. Searching for "spamhaus jurisdiction" answers this in the first paragraph of the first result, not that Google is always this accurate. Spamhaus might not be perfect, but they demonstrably provide the best public source of information on spam sources on the Internet. As such criticizing them makes you look suspect in the eyes of those who have very positive experiences of spamhaus's data, and who are use to seeing criticism of them come almost exclusively from shady characters. If they are wrong say so, and tell them, they've always been very responsive to communications in the past, but don't rant. From abhishekv.verma at gmail.com Mon Oct 13 11:43:47 2008 From: abhishekv.verma at gmail.com (Abhishek Verma) Date: Mon, 13 Oct 2008 22:13:47 +0530 Subject: Study on Minium Route Advertisement Interval .. Message-ID: Hi, I am studying the MRAI timer and its effects on BGP - how it affects the overall BGP convergence, route flap damping, persistent oscillations, etc. It is wrt this that i would like to know the default setting that most service providers use? Do they use the default value as provider by their vendor, or do they disable it, or do they explictly set it to a value lower than the default? Please feel free to unicast me your responses. I would summarize the results and send it out on the list, without the specifics of who uses what kind of timer values. Thanks in advance, Abhishek From tkapela at gmail.com Mon Oct 13 14:02:00 2008 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 13 Oct 2008 12:02:00 -0700 Subject: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video Message-ID: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> We've got a simple HDV (1440x1088 p29.976) camera setup aimed at the speaker podium area. It only has front stage video, no presenter slides. For a more "full presentation experience" check out the Quicktime/Winmedia streams at http://nanog.org/streaming.php The following streams will carry both NANOG and ARIN meetings for the week of October 13, 2008: ~27 megabit MPEG2 HD: 233.0.236.20:1234 (udp, mp2ts) ~3 megabit H.264/AVC HD: 233.0.59.44:1234 (udp, mp2ts) ~3 megabit H.264/AVC HD, unicast style: http://kona.doit.wisc.edu:8044 Use VLC to play these streams. When using http streams, tell vlc to buffer 5 or 6 seconds worth. Download VLC here: http://www.videolan.org/ Enjoy! -Tk From tkapela at gmail.com Mon Oct 13 14:05:27 2008 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 13 Oct 2008 12:05:27 -0700 Subject: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video In-Reply-To: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> References: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> Message-ID: <2e9d8ae50810131205u7b380f5asc7ece8340f3cedb1@mail.gmail.com> Oh, forgot one thing. Please don't bother playing the streams on-site. :) -Tk From mrz at velvet.org Mon Oct 13 14:52:39 2008 From: mrz at velvet.org (matthew zeier) Date: Mon, 13 Oct 2008 12:52:39 -0700 Subject: peeringdb admin contact? Message-ID: <48F3A707.7060707@velvet.org> Been trying to get someone from admin at peeringdb to get back to me but haven't had any luck. Anyone? From patrick at ianai.net Mon Oct 13 14:54:21 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 13 Oct 2008 15:54:21 -0400 Subject: peeringdb admin contact? In-Reply-To: <48F3A707.7060707@velvet.org> References: <48F3A707.7060707@velvet.org> Message-ID: On Oct 13, 2008, at 3:52 PM, matthew zeier wrote: > Been trying to get someone from admin at peeringdb to get back to me > but haven't had any luck. Anyone? admin at peeringdb.com The e-mail address is on the front page of , you don't even have to log in to see it. That alias has not received e-mail from "mrz at velvet.org" in the last 90 days. -- TTFN, patrick From raymond at prolocation.net Mon Oct 13 14:56:28 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Mon, 13 Oct 2008 21:56:28 +0200 (CEST) Subject: peeringdb admin contact? In-Reply-To: <48F3A707.7060707@velvet.org> References: <48F3A707.7060707@velvet.org> Message-ID: Hi! > Been trying to get someone from admin at peeringdb to get back to me but haven't > had any luck. Anyone? If you have someone responding. we have created accounts there for a couple of our customers, but still are read only level. Not really handu if you ask people on peeringforum.eu to join and not handle their request accordingly. Bye, Raymond. From pstewart at nexicomgroup.net Mon Oct 13 15:17:11 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 13 Oct 2008 16:17:11 -0400 Subject: peeringdb admin contact? In-Reply-To: <48F3A707.7060707@velvet.org> References: <48F3A707.7060707@velvet.org> Message-ID: <89D27DE3375BB6428DDCC2927489826A01A957FD@nexus.nexicomgroup.net> They always respond very quickly anytime I email them.... you sure there isn't any spam filters etc. playing nasty on you? ;) -----Original Message----- From: matthew zeier [mailto:mrz at velvet.org] Sent: October 13, 2008 3:53 PM To: NANOG Subject: peeringdb admin contact? Been trying to get someone from admin at peeringdb to get back to me but haven't had any luck. Anyone? ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From tkapela at gmail.com Tue Oct 14 10:25:44 2008 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 14 Oct 2008 08:25:44 -0700 Subject: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video In-Reply-To: <2e9d8ae50810131205u7b380f5asc7ece8340f3cedb1@mail.gmail.com> References: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> <2e9d8ae50810131205u7b380f5asc7ece8340f3cedb1@mail.gmail.com> Message-ID: <2e9d8ae50810140825i73cb1fabha7587ea3ee81b8ea@mail.gmail.com> HD Stream is now back online. It'll be online until 5PM PST (the tutorals are not broadcast). -Tk From scott at sonic.net Tue Oct 14 11:08:48 2008 From: scott at sonic.net (Scott Doty) Date: Tue, 14 Oct 2008 09:08:48 -0700 Subject: The DDOS problem & security BOF: Am i mistaken? Message-ID: <48F4C410.50605@sonic.net> First, the good news: so far, the NANOG conference has been very valuable and content-rich, covering a lot of issues that need to be discussed. For that, I am grateful. But now, the bad news(?): Maybe it's just me & my paranoia, but do I detect an inkling of "murk spam" going on with some presentations? Because there seems to be a fundamental misunderstanding, either on my part, or the part of certain vendors: I'm hear to discuss ideas & freely share them, and they are here to discuss (it would seem) their products. Sometimes both goals coincide, and that is fine...but... When a vendor at the security BOF starts showing documents that are "company confidential", and trying to whip up a climate of fear, that we should all deploy their product in front of our recursive name servers, i get this funny feeling that I am being "murk spammed". Perhaps that is my own perspective (& paranoia?), but I found the CERT gentleman's call to monitor icmp backscatter on our authoritative nameservers far more informative -- and open. But I was disappointed with two vendors and their presentations: the first had the tactic of saying "DNSSEC is the actual solution" when asked about why their product would be necessary...completely ignoring the fact that their proprietary "interim solution" was by no means the only way to prevent cache poisoning attacks. Indeed, I would daresay it isn't the best, either by a BCP perspective, or a cost analysis perspective. To put a finer point on this, i should say that i found myself discomforted by a presentation suggesting that I should put their proprietary appliances between my recursive name servers & the Net, and I am grateful that Mr. Vixie stood up and said that there are other ways of dealing with the problem. Then there was the gentleman with the DDOS detection/mitigation appliance, who flipped through several graphs, which were intended to show the number of each type of attack. It's unfortunate that there wasn't more time for questions, because I really wanted to ask why "http GET" and "spidering" attacks weren't listen on their graphs...more on that in a second. Fortunately, said vendor had a table at "beer and gear", so I was able to talk with one of their representatives -- and learned that they have just as much trouble with automatic detection of attacks designed to look like a "slashdotting"...which cleared up the mystery as to why it wasn't on the graphs. Because this is a real problem: anybody, with sufficient knowledge & preparation can vandalize _anybody's_ network. Showing me a graph that ping floods happen all the time doesn't impress me -- what would impress me is going over the actual methods, algorithms (and heuristics?) used in these attack mitigation appliances. Because, the "best" attack mitigation appliance vendor would seem to have 100% of their market, and thus, charge exhorbant prices for their product(s). When I brought this up with Mr. Vendor, his first reaction was to point out that the cost was less than a home-grown solution. When I raised the question of open source software to do the same thing, his reaction was to ask: "oh? who's going to write it?" And that right there would seem to be a bit of bravado, perhaps fueled by a misunderstanding of the role that FOSS has played on the Net. Fortunately -- and again, I am grateful for this -- the ISC was represented in the security BOF, presenting the SIE concept...as well as what applications _already exist_ to detect and mitigate various attacks. One demonstration that blew me away: detecting a botnet being set up for a phishing attack...and preventing the attack before it even started. So in conclusion, I'll say this: the last NANOG I attended was NANOG 9 -- and i remember that being a more challenging environment for vendors. Probably the biggest problem discussed back then was head-of-line blocking on a vendor's switches. _That_ is the kind of content that i have found valuable, both on this list, and at a conference. And so: If I weren't so knock-kneed in public venues, I would probably be doing what i would like to call on conference participants to do: if someone gives a presentation that includes their own proprietary black-box "solution", I think the best benefit for NANOG would be to point out alternatives. -Scott p.s. sorry for the long post. From bburke at merit.edu Tue Oct 14 12:23:20 2008 From: bburke at merit.edu (Betty Burke) Date: Tue, 14 Oct 2008 13:23:20 -0400 (EDT) Subject: [NANOG-announce] NANOG 2008 Voting In-Reply-To: <1012903075.2364161224004997810.JavaMail.root@crono> Message-ID: <1306229654.2364181224005000510.JavaMail.root@crono> Current status........... 102 votes cast as of Merit Network Inc. Merit/NANOG Project Manager _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From phil at mindfury.net Tue Oct 14 12:34:26 2008 From: phil at mindfury.net (Philip L.) Date: Tue, 14 Oct 2008 13:34:26 -0400 Subject: Eircom connectivity issue Message-ID: <48F4D822.8010704@mindfury.net> Hello. I've ran into a puzzling scenario and I thought I'd ask around to see if anyone else has an idea. I have a customer who operates a server on our network who informed me that a customer of his out of Ireland is having connectivity issues to it. The ISP in question is Eircom, and the block that seems unreachable is 86.40.0.0/13. Any trace to an IP in that block drops off the Earth at the edge of the Tier 1 provider that we connect with, such as AT&T and Sprint. I've also tried Level3, but the traffic goes over to AT&T in the end anyhow. I've checked Level3 and Sprint's looking glass and performs a traceroute from there, and I get the same result, so it doesn't appear to be an issue with our network. I'm at a loss and my customer told me that his customer has already contacted Eircom and they are at a loss to explain the disconnect as well. Does anyone have some insight into this? -- Philip L. From todd at renesys.com Tue Oct 14 13:03:03 2008 From: todd at renesys.com (Todd Underwood) Date: Tue, 14 Oct 2008 18:03:03 +0000 Subject: vote now, please Message-ID: <20081014180303.GQ20914@renesys.com> apologies if this is off-topic, but the elections are really important and many people on the list are not at the conference so i thought a short reminder might be useful: nanog is holding elections for steering committee members right now and charter ammendments right now. more information: http://nanog.org/governance/elections/2008elections/ go vote: https://nanog.merit.edu/election/ if you can't remember your password: https://nanog.merit.edu/registration/password.epl this election matters. the steering committee selects the program committe and the mailing list committee. they guide the selection of conference locations. they should be people with good judgement who you respect. elections close at 1300PDT/1600EDT/2000UTC which is in approximately two hours. so vote right now! canada is voting today too, so if you're canadian, vote here and then vote there. thanks :-) t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From scott at sonic.net Tue Oct 14 14:49:27 2008 From: scott at sonic.net (Scott Doty) Date: Tue, 14 Oct 2008 12:49:27 -0700 Subject: spurring transition to ipv6 -- make it faster Message-ID: <48F4F7C7.1020808@sonic.net> We've had one presentation on the "unfairness" of p2p traffic, which (the presenter says) will eventually swamp us. Then just now, we had the presentation & subsequent discussion re: ipv6 adoption. Just wondering: what if we gave ipv6 traffic "mucho priority" over ipv4 traffic, then tell our user communities that ipv6 provides a better quality network experience, including (hopefully) faster page loads, & lower video game pings? With such policies in place, folks wouldn't want to stay with the "old, slow" v4 traffic...and could be a significant selling point. After all, if most p2p traffic is v4, prioritizing ipv6 (as a general concept) should improve the user experience. Anyway, was just an idea, please pardon me if this has been discussed before, or sounds nutty... Thanks, -Scott From niall at moybella.net Tue Oct 14 14:56:03 2008 From: niall at moybella.net (Niall Donegan) Date: Tue, 14 Oct 2008 20:56:03 +0100 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <48F4F7C7.1020808@sonic.net> References: <48F4F7C7.1020808@sonic.net> Message-ID: <48F4F953.3010906@moybella.net> Scott Doty wrote: > After all, if most p2p traffic is v4, prioritizing ipv6 (as a general > concept) should improve the user experience. How long do you think it will take for the P2P software authors to transition over to IPv6? I'll bet that P2P users will be a lot more likely to use IPv6 over Aunt May checking her email once a day. Niall. -- The virus contained in this message was not detected. From Skywing at valhallalegends.com Tue Oct 14 15:01:27 2008 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 14 Oct 2008 15:01:27 -0500 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <48F4F953.3010906@moybella.net> References: <48F4F7C7.1020808@sonic.net> <48F4F953.3010906@moybella.net> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC620@caralain.haven.nynaeve.net> Actually, I seem to recall some postings to the list stating that many of the popular bittorrent clients already do IPv6 if available. So that would seem to be a good recipe for allowing P2P users to prioritize ahead of regular traffic. - S -----Original Message----- From: Niall Donegan [mailto:niall at moybella.net] Sent: Tuesday, October 14, 2008 3:56 PM To: Scott Doty Cc: nanog at merit.edu Subject: Re: spurring transition to ipv6 -- make it faster Scott Doty wrote: > After all, if most p2p traffic is v4, prioritizing ipv6 (as a general > concept) should improve the user experience. How long do you think it will take for the P2P software authors to transition over to IPv6? I'll bet that P2P users will be a lot more likely to use IPv6 over Aunt May checking her email once a day. Niall. -- The virus contained in this message was not detected. From brent.paddon at overthewire.com.au Tue Oct 14 15:07:10 2008 From: brent.paddon at overthewire.com.au (Brent Paddon) Date: Wed, 15 Oct 2008 06:07:10 +1000 Subject: Cisco interface - GB of transfer software In-Reply-To: <48E23CF4.9010709@mountaincable.on.ca> References: <48E23CF4.9010709@mountaincable.on.ca> Message-ID: <48F4FBEE.9030405@overthewire.com.au> http://www.hughes.com.au/products/traffacct/ Built specifically for byte accounting for billing purposes and can poll a number of devices. Built for billing and free (though not maintained it 'just works'). Brent Brent Paddon Director | Over the Wire Pty Ltd brent.paddon at overthewire.com.au | www.overthewire.com.au Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0400 2400 54 | Direct: 07 3503 4807 Dale Turner wrote: > Good morning all, > > I hope my post isn't too off topic but I was wondering if anyone is > using some open source or purchased software that would give me the > monthly Data transfer from cisco switch ports so I can monitor/bill > against some hosting customers. I know we can create our own but > looking to see if there was something that anyone is using and > recommends. > > Thank you very much > > Dale Turner > > > > From newton at internode.com.au Tue Oct 14 15:07:18 2008 From: newton at internode.com.au (Mark Newton) Date: Wed, 15 Oct 2008 06:37:18 +1030 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <48F4F7C7.1020808@sonic.net> References: <48F4F7C7.1020808@sonic.net> Message-ID: <4BFDD585-D70A-4C93-9C68-75D5D0EECB90@internode.com.au> On 15/10/2008, at 6:19 AM, Scott Doty wrote: > > Just wondering: what if we gave ipv6 traffic "mucho priority" over > ipv4 > traffic, then tell our user communities that ipv6 provides a better > quality network experience, including (hopefully) faster page loads, & > lower video game pings? I think by the time we've put carrier NATs everywhere the users will notice that all by themselves, and we won't need to tell them anything. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From nanog at daork.net Tue Oct 14 17:33:15 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 15 Oct 2008 11:33:15 +1300 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <48F4F953.3010906@moybella.net> References: <48F4F7C7.1020808@sonic.net> <48F4F953.3010906@moybella.net> Message-ID: On 15/10/2008, at 8:56 AM, Niall Donegan wrote: > Scott Doty wrote: >> After all, if most p2p traffic is v4, prioritizing ipv6 (as a general >> concept) should improve the user experience. > > How long do you think it will take for the P2P software authors to > transition over to IPv6? I'll bet that P2P users will be a lot more > likely to use IPv6 over Aunt May checking her email once a day. Sorry, it happened already. Presentation I gave at APNIC26 on the subject: http://www.apnic.net/meetings/26/program/ipv6/ward-ipv6-stats.pdf A Teredo/6to4 relay in Finland operated by CSC/FUNET: http://www.braintrust.co.nz/temp/csc-funet-teredo-6to4.png Note the massive increase of traffic. It ramps up the *day* uTorrent 1.8 came out. I have long said: 1) IPv4 will continue to exist for web/email/etc. servers. 2) When ISPs run out of IPv4 space and start NATing their customers, IPv6 will become the new way to do applications that require end-to- end. This is *why* Teredo exists - so Microsoft applications that require end-to-end can get it, without having to implement a NAT traversal stack in each and every app. Teredo is now available on most OSes. 3) (2) is clearly happening already, with bit torrent applications. It's an easy way to do NAT traversal for free. 4) When IPv6 is widely enough supported, then maybe someone will run a web/email/etc. server on IPv6 only. There is a lot of work to attempt to keep IPv4 end-to-end alive when SP-NAT happens. Personally, I think attempting to prolong IPv4 end-to- end is a waste of time when IPv6 does it already, and all these proposals require applications to be updated to support dynamic ports and things. If you're updating the application, just make it support IPv6. For most applications this is trivial. -- Nathan Ward From tomb at byrneit.net Tue Oct 14 21:45:27 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 14 Oct 2008 19:45:27 -0700 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: References: <48F4F7C7.1020808@sonic.net> <48F4F953.3010906@moybella.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F724@pascal.zaphodb.org> If P2P became IPV6, and therefore universally endpoint addressable, and therefore seeded by every download, as opposed to solely seeded by those who have enough clue to configure the inbound ports through their IPV4 NAT, then the bandwidth problem should solve itself, at least for the widely popular downloads. Assuming every downloader could also seed, for the popular stuff, the traffic would be primarily local, which is not where the bottleneck is in most cases. Of course, this is assuming that the reason the SPs are opposed to P2P isn't related to their desire to derive revenue from the content that is non-ratable if delivered over P2P, but that is a different topic. >-----Original Message----- >From: Nathan Ward [mailto:nanog at daork.net] >Sent: Tuesday, October 14, 2008 3:33 PM >To: Niall Donegan >Cc: nanog at merit.edu >Subject: Re: spurring transition to ipv6 -- make it faster > >On 15/10/2008, at 8:56 AM, Niall Donegan wrote: >> Scott Doty wrote: >>> After all, if most p2p traffic is v4, prioritizing ipv6 (as a general >>> concept) should improve the user experience. >> >> How long do you think it will take for the P2P software authors to >> transition over to IPv6? I'll bet that P2P users will be a lot more >> likely to use IPv6 over Aunt May checking her email once a day. > > >Sorry, it happened already. > >Presentation I gave at APNIC26 on the subject: >http://www.apnic.net/meetings/26/program/ipv6/ward-ipv6-stats.pdf > > >A Teredo/6to4 relay in Finland operated by CSC/FUNET: >http://www.braintrust.co.nz/temp/csc-funet-teredo-6to4.png > >Note the massive increase of traffic. It ramps up the *day* uTorrent >1.8 came out. > > >I have long said: >1) IPv4 will continue to exist for web/email/etc. servers. >2) When ISPs run out of IPv4 space and start NATing their customers, >IPv6 will become the new way to do applications that require end-to- >end. This is *why* Teredo exists - so Microsoft applications that >require end-to-end can get it, without having to implement a NAT >traversal stack in each and every app. Teredo is now available on most >OSes. >3) (2) is clearly happening already, with bit torrent applications. >It's an easy way to do NAT traversal for free. >4) When IPv6 is widely enough supported, then maybe someone will run a >web/email/etc. server on IPv6 only. > > >There is a lot of work to attempt to keep IPv4 end-to-end alive when >SP-NAT happens. Personally, I think attempting to prolong IPv4 end-to- >end is a waste of time when IPv6 does it already, and all these >proposals require applications to be updated to support dynamic ports >and things. If you're updating the application, just make it support >IPv6. For most applications this is trivial. > >-- >Nathan Ward > > > > From jeffrey.lyon at blacklotus.net Wed Oct 15 04:21:06 2008 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 15 Oct 2008 12:21:06 +0300 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F4C410.50605@sonic.net> References: <48F4C410.50605@sonic.net> Message-ID: <16720fe00810150221h12527003pa9a19ed4a9009035@mail.gmail.com> Let me avoid being long winded and just put on my Captain Obvious cape. Avoid magic DDoS appliances, particularly those that require some type of relationship or deposit to be made in advance no matter how "risk free." There is a reason why these vendor presentations aren't meeting your expectations. You're also dead on concerning one's ability to develop and deploy OSS. Human capital is generally your best resource. My two cents, Jeff On Tue, Oct 14, 2008 at 7:08 PM, Scott Doty wrote: > First, the good news: so far, the NANOG conference has been very valuable > and > content-rich, covering a lot of issues that need to be discussed. For that, > I am grateful. > > But now, the bad news(?): Maybe it's just me & my paranoia, but do I detect > an inkling of "murk spam" going on with some presentations? > > Because there seems to be a fundamental misunderstanding, either on my part, > or the part of certain vendors: I'm hear to discuss ideas & freely share > them, and they are here to discuss (it would seem) their products. Sometimes > both goals coincide, and that is fine...but... > > When a vendor at the security BOF starts showing documents that are "company > confidential", and trying to whip up a climate of fear, that we should all > deploy their product in front of our recursive name servers, i get this > funny feeling that I am being "murk spammed". > > Perhaps that is my own perspective (& paranoia?), but I found the CERT > gentleman's call to monitor icmp backscatter on our authoritative > nameservers far more informative -- and open. > > But I was disappointed with two vendors and their presentations: the first > had the tactic of saying "DNSSEC is the actual solution" when asked about > why their product would be necessary...completely ignoring the fact that > their proprietary "interim solution" was by no means the only way to prevent > cache poisoning attacks. Indeed, I would daresay it isn't the best, either > by a BCP perspective, or a cost analysis perspective. > > To put a finer point on this, i should say that i found myself discomforted > by a presentation suggesting that I should put their proprietary appliances > between my recursive name servers & the Net, and I am grateful that Mr. > Vixie stood up and said that there are other ways of dealing with the > problem. > > Then there was the gentleman with the DDOS detection/mitigation appliance, > who flipped through several graphs, which were intended to show the number > of each type of attack. It's unfortunate that there wasn't more time for > questions, because I really wanted to ask why "http GET" and "spidering" > attacks weren't listen on their graphs...more on that in a second. > > Fortunately, said vendor had a table at "beer and gear", so I was able to > talk with one of their representatives -- and learned that they have just as > much trouble with automatic detection of attacks designed to look like a > "slashdotting"...which cleared up the mystery as to why it wasn't on the > graphs. > > Because this is a real problem: anybody, with sufficient knowledge & > preparation can vandalize _anybody's_ network. Showing me a graph that ping > floods happen all the time doesn't impress me -- what would impress me is > going over the actual methods, algorithms (and heuristics?) used in these > attack mitigation appliances. > > Because, the "best" attack mitigation appliance vendor would seem to have > 100% of their market, and thus, charge exhorbant prices for their > product(s). When I brought this up with Mr. Vendor, his first reaction was > to point out that the cost was less than a home-grown solution. When I > raised the question of open source software to do the same thing, his > reaction was to ask: "oh? who's going to write it?" > > And that right there would seem to be a bit of bravado, perhaps fueled by a > misunderstanding of the role that FOSS has played on the Net. > > Fortunately -- and again, I am grateful for this -- the ISC was represented > in the security BOF, presenting the SIE concept...as well as what > applications _already exist_ to detect and mitigate various attacks. One > demonstration that blew me away: detecting a botnet being set up for a > phishing attack...and preventing the attack before it even started. > > So in conclusion, I'll say this: the last NANOG I attended was NANOG 9 -- > and i remember that being a more challenging environment for vendors. > Probably the biggest problem discussed back then was head-of-line blocking > on a vendor's switches. _That_ is the kind of content that i have found > valuable, both on this list, and at a conference. > > And so: If I weren't so knock-kneed in public venues, > I would probably be doing what i would like to call on conference > participants to do: if someone gives a presentation that includes their own > proprietary black-box "solution", I think the best benefit for NANOG would > be to point out alternatives. > > -Scott > p.s. sorry for the long post. > > > -- Jeffrey Lyon, President Level III Information Systems Technician jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Talk for 4h 45m from the U.S. to Latin America for $10.00: http://www.defensecalling.com From tkapela at gmail.com Wed Oct 15 11:03:02 2008 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 15 Oct 2008 09:03:02 -0700 Subject: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video In-Reply-To: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> References: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> Message-ID: <2e9d8ae50810150903t160d321m451174a91a4731ce@mail.gmail.com> Streams are back up for the last day of NANOG, later covering ARIN for the remainder of the week. Since it's mostly talking heads, I've lowered the bitrate of the h264 versions, and removed cpu-consuming options (i.e. no CABAC) ~27 megabit MPEG2 HD: udp://233.0.236.20:1234 (udp, mp2ts) ~2 megabit H.264/AVC HD: udp://233.0.59.44:1234 (udp, mp2ts) ~2 megabit H.264/AVC HD, unicast style: http://kona.doit.wisc.edu:8044 Use VLC to play these streams. When using http streams, tell vlc to buffer 5 or 6 seconds worth. Download VLC here: http://www.videolan.org/ -Tk From tkapela at gmail.com Wed Oct 15 11:16:02 2008 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 15 Oct 2008 09:16:02 -0700 Subject: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video In-Reply-To: <2e9d8ae50810150903t160d321m451174a91a4731ce@mail.gmail.com> References: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> <2e9d8ae50810150903t160d321m451174a91a4731ce@mail.gmail.com> Message-ID: <2e9d8ae50810150916h6dbe8g4201244f04d2f574@mail.gmail.com> One last message... Audio-only streams are up, and will be fur the durration. Mp3 and AAC+ are available. Find them here: http://classic.shoutcast.com/directory/index.phtml?s=ARIN+XXII -Tk From ka at pacific.net Wed Oct 15 11:25:52 2008 From: ka at pacific.net (Ken A) Date: Wed, 15 Oct 2008 11:25:52 -0500 Subject: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video In-Reply-To: <2e9d8ae50810150903t160d321m451174a91a4731ce@mail.gmail.com> References: <2e9d8ae50810131202r72da8aence95fa03007d4429@mail.gmail.com> <2e9d8ae50810150903t160d321m451174a91a4731ce@mail.gmail.com> Message-ID: <48F61990.4060707@pacific.net> Anton Kapela wrote: > Streams are back up for the last day of NANOG, later covering ARIN for > the remainder of the week. > > Since it's mostly talking heads, I've lowered the bitrate of the h264 > versions, and removed cpu-consuming options (i.e. no CABAC) > > ~27 megabit MPEG2 HD: udp://233.0.236.20:1234 (udp, mp2ts) > > ~2 megabit H.264/AVC HD: udp://233.0.59.44:1234 (udp, mp2ts) > > ~2 megabit H.264/AVC HD, unicast style: http://kona.doit.wisc.edu:8044 > > Use VLC to play these streams. When using http streams, tell vlc to > buffer 5 or 6 seconds worth. Download VLC here: http://www.videolan.org/ > > -Tk > Why does the quicktime stream 256k show the slides and the 2mbit stream doesn't? -- Ken Anderson Pacific.Net From karnaugh at karnaugh.za.net Wed Oct 15 11:29:32 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 15 Oct 2008 18:29:32 +0200 Subject: Network topology Message-ID: <48F61A6C.5050201@karnaugh.za.net> Hi all I'm considering trying to come up with some means to automatically detect a networks topology and draw pretty pictures. This is somewhat boring though if a network isn't well arranged with VLANs and q-tag trunk routers and so on (It will just look like a big cloud of junk connected off an assumed switch). Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP? From woody at pch.net Wed Oct 15 11:29:24 2008 From: woody at pch.net (Bill Woodcock) Date: Wed, 15 Oct 2008 09:29:24 -0700 (PDT) Subject: Network topology In-Reply-To: <48F61A6C.5050201@karnaugh.za.net> References: <48F61A6C.5050201@karnaugh.za.net> Message-ID: On Wed, 15 Oct 2008, Colin Alston wrote: > I'm considering trying to come up with some means to automatically detect > a networks topology and draw pretty pictures. InterMapper. http://dartware.com/network_monitoring_products/intermapper/index.html -Bill From bfeeny at mac.com Wed Oct 15 11:36:36 2008 From: bfeeny at mac.com (Brian Feeny) Date: Wed, 15 Oct 2008 12:36:36 -0400 Subject: Network topology In-Reply-To: References: <48F61A6C.5050201@karnaugh.za.net> Message-ID: And another one, that I believe is a commercial product: http://www.solarwinds.com/products/lansurveyor/ On Oct 15, 2008, at 12:29 PM, Bill Woodcock wrote: > On Wed, 15 Oct 2008, Colin Alston wrote: >> I'm considering trying to come up with some means to automatically >> detect >> a networks topology and draw pretty pictures. > > InterMapper. > > http://dartware.com/network_monitoring_products/intermapper/index.html > > -Bill > > From karnaugh at karnaugh.za.net Wed Oct 15 11:52:19 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 15 Oct 2008 18:52:19 +0200 Subject: Network topology In-Reply-To: References: <48F61A6C.5050201@karnaugh.za.net> Message-ID: <48F61FC3.2080602@karnaugh.za.net> On 2008/10/15 06:29 PM Bill Woodcock wrote: > InterMapper. > > http://dartware.com/network_monitoring_products/intermapper/index.html > > -Bill > Whoa, quite a serious looking piece of software. Will check it out. Was kinda hoping to write my own software though, but perhaps I can craftily learn something from it :) From danny at tcb.net Wed Oct 15 13:09:00 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 15 Oct 2008 12:09:00 -0600 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F4C410.50605@sonic.net> References: <48F4C410.50605@sonic.net> Message-ID: Scott, Given that I both co-moderated the ISP security BOF AND gave a ~9 minute presentation covering *empirical* data and stats of observed attack vectors across 100 ISP networks over 640 days, and shared a slide or two with stats from an infrastructure security survey we've been doing and sharing with the operations community for 4 years now, I take a bit of offense to your comments below. I make a concerted effort to decouple vendor pitches from both the data sets presented and believe I did so effectively. There was open microphone time and you were welcome to share your thoughts. There has been context set with both the data I presented and the survey in previous meetings and NANOGs, it's unfortunate you're unfamiliar with this. Rodney's presentation was one vendor's approach to a very real problem, one that has consumed a significant amount of ISP operations resources over the past 6 months, and you were certainly welcome to comment on that as well - as you note Vixie and others did - and that's a large part of the point of the BOF, IMO. You're welcome to contribute positively in some manner to the next BOF - proactively - or co-moderate if you'd like, but to address the question in the subject line directly - "Am I mistaken", I believe yes. Also, please don't confuse discussion of what happened at beer n gear with what happened at the BOF. -danny From karnaugh at karnaugh.za.net Wed Oct 15 13:35:33 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 15 Oct 2008 20:35:33 +0200 Subject: Network topology [Solved] In-Reply-To: <48F61A6C.5050201@karnaugh.za.net> References: <48F61A6C.5050201@karnaugh.za.net> Message-ID: <48F637F5.9020303@karnaugh.za.net> On 2008/10/15 06:29 PM Colin Alston wrote: > Is there any kind of cunning trick to detect standard layer2 switches > along a path without stuff like STP? Apparently there isn't. Lots of people mentioned other tools, the problem there is they have one thing in common which is polling SNMP. I think it scales badly in general. I was hoping to find a more intelligent way of, I guess, doing an ARP/MAC based traceroute by checking LLC 802.2 headers or something. Yes, it might have been easier if I hoped for it to rain money :) Maybe there should be something (I mean like, someone should come up with a standard :P) to trace switches in a path... Problem is I think even then the simple devices won't bother to support it. From LarrySheldon at cox.net Wed Oct 15 13:49:00 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 15 Oct 2008 13:49:00 -0500 Subject: Network topology [Solved] In-Reply-To: <48F637F5.9020303@karnaugh.za.net> References: <48F61A6C.5050201@karnaugh.za.net> <48F637F5.9020303@karnaugh.za.net> Message-ID: <48F63B1C.7070105@cox.net> Colin Alston wrote: > Maybe there should be something (I mean like, someone should come up > with a standard :P) to trace switches in a path... Problem is I think > even then the simple devices won't bother to support it. I have been away from it for ma while and in truth don't know the answer--but-- To the best of my knowledge, "Layer two Switches" in fact operate as multi-port bridges. If that is true, then they ought to be transmitting BDUs which should be detectable and used for mapping. If the switches are all from the same manufacturer, there is a chance that the manufacture has a proprietary mapping tool. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From dholmes at mwdh2o.com Wed Oct 15 13:53:06 2008 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 15 Oct 2008 11:53:06 -0700 Subject: Network topology [Solved] In-Reply-To: <48F63B1C.7070105@cox.net> References: <48F61A6C.5050201@karnaugh.za.net><48F637F5.9020303@karnaugh.za.net> <48F63B1C.7070105@cox.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E07B9D292@usmsxt104.mwd.h2o> If the switches are Cisco, then Cisco Works has a L2 STP forwarding path graphical display which can be used in cases where the L3 path is a logical abstraction overlaid on the underlying L2 topology. -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Wednesday, October 15, 2008 11:49 AM Cc: NANOG list Subject: Re: Network topology [Solved] Colin Alston wrote: > Maybe there should be something (I mean like, someone should come up > with a standard :P) to trace switches in a path... Problem is I think > even then the simple devices won't bother to support it. I have been away from it for ma while and in truth don't know the answer--but-- To the best of my knowledge, "Layer two Switches" in fact operate as multi-port bridges. If that is true, then they ought to be transmitting BDUs which should be detectable and used for mapping. If the switches are all from the same manufacturer, there is a chance that the manufacture has a proprietary mapping tool. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From karnaugh at karnaugh.za.net Wed Oct 15 14:04:30 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 15 Oct 2008 21:04:30 +0200 Subject: Network topology [Solved] In-Reply-To: <48F63B1C.7070105@cox.net> References: <48F61A6C.5050201@karnaugh.za.net> <48F637F5.9020303@karnaugh.za.net> <48F63B1C.7070105@cox.net> Message-ID: <48F63EBE.5050908@karnaugh.za.net> On 2008/10/15 08:49 PM Larry Sheldon wrote: > Colin Alston wrote: > >> Maybe there should be something (I mean like, someone should come up >> with a standard :P) to trace switches in a path... Problem is I think >> even then the simple devices won't bother to support it. > > I have been away from it for ma while and in truth don't know the > answer--but-- > > To the best of my knowledge, "Layer two Switches" in fact operate as > multi-port bridges. > > If that is true, then they ought to be transmitting BDUs which should be > detectable and used for mapping. Ahh, you are correct sir (as well as the off list responses :)) Found this rather quickly http://www.geocities.com/milicsasa/Tools/l2trace/index.html as well as http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/l2trace.pdf Not sure why I didn't Google "layer 2 traceroute" before... Oh well, live and learn, and work shorter hours. Thanks :) From warren at kumari.net Wed Oct 15 15:05:06 2008 From: warren at kumari.net (Warren Kumari) Date: Wed, 15 Oct 2008 16:05:06 -0400 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F4C410.50605@sonic.net> References: <48F4C410.50605@sonic.net> Message-ID: <23C6BF4F-9B74-4798-9BA1-88701398B8A8@kumari.net> On Oct 14, 2008, at 12:08 PM, Scott Doty wrote: > First, the good news: so far, the NANOG conference has been very > valuable and > content-rich, covering a lot of issues that need to be discussed. > For that, I am grateful. > > But now, the bad news(?): Maybe it's just me & my paranoia, but do > I detect > an inkling of "murk spam" going on with some presentations? I fully agree with you -- some talks are thinly (or not so thinly) veiled attempts to convince you to buy a vendor's shiny, new solution. There are a large number of reasons for this, and the Program Committee works hard (and I think is doing a great job) to limit the amount of sales pitch but A: there are a limited number of talks and B: many vendors are unable to resist trying to spin their product. I suggest that if you have a topic that you would like to present (and will keep it sales free) you resent it to the PC. I *do* however disagree with you that this happened in the talks to which you are referring... > > > Because there seems to be a fundamental misunderstanding, either on > my part, > or the part of certain vendors: I'm hear to discuss ideas & freely > share > them, and they are here to discuss (it would seem) their products. Once again, great -- please submit a talk to the PC and they will review it. The PC is always looking for good talks... > Sometimes > both goals coincide, and that is fine...but... > > When a vendor at the security BOF starts showing documents that are > "company > confidential", and trying to whip up a climate of fear, that we > should all > deploy their product in front of our recursive name servers, i get > this > funny feeling that I am being "murk spammed". Hmmm... The vendor that you are referring to provides authoritative DNS for many domains (and, at least some of them I view as "important", meaning that I would prefer a correct response!). Yes, I am sure that he would be happy to have you as a customer and, yes, this is feature that differentiates his company, but I did not get the impression AT ALL that he was trying to sell his service, but rather provide better service to his existing customers, even going so far as to provide free devices to people who run large recursive resolvers. This helps both his existing customers (who, yes, will be more likely to continue using him), but, more importantly helps me as an end user feel a little comfortable that the page that I am getting is the correct page... > > > Perhaps that is my own perspective (& paranoia?), but I found the CERT > gentleman's call to monitor icmp backscatter on our authoritative > nameservers far more informative -- and open. > > But I was disappointed with two vendors and their presentations: the > first > had the tactic of saying "DNSSEC is the actual solution" when asked > about > why their product would be necessary...completely ignoring the fact > that > their proprietary "interim solution" was by no means the only way to > prevent > cache poisoning attacks. I may be mistaken, but I didn't get the impression that he believed that his solution was the only one -- he repeatedly pointed out that DNSSEC is the correct solution and this his solution does not solve all of the problems that DNSSEC would -- however, DNSSEC is FAR from being fully deployed. > Indeed, I would daresay it isn't the best, either > by a BCP perspective, or a cost analysis perspective. > > > To put a finer point on this, i should say that i found myself > discomforted > by a presentation suggesting that I should put their proprietary > appliances > between my recursive name servers & the Net, and I am grateful that > Mr. > Vixie stood up and said that there are other ways of dealing with the > problem. > Hmmm.. We must have VERY different recollections -- I don't remember him mentioning how much this would cost, other than that he would be give away some to the biggest wins first. Without knowing how much these widgets will be, it is not possibly to do a cost comparison, but don't discount just how expensive engineering time is, and just how hard it is to find competent DNS folks able to deploy something else. I have chatted with many people about the state of their DNS infrastructure -- many people don't care, many people DO care but just don't have the cycles to properly maintain it, many have weird internal politics around them, and many just don't have the knowledge. Some of these are hard to solve, the lack of knowledge is probably the easiest, so I would welcome any how0-to, etc guides that would feel like writing.... > Then there was the gentleman with the DDOS detection/mitigation > appliance, > who flipped through several graphs, which were intended to show the > number > of each type of attack. It's unfortunate that there wasn't more > time for > questions, because I really wanted to ask why "http GET" and > "spidering" > attacks weren't listen on their graphs...more on that in a second. > Hmmm, probably some of this is my fault, I am largely responsible for the agenda -- this was my first tie doing this an I suspect that I tried to fit too many talks into too little time. If there had been more time Danny might have covered their collection methodology (but, I need to warn you that that would probably have involved some information that *could* be construed as "This is what differentiates us" and would have been construed as sales, but whatever...). The information that was presented is part of a very well know report that gets published (but in a more executive format) and he (apparently incorrectly) assumed that the BOF audience would already be aware of how the information is collected and some of the benefits and short comings of their collection methodology. Once agin, probably my fault that he didn't have enough time to go though how the data is collected, but if he had, most of the audience would have bored out of their minds and they already know this and the rest would have felt like they were being sold to... > Fortunately, said vendor had a table at "beer and gear", so I was > able to > talk with one of their representatives -- and learned that they have > just as > much trouble with automatic detection of attacks designed to look > like a > "slashdotting"...which cleared up the mystery as to why it wasn't on > the > graphs. > > Because this is a real problem: anybody, with sufficient knowledge & > preparation can vandalize _anybody's_ network. Showing me a graph > that ping > floods happen all the time doesn't impress me -- what would impress > me is > going over the actual methods, algorithms (and heuristics?) used in > these > attack mitigation appliances. Ok, now I am confused --- you would like the vendor to stand up (in a NANOG presentation) and say: "Here is our widget, look how shiny it is.. Our device is better than $COMPETITOR because we do X, Y, Z, etc. We use the following heuristics and other vendors don't "? To me this sound WAY more like a sales ploy (and, some of the other talks were much closer to this....). > > > Because, the "best" attack mitigation appliance vendor would seem to > have > 100% of their market, and thus, charge exhorbant prices for their > product(s). When I brought this up with Mr. Vendor, his first > reaction was > to point out that the cost was less than a home-grown solution. Yup... Said vendor does have a large market share -- by explaining how they collect the information they would have had to explain just how much of the Internet they instrument, which to me would have felt very salesey... > When I > raised the question of open source software to do the same thing, his > reaction was to ask: "oh? who's going to write it?" > And that right there would seem to be a bit of bravado, perhaps > fueled by a > misunderstanding of the role that FOSS has played on the Net. Yes, you can build your own attack mitigation solution (either based on OSS and / or from scratch), but there are limitations. Just saying "use OSS" doesn't make a fully formed solution spring into being, there are *large* investments needed in terms of time, effort, resource, scaling, training, lack of support, etc. While you *can* build a router using just OSS tools[0] there is a reason that most don't... > > > Fortunately -- and again, I am grateful for this -- the ISC was > represented > in the security BOF, presenting the SIE concept...as well as what > applications _already exist_ to detect and mitigate various > attacks. One > demonstration that blew me away: detecting a botnet being set up > for a > phishing attack...and preventing the attack before it even started. Great, I'm glad you liked that... > > > So in conclusion, I'll say this: the last NANOG I attended was > NANOG 9 -- > and i remember that being a more challenging environment for vendors. > Probably the biggest problem discussed back then was head-of-line > blocking > on a vendor's switches. _That_ is the kind of content that i have > found > valuable, both on this list, and at a conference. > Hmmm, I remember some of these -- and I remember the "Our box does this way better than $OTHER_VENDOR" spin that was always put on this... > And so: If I weren't so knock-kneed in public venues, > I would probably be doing what i would like to call on conference > participants to do: if someone gives a presentation that includes > their own > proprietary black-box "solution", I think the best benefit for NANOG > would > be to point out alternatives. > Next time, please try and overcome your fear (although, I will happily point out that I haven't -- even saying "sorry, only time for 1 more question" gives me sweaty palms, makes me feel queasy, etc. What helps is to remember just how badly most of the other people here speak and that no-one cares) -- other (sane and realistic) solutions are always welcomed... > -Scott > p.s. sorry for the long post. W [0]: OMG, have I just kicked off the "Liinux / BSD as your core router" discussion again?! From rjoffe at centergate.com Wed Oct 15 15:39:58 2008 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 15 Oct 2008 13:39:58 -0700 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F4C410.50605@sonic.net> References: <48F4C410.50605@sonic.net> Message-ID: <01A53E5A-F4D1-45A8-B36F-2FA82E352B0C@centergate.com> Scott, On Oct 14, 2008, at 9:08 AM, Scott Doty wrote: > First, the good news: so far, the NANOG conference has been very > valuable and > content-rich, covering a lot of issues that need to be discussed. > For that, I am grateful. Thank you. We worked hard to make it valuable. > > > But now, the bad news(?): Maybe it's just me & my paranoia, but do > I detect > an inkling of "murk spam" going on with some presentations? Not sure what you mean by "murk spam". Thats a term that died years ago. And it really related to people claiming that spam was "in compliance with federal laws". But I think I can guess your intentions from the tone of your email, so let me try and respond. > > > Because there seems to be a fundamental misunderstanding, either on > my part, > or the part of certain vendors: I'm hear to discuss ideas & freely > share > them, and they are here to discuss (it would seem) their products. > Sometimes > both goals coincide, and that is fine...but... > > When a vendor at the security BOF starts showing documents that are > "company > confidential", and trying to whip up a climate of fear, that we > should all > deploy their product in front of our recursive name servers, i get > this > funny feeling that I am being "murk spammed". Well, that's interesting. I see your last NANOG was 9, in February of 1997. So "Welcome back!". We're glad to have you here in person. Things have changed slightly since then. NSP-SEC never existed in 1997. It really came about in the early 2000's where it was developed as a forum for actual operators to share views and thoughts, generally in real time, to help the 'net in general survive disruption, malicious or otherwise. It has really worked pretty well, so if you qualify, I'd encourage you to get involved. See http://puck.nether.net/mailman/listinfo/nsp-security for info. The NSP-SEC bof at NANOG is not quite the same environment as the NSP- SEC mailing list, but it generally includes the same people, plus others from the operations community who take the effort to attend NANOG, and so are sort of self-selected as being "one of the operators" with an already working amount of clue about the subjects that are being discussed. Additionally, the concept of a "trusted environment" still sorta applies. You may not have realized it, but unlike all other sessions at NANOG, the slides are not published, they are not available online, and the session is not broadcast. So "Confidential" was there to remind folks in the BoF that this was a non-public (for a skewed version of public) presentation. Having explained that bit of history which gives you a general background, let me deal with some specifics. > > > Perhaps that is my own perspective (& paranoia?), but I found the CERT > gentleman's call to monitor icmp backscatter on our authoritative > nameservers far more informative -- and open. I don't think anyone from CERT presented. Perhaps you meant Barry Green from Juniper's CERT team? Another "vendor"? Well, as you'll see further on, not really. In this context, like everyone else who presented, he was there as an operator, sharing knowledge and experience. But I digress... > > > But I was disappointed with two vendors and their presentations: the > first > had the tactic of saying "DNSSEC is the actual solution" when asked > about > why their product would be necessary...completely ignoring the fact > that > their proprietary "interim solution" was by no means the only way to > prevent > cache poisoning attacks. Indeed, I would daresay it isn't the best, > either > by a BCP perspective, or a cost analysis perspective. While we may disagree on your last claim (and I actually have a few years of experience to help me argue my point), I specifically said there were a) solutions that solved part of the problem (switching to TCP, detecting and blocking cache poisoning attacks) and b) the right solutions like DLV and DNSSEC that will take some time to be deployed. And I then made sure everyone heard me when I said that we need to find an interim solution that can be deployed *now*, until DNSSEC exists in a useful footprint. I ignore *nothing*. If you have another solution that solves the same problems that has running code now, please share it with all of us. Remember, it has to scale, it has to solve all of the problems, and it has to be implementable across a range of levels of clue. > > > To put a finer point on this, i should say that i found myself > discomforted > by a presentation suggesting that I should put their proprietary > appliances > between my recursive name servers & the Net, and I am grateful that > Mr. > Vixie stood up and said that there are other ways of dealing with the > problem. Indeed. Read further. > > Fortunately, said vendor had a table at "beer and gear", so I was > able to > talk with one of their representatives -- and learned that they have > just as > much trouble with automatic detection of attacks designed to look > like a > "slashdotting"...which cleared up the mystery as to why it wasn't on > the > graphs. > > Because this is a real problem: anybody, with sufficient knowledge & > preparation can vandalize _anybody's_ network. Showing me a graph > that ping > floods happen all the time doesn't impress me -- what would impress > me is > going over the actual methods, algorithms (and heuristics?) used in > these > attack mitigation appliances. > > Because, the "best" attack mitigation appliance vendor would seem to > have > 100% of their market, and thus, charge exhorbant prices for their > product(s). When I brought this up with Mr. Vendor, his first > reaction was > to point out that the cost was less than a home-grown solution. > When I > raised the question of open source software to do the same thing, his > reaction was to ask: "oh? who's going to write it?" > > And that right there would seem to be a bit of bravado, perhaps > fueled by a > misunderstanding of the role that FOSS has played on the Net. > > Fortunately -- and again, I am grateful for this -- the ISC was > represented > in the security BOF, presenting the SIE concept...as well as what > applications _already exist_ to detect and mitigate various > attacks. One > demonstration that blew me away: detecting a botnet being set up > for a > phishing attack...and preventing the attack before it even started. Cool. I'm glad you saw value from that "vendor". Seriously. SIE is good stuff. > > > So in conclusion, I'll say this: the last NANOG I attended was > NANOG 9 -- > and i remember that being a more challenging environment for vendors. > Probably the biggest problem discussed back then was head-of-line > blocking > on a vendor's switches. _That_ is the kind of content that i have > found > valuable, both on this list, and at a conference. > > And so: If I weren't so knock-kneed in public venues, > I would probably be doing what i would like to call on conference > participants to do: if someone gives a presentation that includes > their own > proprietary black-box "solution", I think the best benefit for NANOG > would > be to point out alternatives. *I* was the "vendor" at the security BOF you took aim at. Except I am not a vendor in this environment. I am an operator. Just like ISC (Vixie) and McPherson (Arbor) and Greene (Juniper) etc. We are there as operators and *none* of us was selling *anything. We were describing issues that we currently are facing as operators, and solutions we have developed. You're not alone amongst "newcomers" in missing the point, so don't be hard on yourself ;-). In my case, *nothing* was being sold, other than *a* solution, which I am actually *giving* away to networks that matter in solving the probelm, and picking up the costs myself. I assume you missed that. And the reason I was doing that with a *proprietary* solution was because the open source solution is *not yet ready* for prime time, mainly because it (they) have not solved the wide implementation challenge. And *we* need to find a solution today while the open source (and best solution) gets rolled out effectively. Paul (also a "vendor" in the same vein, but an operator in the BoF forum) answered the question of whether there was another solution by saying "there is in Bind 9.6" - his product, which was released a couple of weeks ago. I referred to it in my presentation, as a solution, along with DNSSEC. It's called DLV. Unfortunately, and Paul admits it, there are challenges to widespread adoption. It works, but there is no business case that makes it easy to roll out. And therein lies the challenge. My customers need it today. And if it isn't out there in wide use, *it doesn't solve the problem*. So I am solving that by picking up the tab myself, and being reimbursed by the people I am a vendor to, my customers. And they're happy to pay for it. None of them were at the bof. Well, not strictly true, but not in numbers to matter. But hopefully you get the point. And you now understand that in the BoF we are all working to try and *solve* problems, not sell products. I'm sorry you failed to grok that difference. Finally, despite your knocking knees, you should have stood up and questioned anything you heard, or misunderstood. Then you would have had a better experience of the bof. As a member of the Program Committee and coincidentally the host of this NANOG, I'm sorry we didn't do a better job. We're trying to get better. I think that this was one of the best NANOGs we've ever had. But I'm biased, especially this time ;-). As an aside, since you were last at a NANOG, we now have Beer 'n Gear, where Vendors have the opportunity to show off their wares, and in exchange they support and underwrite some of the costs of what is a pretty slick conference. I'm not sure why you believe that the vendor pitching his/her products at Beer 'n Gear is in some way violating the sacred rule against talking about a product. The B&G specifically provides the controlled environment and tradeoff. And *most* operators appreciate it, and make really good use of the opportunity to learn about new products that actually matter in such a useful environment. In one place we get to talk to actual engineers, about their products, together with 500 fellow operators who ask questions we may not even know we should ask. If you have any other questions about my presentation, or the program, please feel free to ask directly. > > > -Scott > p.s. sorry for the long post. Ditto for the response. But I have to assume you were not the only one who may have missed key points. Thanks for coming back. Hopefully we'll see you in the Dominican Republic next January. From morrowc.lists at gmail.com Wed Oct 15 15:40:13 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 Oct 2008 16:40:13 -0400 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <23C6BF4F-9B74-4798-9BA1-88701398B8A8@kumari.net> References: <48F4C410.50605@sonic.net> <23C6BF4F-9B74-4798-9BA1-88701398B8A8@kumari.net> Message-ID: <75cb24520810151340m4cef5f04t3cd3c0d3f8d1b933@mail.gmail.com> On Wed, Oct 15, 2008 at 4:05 PM, Warren Kumari wrote: > > On Oct 14, 2008, at 12:08 PM, Scott Doty wrote: >> When a vendor at the security BOF starts showing documents that are >> "company >> confidential", and trying to whip up a climate of fear, that we should all >> deploy their product in front of our recursive name servers, i get this >> funny feeling that I am being "murk spammed". > > Hmmm... The vendor that you are referring to provides authoritative DNS for > many domains (and, at least some of them I view as "important", meaning that > I would prefer a correct response!). Yes, I am sure that he would be happy > to have you as a customer and, yes, this is feature that differentiates his > company, but I did not get the impression AT ALL that he was trying to sell > his service, but rather provide better service to his existing customers, > even going so far as to provide free devices to people who run large > recursive resolvers. This helps both his existing customers (who, yes, will > be more likely to continue using him), but, more importantly helps me as an > end user feel a little comfortable that the page that I am getting is the > correct page... it's probably also worth noting that the person in question has a history of giving away this sort of protection (in other forms) for the DNS system... and innovating as a DNS service provider, both for free (howdy: 4.2.2.1) and for a price.... I'm not sure I'd classify anything he does as a sales pitch in the venue in question. -Chris From nanog at ian.co.uk Wed Oct 15 16:05:14 2008 From: nanog at ian.co.uk (Ian Mason) Date: Wed, 15 Oct 2008 22:05:14 +0100 Subject: Network topology In-Reply-To: <48F61FC3.2080602@karnaugh.za.net> References: <48F61A6C.5050201@karnaugh.za.net> <48F61FC3.2080602@karnaugh.za.net> Message-ID: <96BCF604-8645-4F7A-B05A-A10999F0C8C1@ian.co.uk> On 15 Oct 2008, at 17:52, Colin Alston wrote: > On 2008/10/15 06:29 PM Bill Woodcock wrote: >> InterMapper. http://dartware.com/network_monitoring_products/ >> intermapper/index.html >> -Bill > > Whoa, quite a serious looking piece of software. Will check it out. > > Was kinda hoping to write my own software though, but perhaps I can > craftily learn something from it :) > If you have SNMP access pull:- 1) Is it a bridge or a router? 2) ARP Table 3) MAC forwarding table 4) Interfaces with MAC and IP addresses 5) Netmasks from each such router or bridge in the network. Use the information from one to help you discover the others recursively. Have a termination condition that stops this process walking off your network and attempting to discover the whole Internet. That's enough to figure out both logical and physical topology. Without SNMP (or similar) access it's nigh impossible to figure out. If you only have access to a subset of the routers and bridges in the network you MAY have enough to figure out the topology - 50% is enough if it's the right 50%. Ian From dean at av8.com Wed Oct 15 16:34:42 2008 From: dean at av8.com (Dean Anderson) Date: Wed, 15 Oct 2008 17:34:42 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F4C410.50605@sonic.net> Message-ID: On Tue, 14 Oct 2008, Scott Doty wrote: > First, the good news: so far, the NANOG conference has been very > valuable and content-rich, covering a lot of issues that need to be > discussed. For that, I am grateful. > > But now, the bad news(?): Maybe it's just me & my paranoia, but do I > detect an inkling of "murk spam" going on with some presentations? Judging by the email after this, the 'vendor' involves Rodney Joffe and probably UltraDNS. My opinion: Yes, you are being 'murk spammed' Joffe and company represent what Professor Dan Bernstein (DJBDNS) calls the 'Bind Company'. I think a better term is the 'BIND Cartel', since it is a collection of companies and individuals. Joffe, Vixie, John Levine et al own or direct Whitehat.com, a spammer. Remember Sanford Wallace? Wallace sent spam and offered anti-spam services; that was a non-starter for many. Vixie, Joffe, Levine et al just stole Wallace's business plan and false-teamed themselves as anti-spammers. What they were really doing was sending spam, and using the MAPS blacklist to detect and interfere with their competitors, and using the credentials with the anti-spam commun and inside information to avoid spam-traps. See http://www.iadl.org/maps/maps-story.html Joffe/Centergate/Bill Manning was the founder of UltraDNS. Manning is also connected to Vixie through PAIX, and to ISC employee Susan Woolf through ISI. Vixie, Conrad, Manning, Woodcock, Curran, Plzak, Ed Lewis, etc all worked together at ARIN, and have had 22 ARIN employees attend NANOG, including the ARIN executive secretary. ARIN is giving NANOG $50,000 checks, even though the Board members have undisclosed conflicts of interest. ARIN resource analysts have (and probably are now) attending NANOG. The resource analysts are the guys who make allocation decisions, so getting chummy with NANOG people is a conflict of interest in the making. So far, I've discovered two cases where ARIN has made allocations in 2 hours. Have they done this before? The answer is yes. The previous scam was AXFR-clarify draft. The draft was presented by the BIND Cartel as not changing the DNS protocol, but in fact did change the protocol. When Dr. Bernstein discovered this, and reported it, Bernstein's email was disrupted and censored. There are other scams that I'm writing up, but this gives you some inkling of what's going on now and what's gone on before. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From David_Hankins at isc.org Wed Oct 15 17:06:04 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Wed, 15 Oct 2008 15:06:04 -0700 Subject: Network topology [Solved] In-Reply-To: <48F637F5.9020303@karnaugh.za.net> References: <48F61A6C.5050201@karnaugh.za.net> <48F637F5.9020303@karnaugh.za.net> Message-ID: <20081015220604.GK5337@isc.org> On Wed, Oct 15, 2008 at 08:35:33PM +0200, Colin Alston wrote: > Apparently there isn't. Lots of people mentioned other tools, the problem > there is they have one thing in common which is polling SNMP. I think it > scales badly in general. I was hoping to find a more intelligent way of, I I don't know what scaling parameters you're looking for. The tool I wrote to recursively traverse Cisco CDP caches via SNMP, from ~7 seed routers, autodetected the interconnections of a ~100 node network (back in 1998) in just seconds (I think it was 3, but that was ten years ago). Using SNMP. It didn't strain our P90 it was running on, nor the network. People often do SNMP wrong (one PDU per packet, single-threaded transmitters, etc). > Maybe there should be something (I mean like, someone should come up with a > standard :P) to trace switches in a path... Problem is I think even then > the simple devices won't bother to support it. Or if they do, they'll do it wrong. They can't even get ifDescr right. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From ml at t-b-o-h.net Wed Oct 15 17:14:50 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 15 Oct 2008 18:14:50 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: Message-ID: <200810152214.m9FMEoic037844@himinbjorg.tucs-beachin-obx-house.com> > > Vixie, Conrad, Manning, Woodcock, Curran, Plzak, Ed Lewis, etc all > worked together at ARIN, and have had 22 ARIN employees attend NANOG, > including the ARIN executive secretary. ARIN is giving NANOG $50,000 > checks, even though the Board members have undisclosed conflicts of > interest. ARIN resource analysts have (and probably are now) attending > NANOG. The resource analysts are the guys who make allocation decisions, > so getting chummy with NANOG people is a conflict of interest in the > making. So far, I've discovered two cases where ARIN has made > allocations in 2 hours. > Didn't you get banned temporarily from this list, then banned for life + 5 years, your children and grandchildren also banned for their lives + 5 years once before for all this? Tuc/TBOH From vixie at isc.org Wed Oct 15 17:22:25 2008 From: vixie at isc.org (Paul Vixie) Date: Wed, 15 Oct 2008 22:22:25 +0000 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <75cb24520810151340m4cef5f04t3cd3c0d3f8d1b933@mail.gmail.com> (Christopher Morrow's message of "Wed\, 15 Oct 2008 16\:40\:13 -0400") References: <48F4C410.50605@sonic.net> <23C6BF4F-9B74-4798-9BA1-88701398B8A8@kumari.net> <75cb24520810151340m4cef5f04t3cd3c0d3f8d1b933@mail.gmail.com> Message-ID: "Christopher Morrow" writes: > On Wed, Oct 15, 2008 at 4:05 PM, Warren Kumari wrote: >> >> On Oct 14, 2008, at 12:08 PM, Scott Doty wrote: > >>> When a vendor at the security BOF starts showing documents that are >>> "company confidential", and trying to whip up a climate of fear, that >>> we should all deploy their product in front of our recursive name >>> servers, i get this funny feeling that I am being "murk spammed". >> >> ... I did not get the impression AT ALL that he was trying to sell his >> service, but rather provide better service to his existing customers, >> even going so far as to provide free devices to people who run large >> recursive resolvers. ... i've heard the following concerns about this free device expressed to me. first, its value-add is its proprietary relationship to one dns authority (ultradns), so if neustar deploys a lot of them it will create third party incentive among domainholders to move their authority service to neustar. so while other commercial authority dns vendors (such as nominum or microsoft) might be willing to license this proprietary technology from neustar and we can all assume that there are commercial terms under which neustar would do this, we can also expect that domainholders who prefer to self-host using f/l/oss (bind, nsd, tinydns, powerdns, etc) won't have that option. rodney said it was necessary that neustar not have to wait for the standards community before deploying this service, but noone asked him why he hasn't open-sourced his solution so that other dns authority suppliers can also benefit from the recursive-dns frontend boxes he's giving away. i know that neustar is in the business of selling outsourced authority dns, so i understood scott doty's comments as referring to the pressure a large deployment of free recursive-dns frontend boxes will put on anyone who isn't a neustar customer to please become a neustar customer so that their zones will be safer. second, there's no real possibility that someone who deploys a free neustar box inline/upstream of their recursive dns server would also deploy a second one if anyone else with a proprietary solution wanted to follow neustar's example. rodney did not say whether the front-end boxes were user programmable or whether he planned to make it possible for competitors of neustar to embed their solutions in this free box. rodney also did not say how many boxes would be available for free before neustar would have to start charging for them, nor whether the price at that point would represent cost recovery or also be a profit center for neustar. these questions also appear (to me) to be implied by scott doty's original question. now for my own concerns. > it's probably also worth noting that the person in question has a > history of giving away this sort of protection (in other forms) for > the DNS system... and innovating as a DNS service provider, both for > free (howdy: 4.2.2.1) and for a price.... I'm not sure I'd classify > anything he does as a sales pitch in the venue in question. in spite of my great admiration for rodney's lifetime of contribution, i do not see any natural consequence toward dnssec from this dns frontend giveaway. i have total confidence that the solution will work, and reasonable confidence that it will indirectly improve neustar's revenue outlook, but no confidence that anyone who wasn't planning to deploy dnssec in their product or network will, as a result of rodney's work, decide to deploy dnssec. far better in my opinion would be for rodney to sign all the zone he carries (keeping the keys he has to generate in escrow to be surrendered to the domainholders upon demand with a reasonable escrow and transfer fee), and to either start his own DLV registry or to offer free secondary service to ISC's DLV registry, and to submit all his customer keys to whichever DLV registry he decided upon. anyone running BIND 9.3.0 (not 9.6.0 as was mentioned -- we're talking about old and somewhat stable code here) can just speak DLV directly. anyone who can and wants to upgrade to BIND with its DLV support can do that. anyone else could install a free recursive dns frontend box from neustar that would do inline DLV. but there's a pure software-only solution that would work. (noting that in rodney's preso he spoke of the many folks who have never upgraded their nameservers, are still running BIND4, etc, but for the larger recursive dns operators this isn't how they work and they can deploy new code, and it would be very easy for nominum-ans and nlnetlabs-unbound to implement DLV, which is unencumbered even though never subject to IETF delays.) it's easy to assume that my worry about this is as someone in the authority dns business whose customers (the vast majority of whom pay nothing), who stands to lose market share when rodney starts pushing his boxes into the field. but since i've been giving away free shovels to people who mostly want to buy holes, and rodney sells holes, i think that ship has already sailed. the baser knee-jerk reaction underlying my discomfort is that isc's mission statement (front and center at www.isc.org) values the autonomy of the internet's participants. dnssec does that. a dnssec-based solution, or a dnssec-leveraging solution, does that. rodney's plan doesn't do that. i'd welcome raw data about dns poisonining events, too. we're scanning the hell out of all the open recursives, and we're not finding much poison, in spite of all the "please stop querying our nameserver!" complaints we incite. so while i want dnssec, i'm pretty comfortable with 16-bit port randomization as a stopgap. rodney's free inline recursive dns frontend could just do 16-bit port randomization if all we want is an until-there-is-dnssec stopgap. -- Paul Vixie From dean at av8.com Wed Oct 15 17:26:20 2008 From: dean at av8.com (Dean Anderson) Date: Wed, 15 Oct 2008 18:26:20 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: Message-ID: >> Vixie, Conrad, Manning, Woodcock, Curran, Plzak, Ed Lewis, etc all >> worked together at ARIN, and have had 22 ARIN employees attend NANOG, >> including the ARIN executive secretary. ARIN is giving NANOG $50,000 >> checks, even though the Board members have undisclosed conflicts of >> interest. ARIN resource analysts have (and probably are now) >> attending NANOG. The resource analysts are the guys who make >> allocation decisions, so getting chummy with NANOG people is a >> conflict of interest in the making. So far, I've discovered two cases >> where ARIN has made allocations in 2 hours. >> > > Didn't you get banned temporarily from this list, then banned >for life + 5 years, your children and grandchildren also banned for >their lives + 5 years once before for all this? I was never temporarilly banned. I was banned in 2000 so that I couldn't gloat that the CFAA applied to ISPs. See http://www.iadl.org/nanog/nanog-story.html Looks like someone messed up. ;-) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From simon at darkmere.gen.nz Wed Oct 15 17:26:56 2008 From: simon at darkmere.gen.nz (Simon Lyall) Date: Thu, 16 Oct 2008 11:26:56 +1300 (NZDT) Subject: ADMIN: off-topic emails In-Reply-To: References: Message-ID: A reminder to all list members that: 1. DNS related questions should usually be sent to more specific lists such as DNS operations: http://lists.oarci.net/mailman/listinfo/dns-operations 2. Discussion regarding the NANOG organisation and political issues surrounding it are off-topic for the main list and must only occur on the nanog-futures list http://mailman.nanog.org/mailman/listinfo/nanog-futures Simon Lyall NANOG Mailing List Committee -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From ml at t-b-o-h.net Wed Oct 15 18:39:48 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 15 Oct 2008 19:39:48 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: Message-ID: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> > > >> Vixie, Conrad, Manning, Woodcock, Curran, Plzak, Ed Lewis, etc all > >> worked together at ARIN, and have had 22 ARIN employees attend NANOG, > >> including the ARIN executive secretary. ARIN is giving NANOG $50,000 > >> checks, even though the Board members have undisclosed conflicts of > >> interest. ARIN resource analysts have (and probably are now) > >> attending NANOG. The resource analysts are the guys who make > >> allocation decisions, so getting chummy with NANOG people is a > >> conflict of interest in the making. So far, I've discovered two cases > >> where ARIN has made allocations in 2 hours. > >> > > > > Didn't you get banned temporarily from this list, then banned > >for life + 5 years, your children and grandchildren also banned for > >their lives + 5 years once before for all this? > > I was never temporarilly banned. I was banned in 2000 so that I couldn't > gloat that the CFAA applied to ISPs. See > http://www.iadl.org/nanog/nanog-story.html > > Looks like someone messed up. ;-) > Well, yes and no........... I actually was thinking of the ARIN list that you had the temporary ban on : http://lists.arin.net/pipermail/arin-discuss/2008-February/000897.html and then the permanent ban : http://lists.arin.net/pipermail/arin-discuss/2008-June/001058.html as for banning from NANOG, there is a message, purportedly from you : http://lists.arin.net/pipermail/arin-discuss/2008-February/000890.html contains "So Harris banned me from NANOG." . Not sure if thats the meeting, the NANOG list, or one of the NANOG/Merit other lists. Also, in : http://www.iadl.org/nanog/nanog-story.html I see "So, effective May 4 2005, Harris again banned Anderson. Although the new "reformed" rules require a limit of 6 months, Anderson remains banned as of April 16th, 2006. It seems permanent." but I think that refers to another NANOG group, dnsop. Tuc/TBOH From matthew at sorbs.net Wed Oct 15 19:33:31 2008 From: matthew at sorbs.net (matthew at sorbs.net) Date: Thu, 16 Oct 2008 11:33:31 +1100 Subject: The DDOS problem & security BOF: Am i mistaken? Message-ID: ----- Original Message ----- From: "Tuc at T-B-O-H.NET" Date: Thursday, October 16, 2008 10:39 am Subject: Re: The DDOS problem & security BOF: Am i mistaken? > > contains "So Harris banned me from NANOG." . Not sure if thats the > meeting,the NANOG list, or one of the NANOG/Merit other lists. > Also, in : > > http://www.iadl.org/nanog/nanog-story.html > > I see "So, effective May 4 2005, Harris again banned Anderson. > Although > the new "reformed" rules require a limit of 6 months, Anderson > remains banned > as of April 16th, 2006. It seems permanent." > > but I think that refers to another NANOG group, dnsop. Yeah and he still doesn't learn ;-) M From dwcarder at wisc.edu Wed Oct 15 21:18:44 2008 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 15 Oct 2008 21:18:44 -0500 Subject: Network topology [Solved] In-Reply-To: <48F637F5.9020303@karnaugh.za.net> References: <48F61A6C.5050201@karnaugh.za.net> <48F637F5.9020303@karnaugh.za.net> Message-ID: On Oct 15, 2008, at 1:35 PM, Colin Alston wrote: > On 2008/10/15 06:29 PM Colin Alston wrote: >> Is there any kind of cunning trick to detect standard layer2 >> switches along a path without stuff like STP? > > Apparently there isn't. Lots of people mentioned other tools, the > problem there is they have one thing in common which is polling > SNMP. I think it scales badly in general. What is your reasoning behind this claim? I would claim quite the opposite compared to CLI or TL1. > Maybe there should be something (I mean like, someone should come > up with a standard :P) to trace switches in a path I've written a cruddy script that given a seed bridge, scrapes L2 information obtained via CDP (I guess it could do LLDP, too) and does a breadth-first search through a network. Then I just dump that into gnuplot format. Getting the data is easy compared to visualization. A coworker of mine has written script to ask Rapid-STP speaking switches about their current topology and builds a graph again in gnuplot format. A more challenging approach would be to scrape the mac forwarding tables and stitch things together. This would have to be done per-vlan. I think this approach (or similar) might be done by Openview's L2 featureset. Dale -- Dale W. Carder - Network Engineer University of Wisconsin / WiscNet http://net.doit.wisc.edu/~dwcarder From nanog-post at rsuc.gweep.net Wed Oct 15 22:15:29 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 15 Oct 2008 23:15:29 -0400 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <200810152214.m9FMEoic037844@himinbjorg.tucs-beachin-obx-house.com> References: <200810152214.m9FMEoic037844@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20081016031529.GA34755@gweep.net> [snip] http://www.gweep.net/~crimson/Don't_Feed_The_Trolls.mp3 -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From scott at sonic.net Wed Oct 15 23:37:38 2008 From: scott at sonic.net (Scott Doty) Date: Wed, 15 Oct 2008 21:37:38 -0700 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <01A53E5A-F4D1-45A8-B36F-2FA82E352B0C@centergate.com> References: <48F4C410.50605@sonic.net> <01A53E5A-F4D1-45A8-B36F-2FA82E352B0C@centergate.com> Message-ID: <48F6C512.2060707@sonic.net> I do seem to have put my foot in my mouth. I apologize for any offense my comments made, as well as any misunderstanding on my part. I see the note to take this discussion to nanog-futures, so I'll reply further there. And the Security BOF was very good, I was thankful to have been there and hear the discussion. Next time I'll use the microphone. Thank you, -Scott From rjoffe at centergate.com Thu Oct 16 02:50:12 2008 From: rjoffe at centergate.com (Rodney Joffe) Date: Thu, 16 Oct 2008 00:50:12 -0700 Subject: Ten years ago today..... Message-ID: Jon Postel left us. A vacuum still unfilled. http://www.isi.edu/div7/people/postel.home/ From truman at suspicious.org Thu Oct 16 12:03:18 2008 From: truman at suspicious.org (Truman Boyes) Date: Thu, 16 Oct 2008 13:03:18 -0400 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <48F4F7C7.1020808@sonic.net> References: <48F4F7C7.1020808@sonic.net> Message-ID: <70DEF96C-1E52-4B02-A45F-F9F6541C6488@suspicious.org> It's a good point that you brought up. Even though we already have IPv6 P2P (Nathan's post explains this in more detail), it would still be quite interesting to provide IPv6 as a higher class of traffic within service provider networks. Quite likely 6to4 relays and native IPv6 traffic is best effort today (ie. the same as IPv4 inet). I think operators would need to consider the financial implications of placing this traffic ahead of their current revenue generating services. Possibly instead of prioritizing the traffic, if the ISPs that normally police traffic from CE's could provide a higher policed rate for IPv6 traffic, so the experience is significantly different even in times where there is no congestion. Truman On 14/10/2008, at 3:49 PM, Scott Doty wrote: > We've had one presentation on the "unfairness" of p2p traffic, which > (the presenter says) will eventually swamp us. > > Then just now, we had the presentation & subsequent discussion re: > ipv6 > adoption. > > Just wondering: what if we gave ipv6 traffic "mucho priority" over > ipv4 > traffic, then tell our user communities that ipv6 provides a better > quality network experience, including (hopefully) faster page loads, & > lower video game pings? > > With such policies in place, folks wouldn't want to stay with the > "old, > slow" v4 traffic...and could be a significant selling point. > > After all, if most p2p traffic is v4, prioritizing ipv6 (as a > general concept) should improve the user experience. > > Anyway, was just an idea, please pardon me if this has been discussed > before, or sounds nutty... > > Thanks, > > -Scott > > > From patrick.g.felt at L-3com.com Thu Oct 16 13:18:51 2008 From: patrick.g.felt at L-3com.com (patrick.g.felt at L-3com.com) Date: Thu, 16 Oct 2008 12:18:51 -0600 Subject: ATT dns admins Message-ID: <6E28F1BD0F8AA94D9CD63E117CA5B578084FA4@MAIL1.csw.l-3com.com> It looks like ATT has delegated some networks to our DNS servers. We need to get those changed and have no idea on who the contacts are. Are there any ATT dns admins that can contact me offline? Thanks, Patrick Felt From dhetzel at gmail.com Thu Oct 16 15:00:30 2008 From: dhetzel at gmail.com (Alan Hetzel) Date: Thu, 16 Oct 2008 16:00:30 -0400 Subject: 3845 memory Message-ID: <7db2dcf90810161300k1dc81d0eg3845ea3351fffa7f@mail.gmail.com> How many (if any) full BGP feeds should a 3845 with 256M memory normally be expected to take? From andy-nanog at bash.sh Thu Oct 16 15:03:50 2008 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Thu, 16 Oct 2008 22:03:50 +0200 Subject: 3845 memory In-Reply-To: <7db2dcf90810161300k1dc81d0eg3845ea3351fffa7f@mail.gmail.com> References: <7db2dcf90810161300k1dc81d0eg3845ea3351fffa7f@mail.gmail.com> Message-ID: On Thu, Oct 16, 2008 at 10:00 PM, Alan Hetzel wrote: > How many (if any) full BGP feeds should a 3845 with 256M memory normally be > expected to take? > Less than one? :) From cchurc05 at harris.com Thu Oct 16 15:15:11 2008 From: cchurc05 at harris.com (Church, Charles) Date: Thu, 16 Oct 2008 15:15:11 -0500 Subject: 3845 memory In-Reply-To: References: <7db2dcf90810161300k1dc81d0eg3845ea3351fffa7f@mail.gmail.com> Message-ID: Agree. Our 2821 with 2 full views running 12.4 mainline and 768MB ram has 427 free. So using 340 for OS and tables... Chuck -----Original Message----- From: Andrew Mulholland [mailto:andy-nanog at bash.sh] Sent: Thursday, October 16, 2008 4:04 PM To: Alan Hetzel Cc: nanog at nanog.org Subject: Re: 3845 memory On Thu, Oct 16, 2008 at 10:00 PM, Alan Hetzel wrote: > How many (if any) full BGP feeds should a 3845 with 256M memory normally be > expected to take? > Less than one? :) From surfer at mauigateway.com Thu Oct 16 15:17:08 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 16 Oct 2008 13:17:08 -0700 Subject: 3845 memory Message-ID: <20081016131708.67B064A@resin18.mta.everyone.net> --- dhetzel at gmail.com wrote: From: "Alan Hetzel" How many (if any) full BGP feeds should a 3845 with 256M memory normally be expected to take? ------------------------------------------- You might try on a cisco specific list like cisco-nsp. scott From bfeeny at mac.com Thu Oct 16 15:18:58 2008 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 16 Oct 2008 16:18:58 -0400 Subject: 3845 memory In-Reply-To: <7db2dcf90810161300k1dc81d0eg3845ea3351fffa7f@mail.gmail.com> References: <7db2dcf90810161300k1dc81d0eg3845ea3351fffa7f@mail.gmail.com> Message-ID: 3845 is plenty powerful, its the equivalent of an NPE-400 basically, but you should plan on 512MB minimum with full BGP, so that you make sure you have room for other things as well on the router. Its not linear of course, since there is alot of redundant information with multiple BGP feeds, so you won't need another 512MB per peer. Brian On Oct 16, 2008, at 4:00 PM, Alan Hetzel wrote: > How many (if any) full BGP feeds should a 3845 with 256M memory > normally be > expected to take? From jra at baylink.com Thu Oct 16 16:56:13 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 16 Oct 2008 17:56:13 -0400 (EDT) Subject: Ten years ago today..... In-Reply-To: Message-ID: <30539996.107091224194173184.JavaMail.root@benjamin.vicimarketing.com> ----- "Rodney Joffe" wrote: > Jon Postel left us. A vacuum still unfilled. I thought I felt a ripple in the Force, today. It was as if 4.2 billion IP addresses cried out, then were silenced. Requiescat in Pace. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From smj at merit.edu Thu Oct 16 18:28:52 2008 From: smj at merit.edu (Sue Joiner) Date: Thu, 16 Oct 2008 19:28:52 -0400 (EDT) Subject: Fwd: [NANOG-announce] New NANOG Steering Committee In-Reply-To: <20081015193337.GB19658@gweep.net> Message-ID: <1068437801.2553381224199732784.JavaMail.root@crono> ----- Forwarded Message ----- From: "Joe Provo" To: nanog-announce at nanog.org Sent: Wednesday, October 15, 2008 3:33:38 PM GMT -05:00 US/Canada Eastern Subject: [NANOG-announce] New NANOG Steering Committee The new NANOG SC held its first meeting on Tuesday evening of NANOG44. One of the first action items for the SC (as per 6.1 in the Charter) is to appoint a new chair to serve for a one year term. After holding a vote, I would like to report that I have been accorded the privilege of being chair of the NANOG SC for the next year. As incoming chair, and on behalf of the new SC, I'd like to thank Philip Smith for his exceptional leadership in the last year as outgoing SC Chair, as well as thank him for his service to the community as member of the SC for many years. I would also like to extend the SC's significant thanks to Randy Bush for his long history of valuable contribution to NANOG and the SC during his term of service on the SC. Both he and Philip have put in enormous time and energy to help NANOG be what it is today. They leave large shoes to fill. The new Steering Committee is as follows: Betty Burke (Merit Appointee) Steve Feldman Patrick Gilmore Jared Mauch Chris Morrow Joe Provo Rob Seastrom with the MLC Chair (Kris Foster) and the PC Chair (TBA) serving as non-voting members. Joe Provo (for the SC) -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From smj at merit.edu Thu Oct 16 18:30:01 2008 From: smj at merit.edu (Sue Joiner) Date: Thu, 16 Oct 2008 19:30:01 -0400 (EDT) Subject: Fwd: [NANOG-announce] New NANOG Program Committee In-Reply-To: <20081016055415.GA6286@gweep.net> Message-ID: <1114642224.2553451224199801081.JavaMail.root@crono> ----- Forwarded Message ----- From: "Joe Provo" To: nanog-announce at nanog.org Sent: Thursday, October 16, 2008 1:54:15 AM GMT -05:00 US/Canada Eastern Subject: [NANOG-announce] New NANOG Program Committee In its last scheduled meeting, the NANOG Steering Committee selected a new Programme Committee. With seventeen very well-qualified candidates and eight open positions, it was a difficult decision to make. The SC, with input from the current PC and the community, felt it necessary to form a balanced PC, with a diversity of backgrounds, knowledge, and experience, and one that is representative of the entire NANOG constituency. The SC would like to thank outgoing the PC member Keith Mitchell for his valuable contributions while serving on the PC. Additionally, the SC is grateful to the eight candidates who volunteered their time but who weren't selected. We hope they will all consider volunteering again next time. The NANOG Programme Committee for 2008/2009 is as follows: Existing members: Larry Blunk (Merit appointee) Joel Jaeggli Rodney Joffe Sylvie LaPerriere Kevin Oberman Lane Patterson Ren Provo Josh Snowhorn Todd Underwood New (and returning) members: Nina Bargisen Tom Daly Brian Deardorff Igor Gashinsky Mike Hughes David Meyer Tom Scholl Richard Steenbergen Joe Provo SC Chair -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jlloret at dcom.upv.es Thu Oct 16 18:47:59 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Fri, 17 Oct 2008 01:47:59 +0200 Subject: 3rd CfP: ICNS 2009 | April 21-25, 2009 - Valencia, Spain Message-ID: <1224200879.48f7d2af41ab8@webmail.upv.es> Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Apologies for cross-postings. ============== ICNS 2009 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ICNS 2009, The Fifth International Conference on Networking and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/ICNS09.html Call for Papers: http://www.iaria.org/conferences2009/CfPICNS09.html Important deadlines: Submission (full paper) November 1, 2008 Authors notification December 5, 2008 Registration December 20, 2008 Camera ready December 25, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum special submission with on progress and challenging ideas. ICNS 2009 Area Tracks are the following (details in the CfP on site): ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications IPv6DFI: Deploying the Future Infrastructure IPDy: Internet Packet Dynamics GOBS: GRID over Optical Burst Switching Networks ================================= - ICNS General Chair Jaime Lloret Mauri, Polytechnic University of Valencia, Spain - ICNS 2009 Industry Chairs Kevin Y Ung, Boeing, USA Leo Lehmann, OFCOM, Switzerland Francisco Javier S?nchez, Administrador de Infraestructuras Ferroviarias (ADIF), Spain - ICNS 2009 Technical Program Committee Chair Giancarlo Fortino, Universit? della Calabria, Italy Salvador Sales, Polytechnic University of Valencia, Spain Feng Xia, Queensland University of Technology, Australia / Zhejiang University, China - ICNS Advisory Chairs Wojciech Burakowski, Warsaw University of Technology, Poland Vicente Casares, Polytechnic University of Valencia, Spain Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Xiaohua Jia, City University of Hong Kong - Kowloon, Hong Kong Manuel Sierra-P?rez, Universidad Polit?cnica de Madrid, Spain ================================ -- From glen.kent at gmail.com Thu Oct 16 20:23:15 2008 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 17 Oct 2008 06:53:15 +0530 Subject: SMS Standards Message-ID: <92c950310810161823w2a54e5f5he1584104772660ea@mail.gmail.com> Hi, Apologies in advance since this is off-topic. However, posting in on nanog since i am confident that we will have some experts who would be able to guide me here. I want to study the standards (RFC equivalent) for sending and receiving SMSs. Any ideas on what kind of protocol runs between a mobile phone and a SMS center (SMSC)? Thanks, Glen From bep at whack.org Thu Oct 16 20:41:59 2008 From: bep at whack.org (Bruce Pinsky) Date: Thu, 16 Oct 2008 18:41:59 -0700 Subject: SMS Standards In-Reply-To: <92c950310810161823w2a54e5f5he1584104772660ea@mail.gmail.com> References: <92c950310810161823w2a54e5f5he1584104772660ea@mail.gmail.com> Message-ID: <48F7ED67.8050504@whack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Glen Kent wrote: > Hi, > > Apologies in advance since this is off-topic. However, posting in on > nanog since i am confident that we will have some experts who would be > able to guide me here. > > I want to study the standards (RFC equivalent) for sending and > receiving SMSs. Any ideas on what kind of protocol runs between a > mobile phone and a SMS center (SMSC)? > Wiki_Pedia is your friend http://en.wikipedia.org/wiki/Short_message_service The Short Message Service - Point to Point (SMS-PP) is defined in GSM recommendation 03.40.[2] GSM 03.41 defines the Short Message Service - Cell Broadcast (SMS-CB) which allows messages (advertising, public information, etc.) to be broadcast to all mobile users in a specified geographical area.[16] Messages are sent to a Short Message Service Centre (SMSC) which provides a store-and-forward mechanism. It attempts to send messages to their recipients. If a recipient is not reachable, the SMSC queues the message for later retry.[17] Some SMSCs also provide a "forward and forget" option where transmission is tried only once. Both Mobile Terminated (MT), for messages sent to a mobile handset, and Mobile Originating (MO), for those that are sent from the mobile handset, operations are supported. Message delivery is best effort, so there are no guarantees that a message will actually be delivered to its recipient and delay or complete loss of a message is not uncommon, particularly when sending between networks. Users may choose to request delivery reports (simply add *0# or *N# to the beginning of your text message), which can provide positive confirmation that the message has reached the intended recipient. Transmission of short messages between the SMSC and the handset is done using the Mobile Application Part (MAP) of the SS7 protocol. Messages are sent with the MAP mo- and mt-ForwardSM operations, whose payload length is limited by the constraints of the signalling protocol to precisely 140 octets (140 octets = 140 * 8 bits = 1120 bits). Short messages can be encoded using a variety of alphabets: the default GSM 7-bit alphabet (shown below), the 8-bit data alphabet, and the 16-bit UTF-16/UCS-2 alphabet.[18] Depending on which alphabet the subscriber has configured in the handset, this leads to the maximum individual Short Message sizes of 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters (including spaces). Support of the GSM 7-bit alphabet is mandatory for GSM handsets and network elements,[18] but characters in languages such as Arabic, Chinese, Korean, Japanese or Cyrillic alphabet languages (e.g. Russian) must be encoded using the 16-bit UCS-2 character encoding (see Unicode). Routing data and other metadata is additional to the payload size. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj37WcACgkQE1XcgMgrtyZiVACgjSYOrHVRE9g1vufxWpa67rC6 o8YAn1JjliEYx73fLGXbIOyeTTZtsj/S =2vZP -----END PGP SIGNATURE----- From dean at av8.com Thu Oct 16 21:31:21 2008 From: dean at av8.com (Dean Anderson) Date: Thu, 16 Oct 2008 22:31:21 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> Message-ID: Since you so many facts wrong, a response is necessary. On Wed, 15 Oct 2008, Tuc at T-B-O-H.NET wrote: > I actually was thinking of the ARIN list that you had the temporary > ban on : > > http://lists.arin.net/pipermail/arin-discuss/2008-February/000897.html I don't have a page on this because it is currently the subject of litigation. However, since you brought it up, I have to defend myself. As my attorney pointed out to ARIN, this ban was based on a fabrication by ARIN. Among other things, ARIN also threatened to make false claims that I sent spam to the ARIN lists. ARIN has also published the communications between my lawyer and ARIN's lawyer, which is very irregular. This particular ban disrupted and ended a discussion about the lack of quorum in elections that brought Bradner, Curran, Howard, Manning, Vixie and Woodcock to the ARIN Board of Directors. Notices were recently sent (certified mail) to all six ARIN Board Members informing them of the lack of quorum in their election and that they are not authorized to act as Board Members. The ban has prevented other voting members from learning these facts. (Manning and Woodcock have so far refused to accept the certified letters) In the meantime, the Board (Vixie et al) have tried to alter the ARIN bylaws to change the quorum requirements. But because the Board members voting on these changes weren't validly elected, their modifications are also invalid. Board members (e.g. Ray Plzak) also have a duty to object to improper acts; such as allowing invalidly elected board members to act as board members. This might be a tad legal, but NANOG has had seminars on internet law, so some basic business law is just a part of any operator's skillset. Everyone should know that membership rights to democratic participation are intangible property, and should know that taking property (including membership rights to democratic participation) on false pretenses is fraud. Threatening to take such property by force or fear is extortion. I encourage everyone to read http://www.usdoj.gov/usao/eousa/foia_reading_room/usam/title9/crm02403.htm particularly United States v. Teamsters Local 560. > and then the permanent ban : > > http://lists.arin.net/pipermail/arin-discuss/2008-June/001058.html Also based on fabrication, by a non-neutral body of Vixie/NANOG cronies. My attorney is preparing a response to this, so I can't comment very much about it. > as for banning from NANOG, there is a message, purportedly from > you : > > http://lists.arin.net/pipermail/arin-discuss/2008-February/000890.html > > contains "So Harris banned me from NANOG." . Not sure if thats the > meeting, the NANOG list, or one of the NANOG/Merit other lists. The list, I don't know if this applies to meetings. However, Jeremy Porter threatened 'Dead Anderson' with "Maybe with any luck he'll show up at the next nanog meeting and be suprised in a dark alley." So I haven't attended any meetings where there will be NANOG people present without much security. It is interesing to note however that the NANOG-affiliated ARIN AUP committee claimed in June 2008 that this threat wasn't made. > Also, in : http://www.iadl.org/nanog/nanog-story.html > > I see "So, effective May 4 2005, Harris again banned Anderson. > Although the new "reformed" rules require a limit of 6 months, > Anderson remains banned as of April 16th, 2006. It seems permanent." This refers to the NANOG reform movement in 2005. If that's really not clear from the page, I'll edit the page for clarity. > but I think that refers to another NANOG group, dnsop. DNSOP isn't a NANOG group. Its an IETF group. http://www.av8.net/IETF-watch/IESG/IESG-PR-discussion.html In fact, you might find everything on http://www.av8.net/IETF-watch interesting. Hope that clears up the facts. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Thu Oct 16 21:38:51 2008 From: dean at av8.com (Dean Anderson) Date: Thu, 16 Oct 2008 22:38:51 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: Message-ID: http://www.iadl.org/sorbs/sorbs-story.html For an account of Mr. Sullivan's assertions that IP blocks used by AV8 Internet are hijacked. I'm going to put up a page fairly soon about Mr. Vixie's changing support of SORBS. It seems that many people don't like SORBS, and to those people, Vixie says he has nothing to do with SORBS. But to others, Vixie is willing to discuss the SORBS business model '1x1'. Hmm. Sounds like that intercage discussion a bit. --Dean On Thu, 16 Oct 2008 matthew at sorbs.net wrote: > > > ----- Original Message ----- > From: "Tuc at T-B-O-H.NET" > Date: Thursday, October 16, 2008 10:39 am > Subject: Re: The DDOS problem & security BOF: Am i mistaken? > > > > > > > contains "So Harris banned me from NANOG." . Not sure if thats the > > meeting,the NANOG list, or one of the NANOG/Merit other lists. > > Also, in : > > > > http://www.iadl.org/nanog/nanog-story.html > > > > I see "So, effective May 4 2005, Harris again banned Anderson. > > Although > > the new "reformed" rules require a limit of 6 months, Anderson > > remains banned > > as of April 16th, 2006. It seems permanent." > > > > but I think that refers to another NANOG group, dnsop. > > Yeah and he still doesn't learn ;-) > > M > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Thu Oct 16 21:42:39 2008 From: dean at av8.com (Dean Anderson) Date: Thu, 16 Oct 2008 22:42:39 -0400 (EDT) Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F66BBC.5070509@internap.com> Message-ID: On Wed, 15 Oct 2008, Alan Hannan wrote: > Is truth an actual defense to your assertions? Yes. Everything in this message is true, and can be proved to a certainty. --Dean > Dean Anderson wrote: > > On Tue, 14 Oct 2008, Scott Doty wrote: > > > > > >> First, the good news: so far, the NANOG conference has been very > >> valuable and content-rich, covering a lot of issues that need to be > >> discussed. For that, I am grateful. > >> > >> But now, the bad news(?): Maybe it's just me & my paranoia, but do I > >> detect an inkling of "murk spam" going on with some presentations? > >> > > > > Judging by the email after this, the 'vendor' involves Rodney Joffe and > > probably UltraDNS. > > > > My opinion: Yes, you are being 'murk spammed' > > > > Joffe and company represent what Professor Dan Bernstein (DJBDNS) calls > > the 'Bind Company'. I think a better term is the 'BIND Cartel', since it > > is a collection of companies and individuals. > > > > Joffe, Vixie, John Levine et al own or direct Whitehat.com, a spammer. > > Remember Sanford Wallace? Wallace sent spam and offered anti-spam > > services; that was a non-starter for many. Vixie, Joffe, Levine et al > > just stole Wallace's business plan and false-teamed themselves as > > anti-spammers. What they were really doing was sending spam, and using > > the MAPS blacklist to detect and interfere with their competitors, and > > using the credentials with the anti-spam commun and inside information > > to avoid spam-traps. See http://www.iadl.org/maps/maps-story.html > > > > Joffe/Centergate/Bill Manning was the founder of UltraDNS. Manning is > > also connected to Vixie through PAIX, and to ISC employee Susan Woolf > > through ISI. > > > > Vixie, Conrad, Manning, Woodcock, Curran, Plzak, Ed Lewis, etc all > > worked together at ARIN, and have had 22 ARIN employees attend NANOG, > > including the ARIN executive secretary. ARIN is giving NANOG $50,000 > > checks, even though the Board members have undisclosed conflicts of > > interest. ARIN resource analysts have (and probably are now) attending > > NANOG. The resource analysts are the guys who make allocation decisions, > > so getting chummy with NANOG people is a conflict of interest in the > > making. So far, I've discovered two cases where ARIN has made > > allocations in 2 hours. > > > > Have they done this before? The answer is yes. The previous scam was > > AXFR-clarify draft. The draft was presented by the BIND Cartel as not > > changing the DNS protocol, but in fact did change the protocol. When Dr. > > Bernstein discovered this, and reported it, Bernstein's email was > > disrupted and censored. > > > > There are other scams that I'm writing up, but this gives you some > > inkling of what's going on now and what's gone on before. > > > > --Dean > > > > > > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Thu Oct 16 22:32:40 2008 From: dean at av8.com (Dean Anderson) Date: Thu, 16 Oct 2008 23:32:40 -0400 (EDT) Subject: Nanog History In-Reply-To: Message-ID: On Thu, 16 Oct 2008, Dean Anderson wrote: > > contains "So Harris banned me from NANOG." . Not sure if thats the > > meeting, the NANOG list, or one of the NANOG/Merit other lists. > > The list, I don't know if this applies to meetings. The Jan 2000 ban also stopped my participation in RADB. Mail to all of merit.edu was affected. I think this was to prevent me from emailing Harris' boss---she hung up on me in a phone call when I asked who her boss was. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From scott at sonic.net Thu Oct 16 23:19:47 2008 From: scott at sonic.net (Scott Doty) Date: Thu, 16 Oct 2008 21:19:47 -0700 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: References: Message-ID: <48F81263.8030702@sonic.net> Dean Anderson wrote: > On Wed, 15 Oct 2008, Alan Hannan wrote: > >> Is truth an actual defense to your assertions? >> > > Yes. Everything in this message is true, and can be proved to a > certainty. > Please, sir: I suggest that your messages might contain more that a bit of quixotism... Right or wrong, your posts are certainly not operational, and I feel partially responsible for the ensuing firegrams... So please, if you have anything further to say, either email me directly, or I suggest trying the nanog-futures list. Thank you. -Scott From karnaugh at karnaugh.za.net Thu Oct 16 23:26:18 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 17 Oct 2008 06:26:18 +0200 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: <48F81263.8030702@sonic.net> References: <48F81263.8030702@sonic.net> Message-ID: <48F813EA.3090106@karnaugh.za.net> On 2008/10/17 06:19 AM Scott Doty wrote: > So please, if you have anything further to say, either email me > directly, or I suggest trying the nanog-futures list. Thank you. > Abandon all hope ye who enter this thread. From jlloret at dcom.upv.es Fri Oct 17 04:33:51 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Fri, 17 Oct 2008 11:33:51 +0200 Subject: 1st CFP: 1st Workshop LMPCNAP in ICNS 2009 | April 21-25, 2009 - Valencia, Spain Message-ID: <1224236031.48f85bff86970@webmail.upv.es> INVITATION ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific or educational results. ================= ============== LMPCNAP 2009 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS The first International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy Program (CNAP), LMPCNAP 2009 will be held during ICNS 2009 in April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/LMPCNAP.html Submission deadline: November 1, 2008 Submissions will be peer-reviewed, published by IEEE CPS and posted in IEEE Digital Library (pending agreement). Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Cisco Networking Academy Program is an education initiative that delivers information and communication technology skills to improve student?s career around the world. Cisco Networking Academy provides online courses, interactive tools, and lab activities to help individuals develop the skills needed to fill ICT positions in virtually every type of industry. It also provides numerous programs and resources to link students and alumni with potential employers. This innovative learning program that has more than 11,000 Academies spread world wide in more than 160 Countries with more than 472,000 students registered and more than 16,000 instructors. It realizes more than 25,000 online exams per day. The number of academies in the CNAP has been growing continuously during its 12 years of existence. The CCNA course has been translated in 10 different languages. This international workshop will serve as a forum for teachers and instructors from the academia and the industry to exchange ideas. The topics could be on techniques, methodologies and applications, best practices, awareness and experiences as well as future trends and needs related to all aspects of education and technologies. Topics of interest include, but are not limited to, the following topics: New learning methodologies. Blended learning. Online laboratories. Virtual laboratories. Remote laboratories. Learning strategies to enhance online courses. Learning Content adaptation for blended learning. Learning platforms and their compatibility with cisco.netacad.net. ================= LMPCNAP 2009 General Chair Rafael Tomas, Mediterranean Cisco Academy Training Center (CATC), Spain LMPCNAP 2009 Technical Program Commitee chair Prof. Tomeu Serra, Universitat de les Illes Balears, Spain ================== -- From kisanth88 at gmail.com Fri Oct 17 04:54:10 2008 From: kisanth88 at gmail.com (John Bittenbender) Date: Fri, 17 Oct 2008 05:54:10 -0400 Subject: SMS Standards In-Reply-To: <48F7ED67.8050504@whack.org> References: <92c950310810161823w2a54e5f5he1584104772660ea@mail.gmail.com> <48F7ED67.8050504@whack.org> Message-ID: <1ebc03a70810170254n6aa8f398ve6443811a155bc67@mail.gmail.com> On Thu, Oct 16, 2008 at 9:41 PM, Bruce Pinsky wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Glen Kent wrote: >> Hi, >> >> Apologies in advance since this is off-topic. However, posting in on >> nanog since i am confident that we will have some experts who would be >> able to guide me here. >> >> I want to study the standards (RFC equivalent) for sending and >> receiving SMSs. Any ideas on what kind of protocol runs between a >> mobile phone and a SMS center (SMSC)? >> > > Wiki_Pedia is your friend http://en.wikipedia.org/wiki/Short_message_service > > The Short Message Service - Point to Point (SMS-PP) is defined in GSM > recommendation 03.40.[2] GSM 03.41 defines the Short Message Service - Cell > Broadcast (SMS-CB) which allows messages (advertising, public information, > etc.) to be broadcast to all mobile users in a specified geographical > area.[16] Messages are sent to a Short Message Service Centre (SMSC) which > provides a store-and-forward mechanism. It attempts to send messages to > their recipients. If a recipient is not reachable, the SMSC queues the > message for later retry.[17] Some SMSCs also provide a "forward and forget" > option where transmission is tried only once. Both Mobile Terminated (MT), > for messages sent to a mobile handset, and Mobile Originating (MO), for > those that are sent from the mobile handset, operations are supported. > Message delivery is best effort, so there are no guarantees that a message > will actually be delivered to its recipient and delay or complete loss of a > message is not uncommon, particularly when sending between networks. Users > may choose to request delivery reports (simply add *0# or *N# to the > beginning of your text message), which can provide positive confirmation > that the message has reached the intended recipient. > > Transmission of short messages between the SMSC and the handset is done > using the Mobile Application Part (MAP) of the SS7 protocol. Messages are > sent with the MAP mo- and mt-ForwardSM operations, whose payload length is > limited by the constraints of the signalling protocol to precisely 140 > octets (140 octets = 140 * 8 bits = 1120 bits). Short messages can be > encoded using a variety of alphabets: the default GSM 7-bit alphabet (shown > below), the 8-bit data alphabet, and the 16-bit UTF-16/UCS-2 alphabet.[18] > Depending on which alphabet the subscriber has configured in the handset, > this leads to the maximum individual Short Message sizes of 160 7-bit > characters, 140 8-bit characters, or 70 16-bit characters (including > spaces). Support of the GSM 7-bit alphabet is mandatory for GSM handsets > and network elements,[18] but characters in languages such as Arabic, > Chinese, Korean, Japanese or Cyrillic alphabet languages (e.g. Russian) > must be encoded using the 16-bit UCS-2 character encoding (see Unicode). > Routing data and other metadata is additional to the payload size. > > - -- > ========= > bep > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkj37WcACgkQE1XcgMgrtyZiVACgjSYOrHVRE9g1vufxWpa67rC6 > o8YAn1JjliEYx73fLGXbIOyeTTZtsj/S > =2vZP > -----END PGP SIGNATURE----- > Depending on what you are doing, see also SMPP protocol as much inter-carrier SMS is carried over SMPP links. Also many external content providers send SMS messages to phones via SMPP to reach the carrier (news alerts, etc). http://en.wikipedia.org/wiki/Short_message_peer-to-peer_protocol www.alvento.com/productos/sms/smpp/smpp34.pdf John B From mikie.simpson at gmail.com Fri Oct 17 06:18:55 2008 From: mikie.simpson at gmail.com (Michael Simpson) Date: Fri, 17 Oct 2008 12:18:55 +0100 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <70DEF96C-1E52-4B02-A45F-F9F6541C6488@suspicious.org> References: <48F4F7C7.1020808@sonic.net> <70DEF96C-1E52-4B02-A45F-F9F6541C6488@suspicious.org> Message-ID: <82abd3a70810170418r58b96c81uc6c366da6936d411@mail.gmail.com> On 10/16/08, Truman Boyes wrote: > It's a good point that you brought up. > > Even though we already have IPv6 P2P (Nathan's post explains this in more > detail), it would still be quite interesting to provide IPv6 as a higher > class of traffic within service provider networks. > As long as none of your ipv6 traffic transits across anything from British Telecom as it is not supported on their 21st Century Network mike From smj at merit.edu Fri Oct 17 06:52:44 2008 From: smj at merit.edu (Sue Joiner) Date: Fri, 17 Oct 2008 07:52:44 -0400 (EDT) Subject: Fwd: [NANOG-announce] New NANOG Program Committee In-Reply-To: <20081016235935.GA88829@gweep.net> Message-ID: <1268967659.2558441224244364314.JavaMail.root@crono> ----- Forwarded Message ----- From: "Joe Provo" To: nanog-announce at nanog.org Sent: Thursday, October 16, 2008 7:59:35 PM GMT -05:00 US/Canada Eastern Subject: Re: [NANOG-announce] New NANOG Program Committee On Thu, Oct 16, 2008 at 01:54:15AM -0400, Joe Provo wrote: > > In its last scheduled meeting, the NANOG Steering Committee selected > a new Programme Committee. [snip] ...and my poor editing allowed the message to go out uncorrected, inadvertently mangling the thank-you paragraph's grammar and losing the line naming three of the hard-working members of the previous PC. My apologies to them, and wish to also extend the thanks of the SC (present and past) to the outgoing PC members Nick Feamster, Kobi Hsu, and Bill Woodcock, in addition to Keith's previous mention. Mea maxima cupla. Joe Provo SC Chair -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cidr-report at potaroo.net Fri Oct 17 07:00:09 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Oct 2008 22:00:09 +1000 (EST) Subject: BGP Update Report Message-ID: <200810171200.m9HC09Yv039157@wattle.apnic.net> BGP Update Report Interval: 15-Sep-08 -to- 16-Oct-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 216771 3.0% 179.6 -- SIFY-AS-IN Sify Limited 2 - AS1803 101971 1.4% 74.2 -- ICMNET-5 - Sprint 3 - AS20255 79452 1.1% 2563.0 -- Tecnowind S.A. 4 - AS5691 78852 1.1% 6065.5 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8151 61504 0.8% 25.4 -- Uninet S.A. de C.V. 6 - AS9051 60317 0.8% 384.2 -- IDM Autonomous System 7 - AS10986 53349 0.7% 599.4 -- Intermedia Comunicaciones S.A. 8 - AS14593 52344 0.7% 52344.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 9 - AS10396 48019 0.7% 631.8 -- COQUI-NET - DATACOM CARIBE, INC. 10 - AS30890 47599 0.7% 45.3 -- EVOLVA Evolva Telecom 11 - AS4274 43374 0.6% 637.9 -- ERX-AU-NET Assumption University 12 - AS20115 40531 0.6% 17.7 -- CHARTER-NET-HKY-NC - Charter Communications 13 - AS6458 39406 0.5% 110.1 -- Telgua 14 - AS4538 39163 0.5% 7.8 -- ERX-CERNET-BKB China Education and Research Network Center 15 - AS7046 37553 0.5% 129.5 -- UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 16 - AS14846 37505 0.5% 852.4 -- CGNOGE - NBC Internet 17 - AS6629 36602 0.5% 563.1 -- NOAA-AS - NOAA 18 - AS209 36437 0.5% 11.5 -- ASN-QWEST - Qwest Communications Corporation 19 - AS17974 35134 0.5% 43.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS1295 32359 0.5% 829.7 -- BGNOGE - General Electric Company TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 52344 0.7% 52344.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 27084 0.4% 13542.0 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS32761 12590 0.2% 12590.0 -- WASSE-NYC - Wasserstein & Co. 4 - AS8266 10744 0.1% 10744.0 -- NEXUSTEL Nexus Telecommunications 5 - AS43299 10153 0.1% 10153.0 -- TELECONTACT-AS Telecontact Ltd. 6 - AS22492 25731 0.4% 8577.0 -- 7 - AS29910 6260 0.1% 6260.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 8 - AS5691 78852 1.1% 6065.5 -- MITRE-AS-5 - The MITRE Corporation 9 - AS38180 5561 0.1% 5561.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 10 - AS37026 10428 0.1% 5214.0 -- SALT-ASN 11 - AS11971 32063 0.4% 4580.4 -- PFIZERNET-GROTON - PFIZER INC. 12 - AS30969 31919 0.4% 3989.9 -- TAN-NET TransAfrica Networks 13 - AS44194 3975 0.1% 3975.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 14 - AS23082 19707 0.3% 3941.4 -- MPHI - Michigan Public Health Institute 15 - AS4557 6434 0.1% 3217.0 -- EP0-BLK-ASNBLOCK-7 - EP.NET, LLC. 16 - AS20255 79452 1.1% 2563.0 -- Tecnowind S.A. 17 - AS23917 2353 0.0% 2353.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 18 - AS41007 11206 0.1% 2241.2 -- CTCASTANA CTC ASTANA, KZ 19 - AS9747 11654 0.2% 1942.3 -- EZINTERNET-AS-AP EZInternet Pty Ltd 20 - AS39105 1932 0.0% 1932.0 -- CLASS-AS SC Class Computers And Service SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 78821 1.0% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 210.214.151.0/24 62691 0.8% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.134.222.0/24 60455 0.8% AS9583 -- SIFY-AS-IN Sify Limited 4 - 12.8.7.0/24 52344 0.7% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 5 - 221.135.80.0/24 47794 0.6% AS9583 -- SIFY-AS-IN Sify Limited 6 - 194.126.143.0/24 46265 0.6% AS9051 -- IDM Autonomous System 7 - 200.108.200.0/24 40038 0.5% AS20255 -- Tecnowind S.A. 8 - 200.108.220.0/24 39043 0.5% AS20255 -- Tecnowind S.A. 9 - 12.18.36.0/24 31769 0.4% AS11971 -- PFIZERNET-GROTON - PFIZER INC. 10 - 221.128.192.0/18 26956 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 11 - 12.2.46.0/24 25677 0.3% AS22492 -- 12 - 210.210.112.0/24 23429 0.3% AS9583 -- SIFY-AS-IN Sify Limited 13 - 196.42.0.0/20 23427 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 72.50.96.0/20 23343 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 15 - 89.4.131.0/24 15849 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 16 - 196.27.108.0/22 15839 0.2% AS30969 -- TAN-NET TransAfrica Networks 17 - 196.27.104.0/21 15819 0.2% AS30969 -- TAN-NET TransAfrica Networks 18 - 200.33.104.0/23 15804 0.2% AS21603 -- Universidad La Salle, AC 19 - 64.162.116.0/24 13892 0.2% AS5033 -- ISW - Internet Specialties West Inc. 20 - 199.117.144.0/22 13547 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 17 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Oct 2008 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200810171200.m9HC02hW039126@wattle.apnic.net> This report has been generated at Fri Oct 17 21:29:25 2008 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 10-10-08 283780 174334 11-10-08 284059 174429 12-10-08 284056 174623 13-10-08 284154 174546 14-10-08 283998 173699 15-10-08 284303 172344 16-10-08 284573 173316 17-10-08 284383 173765 AS Summary 29678 Number of ASes in routing system 12571 Number of ASes announcing only one prefix 5049 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88278016 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 17Oct08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 284300 173745 110555 38.9% All ASes AS4538 5049 879 4170 82.6% ERX-CERNET-BKB China Education and Research Network Center AS6389 4304 351 3953 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3078 1370 1708 55.5% ASN-QWEST - Qwest Communications Corporation AS6298 2011 771 1240 61.7% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS4755 1489 254 1235 82.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1680 598 1082 64.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1388 307 1081 77.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1548 483 1065 68.8% TWTC - tw telecom holdings, inc. AS22773 996 70 926 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1412 541 871 61.7% Uninet S.A. de C.V. AS11492 1212 464 748 61.7% CABLEONE - CABLE ONE AS19262 951 224 727 76.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1590 915 675 42.5% INS-AS - AT&T Data Communications Services AS6478 1318 657 661 50.2% ATT-INTERNET3 - AT&T WorldNet Services AS9498 688 70 618 89.8% BBIL-AP BHARTI Airtel Ltd. AS18101 781 194 587 75.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1034 462 572 55.3% LEVEL3 Level 3 Communications AS18566 1059 496 563 53.2% COVAD - Covad Communications Co. AS4766 918 431 487 53.1% KIXS-AS-KR Korea Telecom AS4808 631 155 476 75.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17676 522 62 460 88.1% GIGAINFRA BB TECHNOLOGY Corp. AS20115 1905 1452 453 23.8% CHARTER-NET-HKY-NC - Charter Communications AS9443 528 81 447 84.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS855 587 141 446 76.0% CANET-ASN-4 - Bell Aliant AS4134 845 403 442 52.3% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 596 155 441 74.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 564 127 437 77.5% VTR BANDA ANCHA S.A. AS24560 595 158 437 73.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1436 1003 433 30.2% ATT-INTERNET4 - AT&T WorldNet Services AS4668 686 275 411 59.9% LGNET-AS-KR LG CNS Total 41401 13549 27852 67.3% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 31.31.31.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 124.109.16.0/21 AS38137 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.25.240.0/21 AS3209 Arcor IP-Network 193.25.240.0/22 AS3209 Arcor IP-Network 193.25.244.0/23 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 193.25.247.0/24 AS3209 Arcor IP-Network 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From michael.dillon at bt.com Fri Oct 17 07:25:49 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 17 Oct 2008 13:25:49 +0100 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <82abd3a70810170418r58b96c81uc6c366da6936d411@mail.gmail.com> Message-ID: > As long as none of your ipv6 traffic transits across anything > from British Telecom as it is not supported on their 21st > Century Network > > parently-not.html> The distinction between supported, and unsupported is that when something is supported by a company it means that the company has explicitly agreed to provide the supported feature and is getting paid for it. This is marketing/sales lingo. Given that NANOG is a technical forum, I don't know why you bring this up. Clearly we do technically support IPv6 on 21CN because we have customers using it. That's how we discovered a Cisco bug that causes certain IPv6 packets to be mangled, and like all bugs that ISPs find in vendor equipment, it is reported and will eventually get fixed. This illustrates why it is important to deploy IPv6 now, even if it is only for technically clued-in customers who will participate in bug finding, etc. There are a lot of technologies involved here, and clearly we need to exercise some of the access technologies like L2TP a lot more to shake out the bugs and get them fixed. That isn't something that any one ISP can do on their own. It requires every ISP to take IPv6 seriously enough that they deploy it in their labs and offices, then report every bug and issue to vendors asking them to make sure these things are fixed before the end of 2010. This is how the IPv4 Internet managed to scale through a period of 1500% annual growth. It was the cooperation between ISPs, vendors and researchers, mediated by NANOG as a forum, that enabled the Internet to become as important as it is today. --Michael Dillon From cscora at apnic.net Fri Oct 17 13:10:14 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Oct 2008 04:10:14 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200810171810.m9HIAExZ010919@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Oct, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 271514 Prefixes after maximum aggregation: 130898 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131783 Total ASes present in the Internet Routing Table: 29518 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25695 Origin ASes announcing only one prefix: 12506 Transit ASes present in the Internet Routing Table: 3823 Transit-only ASes present in the Internet Routing Table: 81 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 104 Max AS path prepend of ASN (43413) 100 Prefixes from unregistered ASNs in the Routing Table: 562 Unregistered ASNs in the Routing Table: 201 Number of 32-bit ASNs allocated by the RIRs: 61 Prefixes from 32-bit ASNs in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 752 Number of addresses announced to Internet: 1923950912 Equivalent to 114 /8s, 173 /16s and 41 /24s Percentage of available address space announced: 51.9 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.9 Total number of prefixes smaller than registry allocations: 133641 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62245 Total APNIC prefixes after maximum aggregation: 23219 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59212 Unique aggregates announced from the APNIC address blocks: 26686 APNIC Region origin ASes present in the Internet Routing Table: 3404 APNIC Prefixes per ASN: 17.39 APNIC Region origin ASes announcing only one prefix: 906 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 379108256 Equivalent to 22 /8s, 152 /16s and 187 /24s Percentage of available APNIC address space announced: 80.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/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, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123346 Total ARIN prefixes after maximum aggregation: 64844 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92672 Unique aggregates announced from the ARIN address blocks: 35033 ARIN Region origin ASes present in the Internet Routing Table: 12538 ARIN Prefixes per ASN: 7.39 ARIN Region origin ASes announcing only one prefix: 4859 ARIN Region transit ASes present in the Internet Routing Table: 1195 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 363895840 Equivalent to 21 /8s, 176 /16s and 156 /24s Percentage of available ARIN address space announced: 74.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/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, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 59495 Total RIPE prefixes after maximum aggregation: 35663 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 54642 Unique aggregates announced from the RIPE address blocks: 36307 RIPE Region origin ASes present in the Internet Routing Table: 12030 RIPE Prefixes per ASN: 4.54 RIPE Region origin ASes announcing only one prefix: 6326 RIPE Region transit ASes present in the Internet Routing Table: 1824 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 104 Number of RIPE addresses announced to Internet: 375674272 Equivalent to 22 /8s, 100 /16s and 85 /24s Percentage of available RIPE address space announced: 86.1 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-49151 RIPE Address Blocks 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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 21833 Total LACNIC prefixes after maximum aggregation: 5417 LACNIC Deaggregation factor: 4.03 Prefixes being announced from the LACNIC address blocks: 19891 Unique aggregates announced from the LACNIC address blocks: 11115 LACNIC Region origin ASes present in the Internet Routing Table: 1014 LACNIC Prefixes per ASN: 19.62 LACNIC Region origin ASes announcing only one prefix: 334 LACNIC Region transit ASes present in the Internet Routing Table: 171 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 57394944 Equivalent to 3 /8s, 107 /16s and 199 /24s Percentage of available LACNIC address space announced: 57.0 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4036 Total AfriNIC prefixes after maximum aggregation: 1316 AfriNIC Deaggregation factor: 3.07 Prefixes being announced from the AfriNIC address blocks: 4290 Unique aggregates announced from the AfriNIC address blocks: 2100 AfriNIC Region origin ASes present in the Internet Routing Table: 260 AfriNIC Prefixes per ASN: 16.50 AfriNIC Region origin ASes announcing only one prefix: 81 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12856576 Equivalent to 0 /8s, 196 /16s and 45 /24s Percentage of available AfriNIC address space announced: 38.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1483 518 196 TATA Communications formerly 17488 1388 96 103 Hathway IP Over Cable Interne 9583 1104 86 474 Sify Limited 4766 879 6407 360 Korea Telecom (KIX) 4134 844 13647 345 CHINANET-BACKBONE 23577 811 34 693 Korea Telecom (ATM-MPLS) 18101 781 161 65 Reliance Infocom Ltd Internet 4780 717 355 62 Digital United Inc. 9498 688 295 53 BHARTI BT INTERNET LTD. 4808 627 1164 142 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4301 3416 339 bellsouth.net, inc. 209 3075 4033 623 Qwest 6298 2010 319 714 Cox Communicatons 20115 1925 1426 718 Charter Communications 1785 1678 717 155 PaeTec Communications, Inc. 2386 1589 699 896 AT&T Data Communications Serv 4323 1550 1083 373 Time Warner Telecom 7018 1413 5859 984 AT&T WorldNet Services 6478 1318 273 198 AT&T Worldnet Services 11492 1212 152 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 434 1777 385 TDC Tele Danmark 30890 348 94 188 SC Kappa Invexim SRL 3215 327 2756 106 France Telecom Transpac 3301 327 1428 298 TeliaNet Sweden 3320 326 7063 275 Deutsche Telekom AG 8866 326 111 23 Bulgarian Telecommunication C 5462 301 794 27 Telewest Broadband 25233 295 45 27 Awalnet 8452 294 188 11 TEDATA 8551 287 270 37 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1411 2849 221 UniNet S.A. de C.V. 11830 669 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 10620 505 122 61 TVCABLE BOGOTA 7303 493 242 69 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 419 85 48 ENTEL CHILE S.A. 11172 405 118 72 Servicios Alestra S.A de C.V 28573 349 460 23 NET Servicos de Comunicao S.A 14117 343 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 544 72 40 LINKdotNET AS number 3741 269 856 225 The Internet Solution 2018 233 215 139 Tertiary Education Network 20858 213 34 3 EgyNet 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 124 8 20 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 115 555 65 Telkom SA Ltd 29571 112 13 9 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4301 3416 339 bellsouth.net, inc. 209 3075 4033 623 Qwest 6298 2010 319 714 Cox Communicatons 20115 1925 1426 718 Charter Communications 1785 1678 717 155 PaeTec Communications, Inc. 2386 1589 699 896 AT&T Data Communications Serv 4323 1550 1083 373 Time Warner Telecom 4755 1483 518 196 TATA Communications formerly 7018 1413 5859 984 AT&T WorldNet Services 8151 1411 2849 221 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3075 2452 Qwest 1785 1678 1523 PaeTec Communications, Inc. 6298 2010 1296 Cox Communicatons 4755 1483 1287 TATA Communications formerly 17488 1388 1285 Hathway IP Over Cable Interne 20115 1925 1207 Charter Communications 11492 1212 1201 Cable One 8151 1411 1190 UniNet S.A. de C.V. 4323 1550 1177 Time Warner Telecom 6478 1318 1120 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. Complete listing at http://thyme.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:9 /10:17 /11:46 /12:148 /13:298 /14:536 /15:1066 /16:10125 /17:4399 /18:7590 /19:16364 /20:19244 /21:18707 /22:23677 /23:24603 /24:141889 /25:820 /26:999 /27:851 /28:90 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2847 4301 bellsouth.net, inc. 6298 1984 2010 Cox Communicatons 209 1796 3075 Qwest 2386 1268 1589 AT&T Data Communications Serv 11492 1188 1212 Cable One 17488 1179 1388 Hathway IP Over Cable Interne 1785 1139 1678 PaeTec Communications, Inc. 6478 1104 1318 AT&T Worldnet Services 18566 1040 1059 Covad Communications 20115 1033 1925 Charter Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:141 12:2186 13:2 15:22 16:3 17:5 18:13 20:38 24:1148 31:1 32:58 38:511 40:92 41:708 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:521 59:530 60:452 61:983 62:1092 63:2037 64:3240 65:2429 66:3519 67:1286 68:805 69:2346 70:861 71:276 72:2056 73:7 74:1254 75:213 76:279 77:924 78:810 79:279 80:906 81:864 82:587 83:402 84:592 85:1036 86:501 87:706 88:325 89:1380 90:23 91:1602 92:270 93:928 94:258 95:3 96:80 97:102 98:350 99:11 113:15 114:110 115:122 116:985 117:378 118:240 119:523 120:93 121:604 122:852 123:446 124:862 125:1195 128:353 129:207 130:135 131:417 132:72 133:9 134:185 135:31 136:223 137:98 138:144 139:81 140:433 141:106 142:401 143:291 144:326 145:51 146:375 147:153 148:530 149:207 150:128 151:208 152:149 153:135 154:10 155:278 156:173 157:301 158:170 159:305 160:275 161:139 162:255 163:133 164:520 165:511 166:363 167:338 168:644 169:145 170:448 171:33 172:10 173:54 187:16 188:1 189:292 190:2317 192:5750 193:4147 194:3260 195:2617 196:1002 198:3735 199:3299 200:5552 201:1424 202:7820 203:8040 204:3925 205:2164 206:2293 207:2764 208:3708 209:3440 210:2566 211:1102 212:1514 213:1614 214:169 215:50 216:4419 217:1244 218:349 219:439 220:1053 221:413 222:298 End of report From glen.kent at gmail.com Fri Oct 17 18:48:03 2008 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 18 Oct 2008 05:18:03 +0530 Subject: SMS Standards In-Reply-To: <48F7ED67.8050504@whack.org> References: <92c950310810161823w2a54e5f5he1584104772660ea@mail.gmail.com> <48F7ED67.8050504@whack.org> Message-ID: <92c950310810171648s3c0a493em84dd161be76aa0a@mail.gmail.com> > Message delivery is best effort, so there are no guarantees that a message > will actually be delivered to its recipient and delay or complete loss of a > message is not uncommon, particularly when sending between networks. Users > may choose to request delivery reports (simply add *0# or *N# to the > beginning of your text message), which can provide positive confirmation > that the message has reached the intended recipient. I tried adding a *0# to my SMS and i didnt receive any confirmation .. I particularly interested in knowing the frame encoding thats done to send a SMS. What are the control words that are sent along with an SMS, etc. What does one need to do if a standard is to be proposed. Is it like IETF where a draft is submitted, or is it something else. Any pointers to the appropriate mailing list? Regards, Glen From nanog at daork.net Fri Oct 17 19:23:25 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 18 Oct 2008 13:23:25 +1300 Subject: spurring transition to ipv6 -- make it faster In-Reply-To: <82abd3a70810170418r58b96c81uc6c366da6936d411@mail.gmail.com> References: <48F4F7C7.1020808@sonic.net> <70DEF96C-1E52-4B02-A45F-F9F6541C6488@suspicious.org> <82abd3a70810170418r58b96c81uc6c366da6936d411@mail.gmail.com> Message-ID: On 18/10/2008, at 12:18 AM, Michael Simpson wrote: > On 10/16/08, Truman Boyes wrote: >> It's a good point that you brought up. >> >> Even though we already have IPv6 P2P (Nathan's post explains this >> in more >> detail), it would still be quite interesting to provide IPv6 as a >> higher >> class of traffic within service provider networks. >> > > As long as none of your ipv6 traffic transits across anything from > British Telecom > as it is not supported on their 21st Century Network > > > Yeah, except Teredo and 6to4 solve that problem for us today and are enabled by default on Vista and are used by p2p applications. Next. -- Nathan Ward From pfunix at gmail.com Sat Oct 18 09:35:34 2008 From: pfunix at gmail.com (Beavis) Date: Sat, 18 Oct 2008 08:35:34 -0600 Subject: the attack continues.. Message-ID: Hello Lists, I'm still getting attacked and most of the IP's i got have been reported. and just this morning it looks as if someone is testing my network. and sending out short TCP_SESSION requests. now i may be paranoid but this past few days have been hell.. just want to know if the folks from these ip's can help me out. Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start Time,Extra Info 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 First 3 IP's come from AOL, I'll try to see if I can get their attention. Last IP is from a Wildblue Communications WBC-39. I wanted to see if it's possible to get a sample of the "bots" that their using against me. I know... it's a long shot but any help will be greatly appreciated. thanks, John Lopez From jay at west.net Sat Oct 18 10:24:25 2008 From: jay at west.net (Jay Hennigan) Date: Sat, 18 Oct 2008 08:24:25 -0700 Subject: the attack continues.. In-Reply-To: References: Message-ID: <48F9FFA9.8070906@west.net> Beavis wrote: > Hello Lists, > > I'm still getting attacked and most of the IP's i got have been > reported. and just this morning it looks as if someone is testing my > network. and sending out short TCP_SESSION requests. now i may be > paranoid but this past few days have been hell.. just want to know if > the folks from these ip's can help me out. > > Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start > Time,Extra Info > 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 > 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 > 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 > 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 > > First 3 IP's come from AOL, I'll try to see if I can get their attention. > > Last IP is from a Wildblue Communications WBC-39. "Beavis", you're running a web server on 200.0.179.73, some sort of gambling site. Those who operate web servers generally expect traffic to TCP port 80. If you're not aware that you have a web server running, then it is most likely your machine that is infected with a bot. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From frnkblk at iname.com Sat Oct 18 11:16:46 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 18 Oct 2008 11:16:46 -0500 Subject: the attack continues.. In-Reply-To: <48F9FFA9.8070906@west.net> References: <48F9FFA9.8070906@west.net> Message-ID: The website is "http://www.betmania.com/" and when I try to connect to it I get "Database Error: Unable to connect to the database:Could not connect to MySQL". It's not unusual for betting sites to be DDoSed for ransom. Frank -----Original Message----- From: Jay Hennigan [mailto:jay at west.net] Sent: Saturday, October 18, 2008 10:24 AM To: NANOG list Subject: Re: the attack continues.. Beavis wrote: > Hello Lists, > > I'm still getting attacked and most of the IP's i got have been > reported. and just this morning it looks as if someone is testing my > network. and sending out short TCP_SESSION requests. now i may be > paranoid but this past few days have been hell.. just want to know if > the folks from these ip's can help me out. > > Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start > Time,Extra Info > 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 > 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 > 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 > 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 > 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 > > First 3 IP's come from AOL, I'll try to see if I can get their attention. > > Last IP is from a Wildblue Communications WBC-39. "Beavis", you're running a web server on 200.0.179.73, some sort of gambling site. Those who operate web servers generally expect traffic to TCP port 80. If you're not aware that you have a web server running, then it is most likely your machine that is infected with a bot. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From bjorn at mork.no Sat Oct 18 13:04:38 2008 From: bjorn at mork.no (=?iso-8859-1?Q?Bj=F8rn_Mork?=) Date: Sat, 18 Oct 2008 20:04:38 +0200 Subject: SMS Standards In-Reply-To: <92c950310810171648s3c0a493em84dd161be76aa0a@mail.gmail.com> (Glen Kent's message of "Sat, 18 Oct 2008 05:18:03 +0530") References: <92c950310810161823w2a54e5f5he1584104772660ea@mail.gmail.com> <48F7ED67.8050504@whack.org> <92c950310810171648s3c0a493em84dd161be76aa0a@mail.gmail.com> Message-ID: <87fxmtsrt5.fsf@obelix.mork.no> "Glen Kent" writes: > I particularly interested in knowing the frame encoding thats done to > send a SMS. What are the control words that are sent along with an > SMS, etc. What does one need to do if a standard is to be proposed. Is > it like IETF where a draft is submitted, or is it something else. Please see http://www.3gpp.org/. This may be a starting point: http://www.3gpp.org/ftp/Specs/html-info/0340.htm Bj?rn From morrowc.lists at gmail.com Sat Oct 18 13:50:41 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 18 Oct 2008 14:50:41 -0400 Subject: the attack continues.. In-Reply-To: References: <48F9FFA9.8070906@west.net> Message-ID: <75cb24520810181150v2e86782bu5fa910cfb1f910a5@mail.gmail.com> On Sat, Oct 18, 2008 at 12:16 PM, Frank Bulk wrote: > The website is "http://www.betmania.com/" and when I try to connect to it I > get "Database Error: Unable to connect to the database:Could not connect to > MySQL". > > It's not unusual for betting sites to be DDoSed for ransom. > GW10.MIA4.ALTER.NET (152.63.81.53) 54.482 ms 54.665 ms 8 (63.65.190.126) 54.949 ms 54.774 ms 55.035 ms 9 s-1-0-0-nmi-core01.nwnnetwork.net (63.245.5.65) 58.575 ms 56.288 ms 58.745 ms 10 ge-2-0-nmi-edge03.nwnnetwork.net (63.245.5.21) I would also venture to guess that vbz/uunet would be willing to help if the site's provider (nwnnetwork.net) would call and ask for support... > Frank > > -----Original Message----- > From: Jay Hennigan [mailto:jay at west.net] > Sent: Saturday, October 18, 2008 10:24 AM > To: NANOG list > Subject: Re: the attack continues.. > > Beavis wrote: >> Hello Lists, >> >> I'm still getting attacked and most of the IP's i got have been >> reported. and just this morning it looks as if someone is testing my >> network. and sending out short TCP_SESSION requests. now i may be >> paranoid but this past few days have been hell.. just want to know if >> the folks from these ip's can help me out. >> >> Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start >> Time,Extra Info >> 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 >> 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >> 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >> 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >> >> First 3 IP's come from AOL, I'll try to see if I can get their attention. >> >> Last IP is from a Wildblue Communications WBC-39. > > "Beavis", you're running a web server on 200.0.179.73, some sort of > gambling site. Those who operate web servers generally expect traffic > to TCP port 80. If you're not aware that you have a web server running, > then it is most likely your machine that is infected with a bot. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > > > From j at jcoley.net Sat Oct 18 13:59:56 2008 From: j at jcoley.net (Jay Coley) Date: Sat, 18 Oct 2008 19:59:56 +0100 Subject: the attack continues.. In-Reply-To: References: <48F9FFA9.8070906@west.net> Message-ID: <48FA322C.5030709@jcoley.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Bulk wrote: > The website is "http://www.betmania.com/" and when I try to connect to it I > get "Database Error: Unable to connect to the database:Could not connect to > MySQL". > > It's not unusual for betting sites to be DDoSed for ransom. Also competition (rival companies) based attacks are extremely common in the gambling/betting industry as well these days. Are you running any special promotions at the same time as your competition? - --J > > Frank > > -----Original Message----- > From: Jay Hennigan [mailto:jay at west.net] > Sent: Saturday, October 18, 2008 10:24 AM > To: NANOG list > Subject: Re: the attack continues.. > > Beavis wrote: >> Hello Lists, >> >> I'm still getting attacked and most of the IP's i got have been >> reported. and just this morning it looks as if someone is testing my >> network. and sending out short TCP_SESSION requests. now i may be >> paranoid but this past few days have been hell.. just want to know if >> the folks from these ip's can help me out. >> >> Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start >> Time,Extra Info >> 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 >> 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >> 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >> 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 >> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >> >> First 3 IP's come from AOL, I'll try to see if I can get their attention. >> >> Last IP is from a Wildblue Communications WBC-39. > > "Beavis", you're running a web server on 200.0.179.73, some sort of > gambling site. Those who operate web servers generally expect traffic > to TCP port 80. If you're not aware that you have a web server running, > then it is most likely your machine that is infected with a bot. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj6MisACgkQETh+0NgvOtFHnwCfRYCU4VwNmQRXABtgem4wmWhX gD8AnRSxyfM67NJKGiYVn1MNYNQ5eaSO =J0JL -----END PGP SIGNATURE----- From pfunix at gmail.com Sat Oct 18 14:52:26 2008 From: pfunix at gmail.com (Beavis) Date: Sat, 18 Oct 2008 13:52:26 -0600 Subject: the attack continues.. In-Reply-To: <48FA322C.5030709@jcoley.net> References: <48F9FFA9.8070906@west.net> <48FA322C.5030709@jcoley.net> Message-ID: I'm hosting the company's site and we're not running any type of promotions other than the ones that we have. this is a typical scenario for sites that host these type of content to get attacked. If only i can get through one of those IP's and get the program that's running on them (bot) that will give me a clue where it goes. Attacker IP's these guys are just persistent they are trying to hit port 80 on a dns box. 92.124.174.10 89.252.28.60 91.124.110.98 98.25.64.170 92.112.229.94 75.186.69.225 89.113.48.227 87.103.174.101 84.47.161.244 89.169.111.90 92.112.145.158 85.141.238.233 91.202.109.72 89.222.217.116 193.109.241.45 212.192.251.11 213.252.64.74 91.200.8.6 92.113.10.101 200.11.153.142 80.55.213.118 200.43.3.153 On Sat, Oct 18, 2008 at 12:59 PM, Jay Coley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Frank Bulk wrote: >> The website is "http://www.betmania.com/" and when I try to connect to it I >> get "Database Error: Unable to connect to the database:Could not connect to >> MySQL". >> >> It's not unusual for betting sites to be DDoSed for ransom. > > Also competition (rival companies) based attacks are extremely common in > the gambling/betting industry as well these days. > > Are you running any special promotions at the same time as your competition? > > - --J > > >> >> Frank >> >> -----Original Message----- >> From: Jay Hennigan [mailto:jay at west.net] >> Sent: Saturday, October 18, 2008 10:24 AM >> To: NANOG list >> Subject: Re: the attack continues.. >> >> Beavis wrote: >>> Hello Lists, >>> >>> I'm still getting attacked and most of the IP's i got have been >>> reported. and just this morning it looks as if someone is testing my >>> network. and sending out short TCP_SESSION requests. now i may be >>> paranoid but this past few days have been hell.. just want to know if >>> the folks from these ip's can help me out. >>> >>> Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start >>> Time,Extra Info >>> 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 >>> 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 >>> 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 >>> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >>> 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 >>> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >>> 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 >>> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >>> >>> First 3 IP's come from AOL, I'll try to see if I can get their attention. >>> >>> Last IP is from a Wildblue Communications WBC-39. >> >> "Beavis", you're running a web server on 200.0.179.73, some sort of >> gambling site. Those who operate web servers generally expect traffic >> to TCP port 80. If you're not aware that you have a web server running, >> then it is most likely your machine that is infected with a bot. >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> >> >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkj6MisACgkQETh+0NgvOtFHnwCfRYCU4VwNmQRXABtgem4wmWhX > gD8AnRSxyfM67NJKGiYVn1MNYNQ5eaSO > =J0JL > -----END PGP SIGNATURE----- > > From pfunix at gmail.com Sat Oct 18 14:58:57 2008 From: pfunix at gmail.com (Beavis) Date: Sat, 18 Oct 2008 13:58:57 -0600 Subject: the attack continues.. In-Reply-To: References: <48F9FFA9.8070906@west.net> <48FA322C.5030709@jcoley.net> Message-ID: overall .. sorry list for putting out such a noise. -John On Sat, Oct 18, 2008 at 1:52 PM, Beavis wrote: > I'm hosting the company's site and we're not running any type of > promotions other than the ones that we have. this is a typical > scenario for sites that host these type of content to get attacked. > > If only i can get through one of those IP's and get the program that's > running on them (bot) that will give me a clue where it goes. > > Attacker IP's these guys are just persistent they are trying to hit > port 80 on a dns box. > > 92.124.174.10 > 89.252.28.60 > 91.124.110.98 > 98.25.64.170 > 92.112.229.94 > 75.186.69.225 > 89.113.48.227 > 87.103.174.101 > 84.47.161.244 > 89.169.111.90 > 92.112.145.158 > 85.141.238.233 > 91.202.109.72 > 89.222.217.116 > 193.109.241.45 > 212.192.251.11 > 213.252.64.74 > 91.200.8.6 > 92.113.10.101 > 200.11.153.142 > 80.55.213.118 > 200.43.3.153 > > > On Sat, Oct 18, 2008 at 12:59 PM, Jay Coley wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Frank Bulk wrote: >>> The website is "http://www.betmania.com/" and when I try to connect to it I >>> get "Database Error: Unable to connect to the database:Could not connect to >>> MySQL". >>> >>> It's not unusual for betting sites to be DDoSed for ransom. >> >> Also competition (rival companies) based attacks are extremely common in >> the gambling/betting industry as well these days. >> >> Are you running any special promotions at the same time as your competition? >> >> - --J >> >> >>> >>> Frank >>> >>> -----Original Message----- >>> From: Jay Hennigan [mailto:jay at west.net] >>> Sent: Saturday, October 18, 2008 10:24 AM >>> To: NANOG list >>> Subject: Re: the attack continues.. >>> >>> Beavis wrote: >>>> Hello Lists, >>>> >>>> I'm still getting attacked and most of the IP's i got have been >>>> reported. and just this morning it looks as if someone is testing my >>>> network. and sending out short TCP_SESSION requests. now i may be >>>> paranoid but this past few days have been hell.. just want to know if >>>> the folks from these ip's can help me out. >>>> >>>> Attacker IP,Attacker Port,Victim IP,Victim Port,Attack Type,Start >>>> Time,Extra Info >>>> 205.188.116.7,47198,200.0.179.73,80,TCP_SESSION,2008-10-18 >>>> 14:20:48,Filtered IP: Dropped packets: 3 Dropped bytes: 156 >>>> 205.188.117.134,45379,200.0.179.73,80,TCP_SESSION,2008-10-18 >>>> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >>>> 205.188.117.137,42257,200.0.179.73,80,TCP_SESSION,2008-10-18 >>>> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >>>> 75.105.128.38,4092,200.0.179.73,80,TCP_SESSION,2008-10-18 >>>> 14:20:48,Filtered IP: Dropped packets: 0 Dropped bytes: 0 >>>> >>>> First 3 IP's come from AOL, I'll try to see if I can get their attention. >>>> >>>> Last IP is from a Wildblue Communications WBC-39. >>> >>> "Beavis", you're running a web server on 200.0.179.73, some sort of >>> gambling site. Those who operate web servers generally expect traffic >>> to TCP port 80. If you're not aware that you have a web server running, >>> then it is most likely your machine that is infected with a bot. >>> >>> -- >>> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >>> Impulse Internet Service - http://www.impulse.net/ >>> Your local telephone and internet company - 805 884-6323 - WB6RDV >>> >>> >>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkj6MisACgkQETh+0NgvOtFHnwCfRYCU4VwNmQRXABtgem4wmWhX >> gD8AnRSxyfM67NJKGiYVn1MNYNQ5eaSO >> =J0JL >> -----END PGP SIGNATURE----- >> >> > From fergdawgster at gmail.com Sat Oct 18 15:08:46 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 18 Oct 2008 13:08:46 -0700 Subject: the attack continues.. In-Reply-To: References: <48F9FFA9.8070906@west.net> <48FA322C.5030709@jcoley.net> Message-ID: <6cd462c00810181308p15a42290x8e8c1af115b432a4@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Oct 18, 2008 at 12:52 PM, Beavis wrote: > I'm hosting the company's site and we're not running any type of > promotions other than the ones that we have. this is a typical > scenario for sites that host these type of content to get attacked. > > If only i can get through one of those IP's and get the program that's > running on them (bot) that will give me a clue where it goes. > > Attacker IP's these guys are just persistent they are trying to hit > port 80 on a dns box. > > 92.124.174.10 > 89.252.28.60 > 91.124.110.98 > 98.25.64.170 > 92.112.229.94 > 75.186.69.225 > 89.113.48.227 > 87.103.174.101 > 84.47.161.244 > 89.169.111.90 > 92.112.145.158 > 85.141.238.233 > 91.202.109.72 > 89.222.217.116 > 193.109.241.45 > 212.192.251.11 > 213.252.64.74 > 91.200.8.6 > 92.113.10.101 > 200.11.153.142 > 80.55.213.118 > 200.43.3.153 > Well, good luck with all that -- it would appear that all of the hosts attacking you are botnet'ed residential broadband machines: 92.124.174.10 -PTR-> host-92-124-174-10.pppoe.omsknet.ru 89.252.28.60 -PTR-> NXDOMAIN 91.124.110.98 -PTR-> 98-110-124-91.pool.ukrtel.net 98.25.64.170 -PTR-> cpe-098-025-064-170.sc.res.rr.com 92.112.229.94 -PTR-> 94-229-112-92.pool.ukrtel.net 75.186.69.225 -PTR-> cpe-75-186-69-225.cinci.res.rr.com 89.113.48.227 -PTR-> 89-113-48-227.nat.dsl.orel.ru 87.103.174.101 -PTR-> 87-103-174-101.pppoe.irtel.ru 84.47.161.244 -PTR-> 84-47-161-244.apmt.ru [...] - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI+kJBq1pz9mNUZTMRApbGAJ9WamkW06pTb+SpWUn0rirpQZf/KgCg1APq LPs4/rDH8wPmAk6bvl+FpI4= =N1VC -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From alif.terranson at gmail.com Sat Oct 18 18:50:23 2008 From: alif.terranson at gmail.com (J.A. Terranson) Date: Sat, 18 Oct 2008 18:50:23 -0500 Subject: Nanog History In-Reply-To: References: Message-ID: On Thu, Oct 16, 2008 at 10:32 PM, Dean Anderson wrote: > On Thu, 16 Oct 2008, Dean Anderson wrote: >> > contains "So Harris banned me from NANOG." . Not sure if thats the >> > meeting, the NANOG list, or one of the NANOG/Merit other lists. >> >> The list, I don't know if this applies to meetings. > > The Jan 2000 ban also stopped my participation in RADB. Mail to all of > merit.edu was affected. I think this was to prevent me from emailing > Harris' boss---she hung up on me in a phone call when I asked who her > boss was. > > --Dean Well Dean, considering that you are a pathological liar (as well as an IP theif), I can certainly understand people being defensive around you. As to your non-participation in NANOG and related flora, remember that the Innernets are a *cooperative* being. Encouraging the participation of loose screws, cerebral derelicts, and other assorted net.trash such as yourself can only *improve* the quality of the venture. //Alif -- "Never belong to any party, always oppose privileged classes and public plunderers, never lack sympathy with the poor, always remain devoted to the public welfare, never be satisfied with merely printing news, always be drastically independent, never be afraid to attack wrong, whether by predatory plutocracy or predatory poverty." Joseph Pulitzer 1907 Speech From trelane at trelane.net Sun Oct 19 19:29:13 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 19 Oct 2008 20:29:13 -0400 Subject: The DDOS problem & security BOF: Am i mistaken? In-Reply-To: References: Message-ID: <48FBD0D9.1080206@trelane.net> Dean Anderson wrote: > snip Wow, just Wow. They must have let you out early. Andrew From marks at bit.nl Mon Oct 20 00:53:20 2008 From: marks at bit.nl (Mark Schouten) Date: Mon, 20 Oct 2008 07:53:20 +0200 Subject: virbl.bit.nl, A list of virussending IP's In-Reply-To: <1221831113.21191.100.camel@highway> References: <1221831113.21191.100.camel@highway> Message-ID: <1224482000.7093.6.camel@schouten-laptop> On Fri, 2008-09-19 at 15:31 +0200, Mark Schouten wrote: > AS Administrators can login at [2]. A password will be emailed to a > address you select. We look for addresses in the whois-info for your AS. > You can see evidence, suspend hosts from the list and see stats about > your AS. > > We are working on notifications, which will also be configurable in the > login-interface. Notifications are now configurable. We can email you every 12 hours with listed IP's in your network. > [2] https://virbl.bit.nl/login/ Regards, -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fergdawgster at gmail.com Mon Oct 20 02:03:59 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 20 Oct 2008 00:03:59 -0700 Subject: In Memoriam: Abha Ahuja Message-ID: <6cd462c00810200003m5b5ba2f6neb90388219624305@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On October 20, 2001, we lost a dear friend and colleague. We miss you, Abha. http://fergdawg.blogspot.com/2008/10/in-memoriam-abha-ahuja.html And of course: http://www.nanog.org/scholarships/abha.php - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI/C1Qq1pz9mNUZTMRAucmAJ9SltkxADgCmC3fu9vTatb7QqeZNgCgiLPw 9oIJ6crCAXiJ1WGtUB9SKmQ= =FCpY -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From ops.lists at gmail.com Tue Oct 21 20:25:10 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 22 Oct 2008 06:55:10 +0530 Subject: Kaminsky redux - libspf2 dns parsing bug Message-ID: For the "mailops is not operational" folks.. it involves parsing dns txt records, so .. well, please grit your teeth and read on, this gets interesting Well, we discarded spf back in 2005 so we arent in any particular danger, but for those few of y'all still deploying and checking spf .. please upgrade asap. srs http://www.doxpara.com/?p=1263 I really need to learn to leave DNS alone :) DNS TXT Record Parsing Bug in LibSPF2 A relatively common bug parsing TXT records delivered over DNS, dating at least back to 2002 in Sendmail 8.2.0 and almost certainly much earlier, has been found in LibSPF2, a library frequently used to retrieve SPF (Sender Policy Framework) records and apply policy according to those records. This implementation flaw allows for relatively flexible memory corruption, and should thus be treated as a path to anonymous remote code execution. Of particular note is that the remote code execution would occur on servers specifically designed to receive E-Mail from the Internet, and that these systems may in fact be high volume mail exchangers. This creates privacy implications. It is also the case that a corrupted email server is a useful "jumping off" point for attackers to corrupt desktop machines, since attachments can be corrupted with malware while the containing message stays intact. So there are internal security implications as well, above and beyond corruption of the mail server on the DMZ. Apparently LibSPF2 is actually used to secure quite a bit of mail traffic ? there's a lot of SPAM out there. Fix is out, see http://www.libspf2.org/index.html or your friendly neighborhood distro. Thanks to Shevek, CERT (VU#183657), Ken Simpson of MailChannels, Andre Engel, Scott Kitterman, and Hannah Schroeter for their help with this. From David.Malone at nuim.ie Wed Oct 22 04:53:35 2008 From: David.Malone at nuim.ie (David Malone) Date: Wed, 22 Oct 2008 10:53:35 +0100 Subject: IPv6 Wow In-Reply-To: References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> Message-ID: <20081022095335.GA91426@kac.cnri.dit.ie> > If someone has some nice code that'll take a list of IPv6 addresses and > break it down to geographical distribution of native/teredo/6to4, I'd be > more than happy to run it on my data. I have some code for doing breakdowns of IPv6 addresses which runs on web logs. It was written for my own consumption, but I've put some instructions on how to use it here: http://www.maths.tcd.ie/~dwmalone/v6classify/instructions.html If anyone is interested in playing with it, I'd be interested to see how it does. David. From ernesto at cs.fiu.edu Wed Oct 22 14:16:35 2008 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 22 Oct 2008 15:16:35 -0400 Subject: UDRP and ICANN / Input Requested Message-ID: Hi folks, So I'm a network engineer and a law student and have decided to write a short note for one of our International Law classes based on UDRP and ICANN issues. I'd like to request input from the community as to what they see as the advantages and disadvantages for the UDRP process the way ICANN has it structured now. Any comments on how to improve the system are greatly appreciated. You can contact post to the list or contact me off list, either way my information is below. Ernesto M. Rubi Network Engineer - AMPATH Florida International University J.D. Candidate, 2010 Patent Agent - USPTO Reg. 63,074 FIU College of Law Email: ernesto at cs.fiu.edu From charles at thewybles.com Wed Oct 22 14:20:00 2008 From: charles at thewybles.com (Charles Wyble) Date: Wed, 22 Oct 2008 12:20:00 -0700 Subject: Telstra NOC Message-ID: <48FF7CE0.6060106@thewybles.com> http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg From nanog at headcandy.org Wed Oct 22 14:28:57 2008 From: nanog at headcandy.org (Steve Church) Date: Wed, 22 Oct 2008 15:28:57 -0400 Subject: Telstra NOC In-Reply-To: <48FF7CE0.6060106@thewybles.com> References: <48FF7CE0.6060106@thewybles.com> Message-ID: Who's the hot chick in the bottom right corner? S On Wed, Oct 22, 2008 at 3:20 PM, Charles Wyble wrote: > > http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg > > > From randy at psg.com Wed Oct 22 14:29:00 2008 From: randy at psg.com (Randy Bush) Date: Wed, 22 Oct 2008 13:29:00 -0600 Subject: Telstra NOC In-Reply-To: <48FF7CE0.6060106@thewybles.com> References: <48FF7CE0.6060106@thewybles.com> Message-ID: <48FF7EFC.4000704@psg.com> Charles Wyble wrote: > http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg so telstra's noc had more glass than ass one lunchtime nine years ago. next? randy From surfer at mauigateway.com Wed Oct 22 14:31:57 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 22 Oct 2008 12:31:57 -0700 Subject: UDRP and ICANN / Input Requested Message-ID: <20081022123157.25F5B316@resin14.mta.everyone.net> Fire, meet gasoline. >;-) If allowed to ignite, this will be an explosive discussion. scott --- ernesto at cs.fiu.edu wrote: From: Ernie Rubi So I'm a network engineer and a law student and have decided to write a short note for one of our International Law classes based on UDRP and ICANN issues. I'd like to request input from the community as to what they see as the advantages and disadvantages for the UDRP process the way ICANN has it structured now. Any comments on how to improve the system are greatly appreciated. You can contact post to the list or contact me off list, either way my information is below. From mike.lyon at gmail.com Wed Oct 22 14:34:27 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 22 Oct 2008 12:34:27 -0700 Subject: Telstra NOC In-Reply-To: References: <48FF7CE0.6060106@thewybles.com> Message-ID: <1b5c1c150810221234l516cd579r877c887fb031e58b@mail.gmail.com> That's a guy :) On Wed, Oct 22, 2008 at 12:28 PM, Steve Church wrote: > Who's the hot chick in the bottom right corner? > > S > > On Wed, Oct 22, 2008 at 3:20 PM, Charles Wyble wrote: > >> >> http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg >> >> >> > From chaim.rieger at gmail.com Wed Oct 22 14:35:32 2008 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 22 Oct 2008 12:35:32 -0700 Subject: Telstra NOC In-Reply-To: References: <48FF7CE0.6060106@thewybles.com> Message-ID: <48FF8084.7000006@gmail.com> Steve Church wrote: > Who's the hot chick in the bottom right corner? > > S thats my sis, want her number ? -- -- Chaim Rieger From baldwinmathew at gmail.com Wed Oct 22 14:38:46 2008 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Wed, 22 Oct 2008 12:38:46 -0700 Subject: Telstra NOC In-Reply-To: References: <48FF7CE0.6060106@thewybles.com> Message-ID: <5c0303b00810221238t2c2f9140kbd237e838f7ab4ae@mail.gmail.com> Based upon the NOCs I've been in I would say that "chick" is a dude. :) -matt On Wed, Oct 22, 2008 at 12:28 PM, Steve Church wrote: > Who's the hot chick in the bottom right corner? > > S > > On Wed, Oct 22, 2008 at 3:20 PM, Charles Wyble wrote: > >> >> http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg >> >> >> > From ernesto at cs.fiu.edu Wed Oct 22 14:41:31 2008 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 22 Oct 2008 15:41:31 -0400 Subject: UDRP and ICANN / Input Requested In-Reply-To: <20081022123157.25F5B316@resin14.mta.everyone.net> References: <20081022123157.25F5B316@resin14.mta.everyone.net> Message-ID: <2BD16950-C2E7-44E5-B485-881669BDEB9D@cs.fiu.edu> Off list is fine...this is precisely why I chose to write about it. On Oct 22, 2008, at 3:31 PM, Scott Weeks wrote: > > > Fire, meet gasoline. >;-) If allowed to ignite, this will be an > explosive discussion. > > scott > > > > --- ernesto at cs.fiu.edu wrote: > From: Ernie Rubi > > So I'm a network engineer and a law student and have decided to write > a short note for one of our International Law classes based on UDRP > and ICANN issues. > > I'd like to request input from the community as to what they see as > the advantages and disadvantages for the UDRP process the way ICANN > has it structured now. > > Any comments on how to improve the system are greatly appreciated. > You can contact post to the list or contact me off list, either way my > information is below. > > > > > > > From mike at rockynet.com Wed Oct 22 14:46:19 2008 From: mike at rockynet.com (Mike Lewinski) Date: Wed, 22 Oct 2008 13:46:19 -0600 Subject: Telstra NOC In-Reply-To: <48FF8084.7000006@gmail.com> References: <48FF7CE0.6060106@thewybles.com> <48FF8084.7000006@gmail.com> Message-ID: <48FF830B.4090107@rockynet.com> Chaim Rieger wrote: > Steve Church wrote: >> Who's the hot chick in the bottom right corner? >> >> S > thats my sis, want her number ? > While today may be international CAPS LOCK DAY (http://capslockday.com), I believe off-topic posting day was last Thursday. From rcorbin at TRAFFIQ.com Wed Oct 22 14:47:11 2008 From: rcorbin at TRAFFIQ.com (Raymond Corbin) Date: Wed, 22 Oct 2008 15:47:11 -0400 Subject: Telstra NOC In-Reply-To: Message-ID: That's a dude.... -r -----Original Message----- From: Steve Church [mailto:nanog at headcandy.org] Sent: Wednesday, October 22, 2008 3:29 PM To: NANOG list Subject: Re: Telstra NOC Who's the hot chick in the bottom right corner? S On Wed, Oct 22, 2008 at 3:20 PM, Charles Wyble wrote: > > http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires .jpg > > > From jeffshultz at wvi.com Wed Oct 22 16:19:42 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 22 Oct 2008 14:19:42 -0700 Subject: Telstra NOC In-Reply-To: References: Message-ID: <48FF98EE.9090809@wvi.com> Why am I having an Aerosmith flashback right now? Raymond Corbin wrote: > That's a dude.... > > -r > > -----Original Message----- > From: Steve Church [mailto:nanog at headcandy.org] > Sent: Wednesday, October 22, 2008 3:29 PM > To: NANOG list > Subject: Re: Telstra NOC > > Who's the hot chick in the bottom right corner? > > S > > On Wed, Oct 22, 2008 at 3:20 PM, Charles Wyble > wrote: > >> > http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires > .jpg >> >> > -- Jeff Shultz From Crist.Clark at globalstar.com Wed Oct 22 16:47:15 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 22 Oct 2008 14:47:15 -0700 Subject: Telstra NOC In-Reply-To: <48FF7CE0.6060106@thewybles.com> References: <48FF7CE0.6060106@thewybles.com> Message-ID: <48FF3CF2.33E4.0097.0@globalstar.com> >>> On 10/22/2008 at 12:20 PM, Charles Wyble wrote: > http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg The date on the screen, June 30, 1999. I was wondering about the absence of any LCD displays until I saw that. The number of CRTs in that room without energy saving enabled (you can see the screensaver) is sad even for 1999. I also like the one with a BSoD. Do they still have those crappy phones? We still are stuck with them. From Robby at cribbes.com Wed Oct 22 20:06:34 2008 From: Robby at cribbes.com (Robby Cribbes) Date: Thu, 23 Oct 2008 09:06:34 +0800 Subject: Telstra NOC In-Reply-To: <48FF3CF2.33E4.0097.0@globalstar.com> References: <48FF7CE0.6060106@thewybles.com> <48FF3CF2.33E4.0097.0@globalstar.com> Message-ID: <5FC4F6DBB386A141B763EF01C07BAE458168A66926@helm.bg.home.au> The latest MNOC for Telstra (and some photos)- Apparently it grabs a feed out of the Victorian Global Operations Center. http://www.itnews.com.au/News/85870,telstra-launches-mnoc-in-sydney.aspx http://www.itnews.com.au/Galleries/Gallery.aspx?galleryID=610&imageID=18818 R -----Original Message----- From: Crist Clark [mailto:Crist.Clark at globalstar.com] Sent: Thursday, 23 October 2008 5:47 AM To: NANOG list Subject: Re: Telstra NOC >>> On 10/22/2008 at 12:20 PM, Charles Wyble wrote: > http://www.telstra.com.au/abouttelstra/images/media/photos/73764g2_hires.jpg The date on the screen, June 30, 1999. I was wondering about the absence of any LCD displays until I saw that. The number of CRTs in that room without energy saving enabled (you can see the screensaver) is sad even for 1999. I also like the one with a BSoD. Do they still have those crappy phones? We still are stuck with them. This email and any files transmitted with it are confidential and may contain privileged or copyright protected information. You must not present this message to another party without gaining permission from the sender. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us. If you have received this message in error, please notify the sender immediately, and delete this email from your system. We do not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk. From jlewis at lewis.org Wed Oct 22 21:39:30 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 22 Oct 2008 22:39:30 -0400 (EDT) Subject: What's with all the long aspaths? Message-ID: Is there something silly going around? I doubt I'm the only one noticing these being triggered by our generous maxas-limit setting. Oct 9 23:01:46: %BGP-6-ASPATH: ... 27754 27754 27754 ... Oct 17 11:10:40: %BGP-6-ASPATH: ... 43413 43413 43413 ... Oct 22 06:34:09: %BGP-6-ASPATH: ... 38230 38230 38230 ... Anyone have theories as to what these networks are trying to accomplish? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Wed Oct 22 21:57:38 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 22 Oct 2008 22:57:38 -0400 (EDT) Subject: What's with all the long aspaths? In-Reply-To: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz> References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz> Message-ID: Yeah...prepending isn't a big deal...but when someone prepends their own AS 70+ times, I wonder WTF they're thinking. On Thu, 23 Oct 2008, James Baker wrote: > bgp path prepend? > > -----Original Message----- > From: Jon Lewis [mailto:jlewis at lewis.org] > Sent: Thursday, 23 October 2008 3:40 p.m. > To: nanog at nanog.org > Subject: What's with all the long aspaths? > > Is there something silly going around? I doubt I'm the only one > noticing > these being triggered by our generous maxas-limit setting. > > Oct 9 23:01:46: %BGP-6-ASPATH: ... 27754 27754 27754 ... > Oct 17 11:10:40: %BGP-6-ASPATH: ... 43413 43413 43413 ... > Oct 22 06:34:09: %BGP-6-ASPATH: ... 38230 38230 38230 ... > > Anyone have theories as to what these networks are trying to accomplish? > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > ---------- > > The information contained in this e-mail and any attachments is confidential > and is intended for the attention and use of the named addressee(s) only. > Any views expressed in this message are those of the individual sender and > may not necessarily reflect the views of Chelmer Limited. > > ##################################################################################### > This e-mail message has been scanned for Viruses and Content and cleared > by NetIQ MailMarshal > ##################################################################################### > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mike at rockynet.com Wed Oct 22 22:09:37 2008 From: mike at rockynet.com (Mike Lewinski) Date: Wed, 22 Oct 2008 21:09:37 -0600 Subject: What's with all the long aspaths? In-Reply-To: References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz> Message-ID: <48FFEAF1.8000103@rockynet.com> Jon Lewis wrote: > Yeah...prepending isn't a big deal...but when someone prepends their own > AS 70+ times, I wonder WTF they're thinking. > I'm sure they get the attention of NOCs around the world as messages like this show up on consoles Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) for aspath. Replenishing with malloc This time I couldn't be bothered to dig too deeply into who was the cause. From jlewis at lewis.org Wed Oct 22 22:17:19 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 22 Oct 2008 23:17:19 -0400 (EDT) Subject: What's with all the long aspaths? In-Reply-To: <48FFEAF1.8000103@rockynet.com> References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz> <48FFEAF1.8000103@rockynet.com> Message-ID: On Wed, 22 Oct 2008, Mike Lewinski wrote: > I'm sure they get the attention of NOCs around the world as messages like > this show up on consoles > > Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) for > aspath. Replenishing with malloc You might consider something like bgp maxas-limit 75 to exchange that log message for the less scarey Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ... As an added bonus, you ignore their route while they're playing such games. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kch670 at eecs.northwestern.edu Wed Oct 22 22:17:54 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Wed, 22 Oct 2008 22:17:54 -0500 Subject: question on BGP aggregation Message-ID: Hi, I observe some BGP AS paths collected from Routeview having the AS-set in the last hop. According to my understanding, this is BGP route aggregation. However, my question is as follows: Suppose, there is a path AS1 AS2 AS3 {AS4 AS5 AS6}, how AS4 AS5 AS6 connect to AS3? Does it necessarily mean that AS4 AS5 AS6 are direct neighbors of AS4, and AS4 aggregate the routes from AS4 AS5 AS6 then exporting outside. or, it could be other cases such as AS4 aggregate AS5 AS6 first, and then AS3 aggregate AS4? Thanks in advance, From rveloso at cs.ucla.edu Wed Oct 22 22:31:10 2008 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Wed, 22 Oct 2008 20:31:10 -0700 Subject: question on BGP aggregation In-Reply-To: References: Message-ID: the ASes in the AS_SET resulted from merging 2 or more AS_PATHS, you only know at least one of them is connected to AS3 ... more details at rfc4271: http://www.ietf.org/rfc/rfc4271.txt "An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems. AS_SETs provide sufficient information to avoid routing information looping; however, their use may prune potentially feasible paths because such paths are no longer listed individually in the form of AS_SEQUENCEs. In practice, this is not likely to be a problem because once an IP packet arrives at the edge of a group of autonomous systems, the BGP speaker is likely to have more detailed path information and can distinguish individual paths from destinations. " --Ricardo On Oct 22, 2008, at 8:17 PM, Kai Chen wrote: > Hi, > > I observe some BGP AS paths collected from Routeview having the AS-set > in the last hop. According to my understanding, this is BGP route > aggregation. However, my question is as follows: > Suppose, there is a path AS1 AS2 AS3 {AS4 AS5 AS6}, how AS4 AS5 AS6 > connect to AS3? > Does it necessarily mean that AS4 AS5 AS6 are direct neighbors of AS4, > and AS4 aggregate the routes from AS4 AS5 AS6 then exporting outside. > or, it could be other cases such as AS4 aggregate AS5 AS6 first, and > then AS3 aggregate AS4? > > Thanks in advance, From rs at seastrom.com Thu Oct 23 06:41:32 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 23 Oct 2008 07:41:32 -0400 Subject: What's with all the long aspaths? In-Reply-To: (Jon Lewis's message of "Wed, 22 Oct 2008 23:17:19 -0400 (EDT)") References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz> <48FFEAF1.8000103@rockynet.com> Message-ID: <863ainr11v.fsf@seastrom.com> Jon Lewis writes: > You might consider something like bgp maxas-limit 75 to exchange that > log message for the less scarey > Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ... > > As an added bonus, you ignore their route while they're playing such > games. Which is exactly what they want. What you *really* want to do is: router bgp foo neighbor bar route-map prepend-this-you-fool in ip as-path access-list 66 permit _blah_blah_blah_blah_blah_blah_blah_blah_blah_ route-map prepend-this-you-fool permit 10 match as-path 66 set local-preference 1000 -r From cchurc05 at harris.com Thu Oct 23 09:41:20 2008 From: cchurc05 at harris.com (Church, Charles) Date: Thu, 23 Oct 2008 09:41:20 -0500 Subject: What's with all the long aspaths? In-Reply-To: References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz><48FFEAF1.8000103@rockynet.com> Message-ID: Sounds like some automated scripts that didn't do any sanity checking. Process pulls the current BGP table, checks for the longest path, and then prepends the AS that many times to guarantee everyone takes the other path. But if two ISPs are doing this, well, the paths get longer and longer. I just checked our table for those ASs mentioned in your log, they look short now. Guess they caught it. Chuck -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Wednesday, October 22, 2008 11:17 PM To: Mike Lewinski Cc: nanog at nanog.org Subject: Re: What's with all the long aspaths? On Wed, 22 Oct 2008, Mike Lewinski wrote: > I'm sure they get the attention of NOCs around the world as messages like > this show up on consoles > > Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) for > aspath. Replenishing with malloc You might consider something like bgp maxas-limit 75 to exchange that log message for the less scarey Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ... As an added bonus, you ignore their route while they're playing such games. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From pfs at cisco.com Thu Oct 23 11:01:33 2008 From: pfs at cisco.com (Philip Smith) Date: Fri, 24 Oct 2008 02:01:33 +1000 Subject: What's with all the long aspaths? In-Reply-To: References: Message-ID: <49009FDD.1090301@cisco.com> Jon Lewis said the following on 23/10/08 12:39: > Is there something silly going around? I doubt I'm the only one > noticing these being triggered by our generous maxas-limit setting. > > Oct 9 23:01:46: %BGP-6-ASPATH: ... 27754 27754 27754 ... > Oct 17 11:10:40: %BGP-6-ASPATH: ... 43413 43413 43413 ... > Oct 22 06:34:09: %BGP-6-ASPATH: ... 38230 38230 38230 ... > > Anyone have theories as to what these networks are trying to accomplish? Theories include: - trying to make a /20 announcement more important than a component /24 by prepending the /24 out of sight (i'm not joking, some people really believe this!!) - trying to over-ride policy that their upstream provider has applied (e.g. my prepended /20 is a backup to my main /20 announcement but my upstream on the backup path is local pref-ing high to make them look more "peerable") There are bound to be other reasons... :-) philip -- From tomb at byrneit.net Thu Oct 23 11:53:19 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 23 Oct 2008 09:53:19 -0700 Subject: What's with all the long aspaths? In-Reply-To: References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz><48FFEAF1.8000103@rockynet.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F7E0@pascal.zaphodb.org> Not using that prepended route is exactly what the point of the prepend is, so that's not "punishment". It may, in fact, be exactly what they're trying to get you to do. >-----Original Message----- >From: Jon Lewis [mailto:jlewis at lewis.org] >Sent: Wednesday, October 22, 2008 8:17 PM >To: Mike Lewinski >Cc: nanog at nanog.org >Subject: Re: What's with all the long aspaths? > >On Wed, 22 Oct 2008, Mike Lewinski wrote: > >> I'm sure they get the attention of NOCs around the world as messages >like >> this show up on consoles >> >> Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) for >> aspath. Replenishing with malloc > >You might consider something like bgp maxas-limit 75 to exchange that >log >message for the less scarey >Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ... > >As an added bonus, you ignore their route while they're playing such >games. > >---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | >_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hannigan at gmail.com Thu Oct 23 13:40:02 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 23 Oct 2008 14:40:02 -0400 Subject: UDRP and ICANN / Input Requested In-Reply-To: References: Message-ID: <2d106eb50810231140g7e92f60fy750a2106069c214c@mail.gmail.com> On Wed, Oct 22, 2008 at 3:16 PM, Ernie Rubi wrote: > Hi folks, > > So I'm a network engineer and a law student and have decided to write a > short note for one of our International Law classes based on UDRP and ICANN > issues. > > I'd like to request input from the community as to what they see as the > advantages and disadvantages for the UDRP process the way ICANN has it > structured now. > > Any comments on how to improve the system are greatly appreciated. You can > contact post to the list or contact me off list, either way my information > is below. > You may want to use some of the resources available at Harvard, specifically through the Berkman Center for Internet and Society. http://cyber.law.harvard.edu/ A freeform search on UDRP there garnered many hits that I would consider more useful than a NANOG discussion on the ICANN UDRP: http://cyber.law.harvard.edu/search/node/UDRP Best, Martin Hannigan From jason.iannone at gmail.com Thu Oct 23 13:44:13 2008 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 23 Oct 2008 12:44:13 -0600 Subject: What's with all the long aspaths? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F7E0@pascal.zaphodb.org> References: <64396C74FCE435468BE2AF5A73F9C2FD869479@chmaexch.chelmer.co.nz> <48FFEAF1.8000103@rockynet.com> <70D072392E56884193E3D2DE09C097A9F7E0@pascal.zaphodb.org> Message-ID: Except when their primary path goes away and relatively few networks install the prepended route. It's all conjecture, but I like the 'in effort to defeat local pref' option. On Thu, Oct 23, 2008 at 10:53 AM, Tomas L. Byrnes wrote: > Not using that prepended route is exactly what the point of the prepend > is, so that's not "punishment". > > It may, in fact, be exactly what they're trying to get you to do. > > >>-----Original Message----- >>From: Jon Lewis [mailto:jlewis at lewis.org] >>Sent: Wednesday, October 22, 2008 8:17 PM >>To: Mike Lewinski >>Cc: nanog at nanog.org >>Subject: Re: What's with all the long aspaths? >> >>On Wed, 22 Oct 2008, Mike Lewinski wrote: >> >>> I'm sure they get the attention of NOCs around the world as messages >>like >>> this show up on consoles >>> >>> Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) > for >>> aspath. Replenishing with malloc >> >>You might consider something like bgp maxas-limit 75 to exchange that >>log >>message for the less scarey >>Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ... >> >>As an added bonus, you ignore their route while they're playing such >>games. >> >>---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >>_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > From fw at deneb.enyo.de Thu Oct 23 14:03:48 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 23 Oct 2008 21:03:48 +0200 Subject: Kaminsky redux - libspf2 dns parsing bug In-Reply-To: (Suresh Ramasubramanian's message of "Wed, 22 Oct 2008 06:55:10 +0530") References: Message-ID: <87hc73qgkr.fsf@mid.deneb.enyo.de> * Suresh Ramasubramanian: > For the "mailops is not operational" folks.. it involves parsing dns > txt records, so .. well, please grit your teeth and read on, this gets > interesting By the way, BIND 9 is supposed to throw away this type of malformed RDATA, so if you run BIND 9, this is only relevant if you can somehow spoof messages to the stub resolver. From brunner at nic-naa.net Thu Oct 23 14:14:24 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 23 Oct 2008 15:14:24 -0400 Subject: UDRP and ICANN / Input Requested In-Reply-To: References: Message-ID: <4900CD10.5080004@nic-naa.net> Ernie, Martin's suggestions (go rummage around the Berkman dump) is a good one. Not too far from you is someone who actually is a leading figure in this somewhat arcane field, Prof. Froomkin at Miami Law. There've been a couple of papers over the years that are good sources too. Drop a note to the IPC people (you can find them from the GNSO page off the ICANN page) for pointers. NANOG, as you probably know, is an operators list, somewhat North American centric. Operators aren't usually caught up in DRPs, and everyone has an opinion on ICANN. I wrote some bumpf for our brouchure (which mercifully was cut when the copy went to the graphic designer) which we'll be touching on in the workshop we're doing on the 5th in Cairo: http://cai.icann.org/en/node/1867. "Linguistic and cultural applications need to address the intellectual property issues of patrimony and tradition and prioritize those rights, both during the "Sunrise" period, and as an ongoing conflicts resolution process." "Applications for cities also need to address intellectual property issues of space, place and name, and prioritize those rights, both during the "Sunrise" period, and as an ongoing conflicts resolution process." I've lost the para for regional apps, but Governments have the odd idea that they own things, so we'll have to keep governments, as well as the usual bandits, from claiming they own "nile" or "sahara" in a .africa. All this is just to say that the original, marks-focused DRP trajectory may be altered by more registries like .cat (Catalan language and culture) and what I think of as "senior rights" (I'm from the water-poor west, so water rights sort of colors my thinking), that is, rights that pre-exist marks. Oblig WIPO-2 bash: Free Pokey!!! Eric Ernie Rubi wrote: > Hi folks, > > So I'm a network engineer and a law student and have decided to write > a short note for one of our International Law classes based on UDRP > and ICANN issues. > > I'd like to request input from the community as to what they see as > the advantages and disadvantages for the UDRP process the way ICANN > has it structured now. > > Any comments on how to improve the system are greatly appreciated. > You can contact post to the list or contact me off list, either way my > information is below. > > Ernesto M. Rubi > Network Engineer - AMPATH > Florida International University > J.D. Candidate, 2010 > Patent Agent - USPTO Reg. 63,074 > FIU College of Law > Email: ernesto at cs.fiu.edu > > > > > > > From nanog at webazilla.com Thu Oct 23 14:18:20 2008 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Thu, 23 Oct 2008 22:18:20 +0300 Subject: Long haul Ethernet providers around? Message-ID: <4900CDFC.6080507@webazilla.com> Hi, If there are any long haul Ethernet providers on the list, can you contact me offlist? I'm looking for 10GE from Dallas to Ashburn. Thanks. -Konstantin From hank at efes.iucc.ac.il Thu Oct 23 14:33:28 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 23 Oct 2008 21:33:28 +0200 (IST) Subject: What's with all the long aspaths? In-Reply-To: <49009FDD.1090301@cisco.com> References: <49009FDD.1090301@cisco.com> Message-ID: On Fri, 24 Oct 2008, Philip Smith wrote: > Jon Lewis said the following on 23/10/08 12:39: >> Is there something silly going around? I doubt I'm the only one >> noticing these being triggered by our generous maxas-limit setting. >> >> Oct 9 23:01:46: %BGP-6-ASPATH: ... 27754 27754 27754 ... >> Oct 17 11:10:40: %BGP-6-ASPATH: ... 43413 43413 43413 ... >> Oct 22 06:34:09: %BGP-6-ASPATH: ... 38230 38230 38230 ... >> >> Anyone have theories as to what these networks are trying to accomplish? > > Theories include: > > - trying to make a /20 announcement more important than a component /24 > by prepending the /24 out of sight (i'm not joking, some people really > believe this!!) > > - trying to over-ride policy that their upstream provider has applied > (e.g. my prepended /20 is a backup to my main /20 announcement but my > upstream on the backup path is local pref-ing high to make them look > more "peerable") > > There are bound to be other reasons... :-) My theory - some netadmin trying to see if anything bad happens when he does it. Sort of like the Darwin winner who's last words are "I wonder what would happen if I tri..." -Hank From kch670 at eecs.northwestern.edu Thu Oct 23 15:21:26 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Thu, 23 Oct 2008 15:21:26 -0500 Subject: question on BGP aggregation In-Reply-To: References: Message-ID: Thanks, A further question, is it mandatory for all the aggregated information be appended at the AS path, is it possible for some aggregations do not propagate outside? By this, I mean some ASes completely conceal their aggregated ASes when propagation. thanks a lot. On Wed, Oct 22, 2008 at 10:31 PM, Ricardo Oliveira wrote: > the ASes in the AS_SET resulted from merging 2 or more AS_PATHS, you only > know at least one of them is connected to AS3 ... > more details at rfc4271: > http://www.ietf.org/rfc/rfc4271.txt > > "An AS_SET implies that the destinations listed in the NLRI can > be reached through paths that traverse at least some of the > constituent autonomous systems. AS_SETs provide sufficient > information to avoid routing information looping; however, > their use may prune potentially feasible paths because such > paths are no longer listed individually in the form of > AS_SEQUENCEs. In practice, this is not likely to be a problem > because once an IP packet arrives at the edge of a group of > autonomous systems, the BGP speaker is likely to have more > detailed path information and can distinguish individual paths > from destinations. > " > > --Ricardo > > On Oct 22, 2008, at 8:17 PM, Kai Chen wrote: > >> Hi, >> >> I observe some BGP AS paths collected from Routeview having the AS-set >> in the last hop. According to my understanding, this is BGP route >> aggregation. However, my question is as follows: >> Suppose, there is a path AS1 AS2 AS3 {AS4 AS5 AS6}, how AS4 AS5 AS6 >> connect to AS3? >> Does it necessarily mean that AS4 AS5 AS6 are direct neighbors of AS4, >> and AS4 aggregate the routes from AS4 AS5 AS6 then exporting outside. >> or, it could be other cases such as AS4 aggregate AS5 AS6 first, and >> then AS3 aggregate AS4? >> >> Thanks in advance, > > From alh-ietf at tndh.net Thu Oct 23 17:39:42 2008 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 23 Oct 2008 15:39:42 -0700 Subject: IPv6 Wow In-Reply-To: <7EDA8DD1-5205-424B-BA9F-C91EE761A6A3@daork.net> References: <2fa1e1780810120907y46b1b0e9g25c8549d070d8b91@mail.gmail.com> <1223832571.5199.80.camel@petrie.sacredspiral.co.uk> <82ED79DC-6993-4AC4-8870-CDE76E778B23@daork.net> <48F263B9.80007@sprunk.org> <81053F20-9C56-4CBD-A56C-C622959B700B@daork.net> <200810130246.m9D2kt79010996@parsley.amaranth.net> <7EDA8DD1-5205-424B-BA9F-C91EE761A6A3@daork.net> Message-ID: <027a01c93560$3e5c2ad0$bb148070$@net> Nathan Ward wrote: ... > 2) If Teredo relays are deployed close to the service (ie. content, > etc.) then performance is almost equivalent to IPv4. 6to4 relies on > relays being close to both the client and the server, which requires > end users' ISPs to build at least *some* IPv6 infrastructure, maintain > transit, etc. When you consider that this infrastructure and transit > is quite likely to be over long tunnels to weird parts of the world, > this is a bad thing. Putting relays close to the content helps for the > reverse path (ie. content -> client), however the forward path (client > -> content) is likely to perform poorly. Not quite correct. 6to4 does not require transiting a relay if the target is another 6to4 site. What this means is that a clueful content provider will put up a 6to4 router alongside whatever native service they provide, then populate the dns with both the native and 6to4 address. A properly implemented client will do the longest prefix match against that set, so a 6to4 client will go directly to the content provider's 6to4 router, while a native client will take the direct path. The only time an anycast relay needs to be used is when the server is native-only and the client is 6to4-only. Tony From alain_durand at cable.comcast.com Thu Oct 23 17:46:05 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Thu, 23 Oct 2008 18:46:05 -0400 Subject: IPv6 Wow In-Reply-To: <027a01c93560$3e5c2ad0$bb148070$@net> Message-ID: On 10/23/08 6:39 PM, "Tony Hain" wrote: > A properly > implemented client will do the longest prefix match against that set, so a > 6to4 client will go directly to the content provider's 6to4 router, while a > native client will take the direct path. Not quite. Say the server has native IPv6 address 2001::1 and 6to4 IPv6 2002::X. Say the client has native IPv6 address 2003::1 and 6to4 IPv6 2002::Y. Longest prefix match will choose 6to4 over native IPv6. Not good. - Alain. From Mark_Andrews at isc.org Thu Oct 23 18:52:00 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 24 Oct 2008 10:52:00 +1100 Subject: IPv6 Wow In-Reply-To: Your message of "Thu, 23 Oct 2008 18:46:05 EDT." Message-ID: <200810232352.m9NNq0gk070337@drugs.dv.isc.org> In message , Alain Durand writes : > > > > On 10/23/08 6:39 PM, "Tony Hain" wrote: > > > A properly > > implemented client will do the longest prefix match against that set, so a > > 6to4 client will go directly to the content provider's 6to4 router, while a > > native client will take the direct path. > > Not quite. > Say the server has native IPv6 address 2001::1 and 6to4 IPv6 2002::X. > Say the client has native IPv6 address 2003::1 and 6to4 IPv6 2002::Y. > Longest prefix match will choose 6to4 over native IPv6. Not good. > > - Alain. Longest match to select destination address without knowlege of the prefix lengths involved is bogus. Applying a /32, /48 and /64 prefix break points to addresses in 2001::/16 and 2003::/16 and a /16, /48 and /64 to addresses in 2002::/16 will produce reasonable but not perfect results. That's ISP, SITE and LINK level prefix break points. 6to4 can be seen as one ISP with a /16. Note you only need to configure the break points for the address space you are using. We need automate the dissemination of these values within a ISP to the customers so they can correctly configure their address selection rules. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jabley at hopcount.ca Thu Oct 23 22:08:18 2008 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 23 Oct 2008 23:08:18 -0400 Subject: IPv6 Wow In-Reply-To: References: Message-ID: <5A05D3F4-0B7F-468F-B59C-88C74A6EBC5F@hopcount.ca> On 23 Oct 2008, at 18:46, Alain Durand wrote: > On 10/23/08 6:39 PM, "Tony Hain" wrote: > >> A properly >> implemented client will do the longest prefix match against that >> set, so a >> 6to4 client will go directly to the content provider's 6to4 router, >> while a >> native client will take the direct path. > > Not quite. > Say the server has native IPv6 address 2001::1 and 6to4 IPv6 2002::X. > Say the client has native IPv6 address 2003::1 and 6to4 IPv6 2002::Y. > Longest prefix match will choose 6to4 over native IPv6. Not good. Surely the longest prefix only wins over prefixes that cover the long prefix. What you seem to be suggesting is that a client will somehow be able to deduce the prefix length for two bare v6 addresses received from the DNS, and will choose the one with the longest prefix first. That seems unlikely to be the case in general. Joe From perry at coders.net Thu Oct 23 22:36:00 2008 From: perry at coders.net (Perry Lorier) Date: Fri, 24 Oct 2008 16:36:00 +1300 Subject: IPv6 Wow In-Reply-To: References: Message-ID: <490142A0.3050402@coders.net> Alain Durand wrote: > > On 10/23/08 6:39 PM, "Tony Hain" wrote: > > >> A properly >> implemented client will do the longest prefix match against that set, so a >> 6to4 client will go directly to the content provider's 6to4 router, while a >> native client will take the direct path. >> > > Not quite. > Say the server has native IPv6 address 2001::1 and 6to4 IPv6 2002::X. > Say the client has native IPv6 address 2003::1 and 6to4 IPv6 2002::Y. > Longest prefix match will choose 6to4 over native IPv6. Not good. > > Not quite. A properly implemented client will use the policy table first which by section 2.1 and 10.3 of RFC 3484 depref's 2002::/16 below 0::/0. It's only if two addresses are very similar (as far as the OS can determine) that the "longest match" rule comes into play. You should also be able to configure your operating system to depref or pref source/destination addresses as local site policy requires (avoiding tunnels, preferring v4 for some sites, using 6to4 for other sites, and avoiding v6 all together for others and so on). From iradsn09 at zju.edu.cn Fri Oct 24 03:35:33 2008 From: iradsn09 at zju.edu.cn (iradsn09 at zju.edu.cn) Date: Fri, 24 Oct 2008 16:35:33 +0800 Subject: Paper submission deadlines of IRADSN'09 have been extended References: <200810241611575315974@zju.edu.cn> Message-ID: <424836414.06917@zju.edu.cn> Dear Colleagues, Please accept our apologies if you receive multiple copies of this announcement. Due to numerous deadline extension requests from potential IRADSN 2009 authors, the IRADSN organizing committee has decided to extend the paper submission deadline to 11/15/2008. Please note that this is a hard deadline, so that the technical committees can perform their paper reviewing duties in a timely manner. Call for paper can be found in attachments. If you received this email in error, please forward it to the appropriate department at your institution. Please do not reply to this message. If you need to contact us please email us at iradsn09 at zju.edu.cn -------------- next part -------------- A non-text attachment was scrubbed... Name: cfp_iradsn09.pdf Type: application/octet-stream Size: 46428 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Oct 24 07:00:07 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Oct 2008 22:00:07 +1000 (EST) Subject: BGP Update Report Message-ID: <200810241200.m9OC07eX023304@wattle.apnic.net> BGP Update Report Interval: 22-Sep-08 -to- 23-Oct-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 207109 2.2% 182.8 -- SIFY-AS-IN Sify Limited 2 - AS1803 97805 1.1% 70.7 -- ICMNET-5 - Sprint 3 - AS4538 80573 0.9% 15.9 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS5691 77747 0.8% 5980.5 -- MITRE-AS-5 - The MITRE Corporation 5 - AS6389 71848 0.8% 16.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 6 - AS20255 71252 0.8% 2298.5 -- Tecnowind S.A. 7 - AS8151 66487 0.7% 27.7 -- Uninet S.A. de C.V. 8 - AS9051 60816 0.7% 382.5 -- IDM Autonomous System 9 - AS20115 54861 0.6% 23.4 -- CHARTER-NET-HKY-NC - Charter Communications 10 - AS6629 54763 0.6% 842.5 -- NOAA-AS - NOAA 11 - AS7046 49270 0.5% 83.7 -- UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 12 - AS14593 49149 0.5% 49149.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 13 - AS30890 48780 0.5% 49.8 -- EVOLVA Evolva Telecom 14 - AS10396 47946 0.5% 622.7 -- COQUI-NET - DATACOM CARIBE, INC. 15 - AS10986 44612 0.5% 501.3 -- Intermedia Comunicaciones S.A. 16 - AS4274 43772 0.5% 643.7 -- ERX-AU-NET Assumption University 17 - AS6458 41026 0.5% 99.8 -- Telgua 18 - AS17974 39169 0.4% 48.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS22492 37376 0.4% 12458.7 -- 20 - AS14846 36266 0.4% 824.2 -- CGNOGE - NBC Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 49149 0.5% 49149.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS43299 16563 0.2% 16563.0 -- TELECONTACT-AS Telecontact Ltd. 3 - AS22492 37376 0.4% 12458.7 -- 4 - AS37026 17793 0.2% 8896.5 -- SALT-ASN 5 - AS32761 7146 0.1% 7146.0 -- WASSE-NYC - Wasserstein & Co. 6 - AS5691 77747 0.8% 5980.5 -- MITRE-AS-5 - The MITRE Corporation 7 - AS8266 5752 0.1% 5752.0 -- NEXUSTEL Nexus Telecommunications 8 - AS29910 5128 0.1% 5128.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 9 - AS4184 9665 0.1% 4832.5 -- STORTEK-WHQ - Storage Technology Corporation 10 - AS23082 20143 0.2% 4028.6 -- MPHI - Michigan Public Health Institute 11 - AS38180 3941 0.0% 3941.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 12 - AS30969 30175 0.3% 3771.9 -- TAN-NET TransAfrica Networks 13 - AS44194 3262 0.0% 3262.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 14 - AS21603 31590 0.3% 3159.0 -- Universidad La Salle, AC 15 - AS41007 14765 0.2% 2953.0 -- CTCASTANA CTC ASTANA, KZ 16 - AS30287 2385 0.0% 2385.0 -- ALON-USA - ALON USA, LP 17 - AS4130 11719 0.1% 2343.8 -- UPITT-AS - University of Pittsburgh 18 - AS20255 71252 0.8% 2298.5 -- Tecnowind S.A. 19 - AS23917 2290 0.0% 2290.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 20 - AS5033 20017 0.2% 2224.1 -- ISW - Internet Specialties West Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 77609 0.8% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 210.214.151.0/24 62487 0.6% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.134.222.0/24 61543 0.6% AS9583 -- SIFY-AS-IN Sify Limited 4 - 12.8.7.0/24 49149 0.5% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 5 - 221.135.80.0/24 47921 0.5% AS9583 -- SIFY-AS-IN Sify Limited 6 - 194.126.143.0/24 45711 0.5% AS9051 -- IDM Autonomous System 7 - 12.2.46.0/24 37326 0.4% AS22492 -- 8 - 200.108.200.0/24 35379 0.4% AS20255 -- Tecnowind S.A. 9 - 200.108.220.0/24 35368 0.4% AS20255 -- Tecnowind S.A. 10 - 200.33.104.0/23 31161 0.3% AS21603 -- Universidad La Salle, AC 11 - 221.128.192.0/18 26379 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 12 - 196.42.0.0/20 23209 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 13 - 72.50.96.0/20 23108 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 64.162.116.0/24 19953 0.2% AS5033 -- ISW - Internet Specialties West Inc. 15 - 192.102.88.0/24 17999 0.2% AS6629 -- NOAA-AS - NOAA 16 - 192.35.129.0/24 17871 0.2% AS6629 -- NOAA-AS - NOAA 17 - 198.77.177.0/24 17852 0.2% AS6629 -- NOAA-AS - NOAA 18 - 78.40.24.0/21 16563 0.2% AS43299 -- TELECONTACT-AS Telecontact Ltd. 19 - 89.4.131.0/24 16095 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 196.27.108.0/22 14974 0.1% AS30969 -- TAN-NET TransAfrica Networks Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 24 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Oct 2008 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200810241200.m9OC03UD023295@wattle.apnic.net> This report has been generated at Fri Oct 24 21:27:53 2008 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 17-10-08 284383 173876 18-10-08 284628 172567 19-10-08 284858 172849 20-10-08 284886 173311 21-10-08 285389 173535 22-10-08 285116 174027 23-10-08 285363 173151 24-10-08 285588 174323 AS Summary 29758 Number of ASes in routing system 12598 Number of ASes announcing only one prefix 5046 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88343552 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 24Oct08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 286259 174082 112177 39.2% All ASes AS4538 5046 872 4174 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4360 353 4007 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3062 1369 1693 55.3% ASN-QWEST - Qwest Communications Corporation AS6298 2020 715 1305 64.6% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS4755 1499 262 1237 82.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1698 557 1141 67.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1392 303 1089 78.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1558 481 1077 69.1% TWTC - tw telecom holdings, inc. AS22773 999 70 929 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1396 542 854 61.2% Uninet S.A. de C.V. AS19262 954 199 755 79.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1212 464 748 61.7% CABLEONE - CABLE ONE AS2386 1615 934 681 42.2% INS-AS - AT&T Data Communications Services AS6478 1323 660 663 50.1% ATT-INTERNET3 - AT&T WorldNet Services AS9498 692 69 623 90.0% BBIL-AP BHARTI Airtel Ltd. AS3356 1039 469 570 54.9% LEVEL3 Level 3 Communications AS18566 1059 492 567 53.5% COVAD - Covad Communications Co. AS18101 783 228 555 70.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4766 922 417 505 54.8% KIXS-AS-KR Korea Telecom AS4808 631 157 474 75.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS20115 1955 1484 471 24.1% CHARTER-NET-HKY-NC - Charter Communications AS855 590 142 448 75.9% CANET-ASN-4 - Bell Aliant AS7011 918 475 443 48.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17676 522 79 443 84.9% GIGAINFRA BB TECHNOLOGY Corp. AS7545 611 169 442 72.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 523 82 441 84.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS24560 597 158 439 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 566 129 437 77.2% VTR BANDA ANCHA S.A. AS7018 1440 1004 436 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 858 437 421 49.1% CHINANET-BACKBONE No.31,Jin-rong Street Total 41840 13772 28068 67.1% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 124.109.16.0/21 AS38137 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.25.240.0/21 AS3209 Arcor IP-Network 193.25.240.0/22 AS3209 Arcor IP-Network 193.25.244.0/23 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 193.25.247.0/24 AS3209 Arcor IP-Network 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From brunner at nic-naa.net Fri Oct 24 10:24:39 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 24 Oct 2008 11:24:39 -0400 Subject: UDRP and ICANN / Input Requested In-Reply-To: <4900CD10.5080004@nic-naa.net> References: <4900CD10.5080004@nic-naa.net> Message-ID: <4901E8B7.5060403@nic-naa.net> I should have mentioned this, its a nice, non-fatal, 31pp intro to part of the problem space, from the IPC weenies: http://marques.org/sunrise/A%20Perfect%20Sunrise.pdf Eric From joesox at gmail.com Fri Oct 24 12:59:23 2008 From: joesox at gmail.com (JoeSox) Date: Fri, 24 Oct 2008 10:59:23 -0700 Subject: Alaska DNS Message-ID: <785694cd0810241059q34195a9am4d9e867e13bcb0a0@mail.gmail.com> Is anyone else troubleshooting some Alaska domains the past two days? ACS related? C:\Documents and Settings\Joseph>ping dowlandbach.com Pinging dowlandbach.com [209.112.129.41] with 32 bytes of data: Reply from 209.112.129.41: bytes=32 time=233ms TTL=45 Reply from 209.112.129.41: bytes=32 time=235ms TTL=45 Reply from 209.112.129.41: bytes=32 time=300ms TTL=45 Reply from 209.112.129.41: bytes=32 time=252ms TTL=45 Ping statistics for 209.112.129.41: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 233ms, Maximum = 300ms, Average = 255ms C:\Documents and Settings\Joseph>ping edc-alaska.com Ping request could not find host edc-alaska.com. Please check the name and try a gain. C:\Documents and Settings\Joseph>ping www.edc-alaska.com Pinging aws01.nwc.acsalaska.net [209.112.129.41] with 32 bytes of data: Reply from 209.112.129.41: bytes=32 time=251ms TTL=45 Reply from 209.112.129.41: bytes=32 time=235ms TTL=45 Reply from 209.112.129.41: bytes=32 time=247ms TTL=45 Reply from 209.112.129.41: bytes=32 time=252ms TTL=45 Ping statistics for 209.112.129.41: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 235ms, Maximum = 252ms, Average = 246ms C:\Documents and Settings\Joseph> -- Later, Joe From cscora at apnic.net Fri Oct 24 13:09:48 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Oct 2008 04:09:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200810241809.m9OI9muh015451@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Oct, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 271907 Prefixes after maximum aggregation: 131148 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 132451 Total ASes present in the Internet Routing Table: 29588 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25742 Origin ASes announcing only one prefix: 12531 Transit ASes present in the Internet Routing Table: 3846 Transit-only ASes present in the Internet Routing Table: 81 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 19 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 549 Unregistered ASNs in the Routing Table: 196 Number of 32-bit ASNs allocated by the RIRs: 61 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 751 Number of addresses announced to Internet: 1912392384 Equivalent to 113 /8s, 252 /16s and 202 /24s Percentage of available address space announced: 51.6 Percentage of allocated address space announced: 62.7 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.9 Total number of prefixes smaller than registry allocations: 133807 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62377 Total APNIC prefixes after maximum aggregation: 23279 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59339 Unique aggregates announced from the APNIC address blocks: 26786 APNIC Region origin ASes present in the Internet Routing Table: 3418 APNIC Prefixes per ASN: 17.36 APNIC Region origin ASes announcing only one prefix: 918 APNIC Region transit ASes present in the Internet Routing Table: 532 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 379774368 Equivalent to 22 /8s, 162 /16s and 229 /24s Percentage of available APNIC address space announced: 80.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/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, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123035 Total ARIN prefixes after maximum aggregation: 64787 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92511 Unique aggregates announced from the ARIN address blocks: 35100 ARIN Region origin ASes present in the Internet Routing Table: 12535 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4842 ARIN Region transit ASes present in the Internet Routing Table: 1198 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 363924896 Equivalent to 21 /8s, 177 /16s and 13 /24s Percentage of available ARIN address space announced: 74.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/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, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 59860 Total RIPE prefixes after maximum aggregation: 35810 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 55001 Unique aggregates announced from the RIPE address blocks: 36533 RIPE Region origin ASes present in the Internet Routing Table: 12084 RIPE Prefixes per ASN: 4.55 RIPE Region origin ASes announcing only one prefix: 6351 RIPE Region transit ASes present in the Internet Routing Table: 1844 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 376405152 Equivalent to 22 /8s, 111 /16s and 124 /24s Percentage of available RIPE address space announced: 86.3 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-49151 RIPE Address Blocks 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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22011 Total LACNIC prefixes after maximum aggregation: 5514 LACNIC Deaggregation factor: 3.99 Prefixes being announced from the LACNIC address blocks: 20083 Unique aggregates announced from the LACNIC address blocks: 11207 LACNIC Region origin ASes present in the Internet Routing Table: 1018 LACNIC Prefixes per ASN: 19.73 LACNIC Region origin ASes announcing only one prefix: 338 LACNIC Region transit ASes present in the Internet Routing Table: 169 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 57442816 Equivalent to 3 /8s, 108 /16s and 130 /24s Percentage of available LACNIC address space announced: 57.1 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4078 Total AfriNIC prefixes after maximum aggregation: 1320 AfriNIC Deaggregation factor: 3.09 Prefixes being announced from the AfriNIC address blocks: 4340 Unique aggregates announced from the AfriNIC address blocks: 2112 AfriNIC Region origin ASes present in the Internet Routing Table: 264 AfriNIC Prefixes per ASN: 16.44 AfriNIC Region origin ASes announcing only one prefix: 82 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12873216 Equivalent to 0 /8s, 196 /16s and 110 /24s Percentage of available AfriNIC address space announced: 38.4 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1491 526 199 TATA Communications formerly 17488 1392 97 105 Hathway IP Over Cable Interne 9583 1107 87 475 Sify Limited 4766 883 6408 364 Korea Telecom (KIX) 4134 858 13760 353 CHINANET-BACKBONE 23577 812 35 694 Korea Telecom (ATM-MPLS) 18101 783 161 67 Reliance Infocom Ltd Internet 4780 723 357 63 Digital United Inc. 9498 692 295 54 BHARTI BT INTERNET LTD. 4808 631 1164 142 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4354 3416 338 bellsouth.net, inc. 209 3061 4035 624 Qwest 6298 2025 320 705 Cox Communicatons 1785 1696 718 159 PaeTec Communications, Inc. 20115 1650 1437 723 Charter Communications 2386 1587 699 896 AT&T Data Communications Serv 4323 1555 1084 372 Time Warner Telecom 7018 1416 5873 980 AT&T WorldNet Services 6478 1322 274 197 AT&T Worldnet Services 11492 1212 152 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 432 1777 384 TDC Tele Danmark 30890 348 94 188 SC Kappa Invexim SRL 3301 329 1428 300 TeliaNet Sweden 3215 328 2756 106 France Telecom Transpac 8866 328 111 23 Bulgarian Telecommunication C 3320 326 7063 275 Deutsche Telekom AG 5462 301 794 27 Telewest Broadband 25233 295 45 27 Awalnet 8452 294 188 11 TEDATA 8551 287 270 37 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1397 2833 220 UniNet S.A. de C.V. 11830 669 299 9 Instituto Costarricense de El 22047 566 270 14 VTR PUNTO NET S.A. 10620 518 122 63 TVCABLE BOGOTA 7303 494 243 70 Telecom Argentina Stet-France 16814 425 27 10 NSS, S.A. 6471 419 85 48 ENTEL CHILE S.A. 11172 407 118 73 Servicios Alestra S.A de C.V 28573 353 464 22 NET Servicos de Comunicao S.A 14117 331 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 548 72 42 LINKdotNET AS number 3741 269 856 225 The Internet Solution 2018 233 215 139 Tertiary Education Network 20858 217 34 3 EgyNet 6713 143 135 11 Itissalat Al-MAGHRIB 33783 138 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 113 555 64 Telkom SA Ltd 29571 113 13 9 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4354 3416 338 bellsouth.net, inc. 209 3061 4035 624 Qwest 6298 2025 320 705 Cox Communicatons 1785 1696 718 159 PaeTec Communications, Inc. 20115 1650 1437 723 Charter Communications 2386 1587 699 896 AT&T Data Communications Serv 4323 1555 1084 372 Time Warner Telecom 4755 1491 526 199 TATA Communications formerly 7018 1416 5873 980 AT&T WorldNet Services 8151 1397 2833 220 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3061 2437 Qwest 1785 1696 1537 PaeTec Communications, Inc. 6298 2025 1320 Cox Communicatons 4755 1491 1292 TATA Communications formerly 17488 1392 1287 Hathway IP Over Cable Interne 11492 1212 1201 Cable One 4323 1555 1183 Time Warner Telecom 8151 1397 1177 UniNet S.A. de C.V. 6478 1322 1125 AT&T Worldnet Services 18566 1059 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. Complete listing at http://thyme.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:18 /9:9 /10:17 /11:46 /12:148 /13:298 /14:538 /15:1065 /16:10122 /17:4401 /18:7639 /19:16422 /20:19306 /21:18769 /22:23822 /23:24789 /24:141736 /25:819 /26:995 /27:841 /28:90 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2852 4354 bellsouth.net, inc. 6298 1999 2025 Cox Communicatons 209 1781 3061 Qwest 2386 1269 1587 AT&T Data Communications Serv 11492 1188 1212 Cable One 17488 1183 1392 Hathway IP Over Cable Interne 1785 1157 1696 PaeTec Communications, Inc. 6478 1105 1322 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 974 1107 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:140 12:2179 13:2 15:21 16:3 17:5 20:35 24:1084 32:55 38:512 40:92 41:720 43:1 44:2 47:13 52:3 55:3 56:3 57:27 58:519 59:531 60:452 61:1030 62:1113 63:2035 64:3263 65:2432 66:3500 67:1284 68:805 69:2331 70:863 71:138 72:2055 73:7 74:1262 75:168 76:284 77:925 78:810 79:282 80:911 81:870 82:606 83:403 84:595 85:1039 86:508 87:693 88:344 89:1365 90:23 91:1608 92:287 93:955 94:267 95:3 96:80 97:111 98:360 99:13 113:26 114:114 115:127 116:994 117:382 118:238 119:512 120:95 121:608 122:849 123:465 124:862 125:1194 128:354 129:207 130:135 131:416 132:72 133:9 134:185 135:31 136:156 137:98 138:145 139:81 140:409 141:105 142:389 143:299 144:324 145:51 146:375 147:141 148:523 149:212 150:128 151:208 152:147 153:135 154:10 155:278 156:174 157:302 158:169 159:302 160:274 161:139 162:255 163:133 164:520 165:502 166:363 167:338 168:635 169:154 170:450 171:33 172:10 173:56 187:18 188:1 189:296 190:2315 192:5749 193:4160 194:3273 195:2618 196:1004 198:3714 199:3301 200:5546 201:1450 202:7762 203:8048 204:3919 205:2167 206:2285 207:2762 208:3720 209:3429 210:2574 211:1093 212:1545 213:1612 214:164 215:25 216:4428 217:1258 218:349 219:438 220:1056 221:417 222:300 End of report From Mark_Andrews at isc.org Fri Oct 24 17:43:18 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 25 Oct 2008 09:43:18 +1100 Subject: Alaska DNS In-Reply-To: Your message of "Fri, 24 Oct 2008 10:59:23 PDT." <785694cd0810241059q34195a9am4d9e867e13bcb0a0@mail.gmail.com> Message-ID: <200810242243.m9OMhIva090893@drugs.dv.isc.org> In message <785694cd0810241059q34195a9am4d9e867e13bcb0a0 at mail.gmail.com>, JoeSo x writes: > Is anyone else troubleshooting some Alaska domains the past two days? > ACS related? > > > > C:\Documents and Settings\Joseph>ping dowlandbach.com > > Pinging dowlandbach.com [209.112.129.41] with 32 bytes of data: > > Reply from 209.112.129.41: bytes=32 time=233ms TTL=45 > Reply from 209.112.129.41: bytes=32 time=235ms TTL=45 > Reply from 209.112.129.41: bytes=32 time=300ms TTL=45 > Reply from 209.112.129.41: bytes=32 time=252ms TTL=45 > > Ping statistics for 209.112.129.41: > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 233ms, Maximum = 300ms, Average = 255ms > > C:\Documents and Settings\Joseph>ping edc-alaska.com > Ping request could not find host edc-alaska.com. Please check the name and tr > y a > gain. So there are no address records. There doesn't have to be. If you think there is a problem contact dnsadmin at acsalaska.net P.S. using a tool that is designed to display the results of a DNS query is usually much better than using ping for DNS trouble shooting. Mark ; <<>> DiG 9.3.5-P2 <<>> any edc-alaska.com @ns4-auth.alaska.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59826 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 6 ;; QUESTION SECTION: ;edc-alaska.com. IN ANY ;; ANSWER SECTION: edc-alaska.com. 43200 IN SOA ns0.acsalaska.net. dnsadmin.acsalaska.net. 2008102400 28800 3600 1209600 43200 edc-alaska.com. 43200 IN NS ns1.acsalaska.net. edc-alaska.com. 43200 IN NS ns4.acsalaska.net. edc-alaska.com. 43200 IN NS ns3.acsalaska.net. edc-alaska.com. 43200 IN NS ns2.acsalaska.net. edc-alaska.com. 43200 IN MX 10 mail.edc-alaska.com. edc-alaska.com. 43200 IN MX 20 etrn.acsalaska.net. edc-alaska.com. 43200 IN TXT "$Id: edc-alaska.com.db,v 1.17 2007/07/21 00:01:02 kohfield Exp $" ;; ADDITIONAL SECTION: ns1.acsalaska.net. 43200 IN A 204.17.139.1 ns2.acsalaska.net. 43200 IN A 209.112.128.1 ns3.acsalaska.net. 43200 IN A 216.67.0.1 ns4.acsalaska.net. 43200 IN A 209.193.0.1 mail.edc-alaska.com. 43200 IN A 209.112.170.23 etrn.acsalaska.net. 43200 IN A 209.112.173.228 ;; Query time: 218 msec ;; SERVER: 209.193.0.1#53(209.193.0.1) ;; WHEN: Sat Oct 25 09:38:55 2008 ;; MSG SIZE rcvd: 381 > C:\Documents and Settings\Joseph>ping www.edc-alaska.com > > Pinging aws01.nwc.acsalaska.net [209.112.129.41] with 32 bytes of data: > > Reply from 209.112.129.41: bytes=32 time=251ms TTL=45 > Reply from 209.112.129.41: bytes=32 time=235ms TTL=45 > Reply from 209.112.129.41: bytes=32 time=247ms TTL=45 > Reply from 209.112.129.41: bytes=32 time=252ms TTL=45 > > Ping statistics for 209.112.129.41: > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 235ms, Maximum = 252ms, Average = 246ms > > C:\Documents and Settings\Joseph> > > -- > Later, Joe > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From markjr at easydns.com Fri Oct 24 17:54:17 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Fri, 24 Oct 2008 18:54:17 -0400 Subject: bellsouth.net postmaster anywhere? Message-ID: <49025219.90407@easydns.com> Is there a bellsouth.net postmaster anywhere? If you can contact me offlist, thx -mark -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From joesox at gmail.com Fri Oct 24 21:53:34 2008 From: joesox at gmail.com (JoeSox) Date: Fri, 24 Oct 2008 19:53:34 -0700 Subject: Alaska DNS In-Reply-To: <200810242243.m9OMhIva090893@drugs.dv.isc.org> References: <785694cd0810241059q34195a9am4d9e867e13bcb0a0@mail.gmail.com> <200810242243.m9OMhIva090893@drugs.dv.isc.org> Message-ID: <785694cd0810241953p71813826j1f7c8e1e55fbc210@mail.gmail.com> Thanks for everyone's help on and offlist. acsalaska.net told me just before I left the office 4 hours ago they have corrected the issues and time to clear cache. -- Later, Joe From lorell at hathcock.org Sat Oct 25 09:30:48 2008 From: lorell at hathcock.org (Lorell Hathcock) Date: Sat, 25 Oct 2008 09:30:48 -0500 Subject: Level 3 & Sprintlink contacts needed Message-ID: <00d301c936ae$465e62d0$d31b2870$@org> All: I need some help from Sprint and Level 3 network operators. Please contact me off list. Thanks! Lorell Hathcock From ops.lists at gmail.com Sat Oct 25 10:43:10 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 25 Oct 2008 21:13:10 +0530 Subject: Bank of America DNS contact anyone? Message-ID: Can someone please contact me offlist to troubleshoot a dns resolution issue between BofA and our domains? thanks --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From eugen at imacandi.net Sat Oct 25 11:25:22 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 25 Oct 2008 19:25:22 +0300 Subject: Alaska DNS In-Reply-To: <785694cd0810241953p71813826j1f7c8e1e55fbc210@mail.gmail.com> References: <785694cd0810241059q34195a9am4d9e867e13bcb0a0@mail.gmail.com> <200810242243.m9OMhIva090893@drugs.dv.isc.org> <785694cd0810241953p71813826j1f7c8e1e55fbc210@mail.gmail.com> Message-ID: <49034872.9010402@imacandi.net> JoeSox wrote: > Thanks for everyone's help on and offlist. > > acsalaska.net told me just before I left the office 4 hours ago they > have corrected the issues and time to clear cache. > Why was it an issue that they had no A records for the domain name ? From LarrySheldon at cox.net Sat Oct 25 11:57:54 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 25 Oct 2008 11:57:54 -0500 Subject: Alaska DNS In-Reply-To: <49034872.9010402@imacandi.net> References: <785694cd0810241059q34195a9am4d9e867e13bcb0a0@mail.gmail.com> <200810242243.m9OMhIva090893@drugs.dv.isc.org> <785694cd0810241953p71813826j1f7c8e1e55fbc210@mail.gmail.com> <49034872.9010402@imacandi.net> Message-ID: <49035012.3020003@cox.net> Eugeniu Patrascu wrote: > Why was it an issue that they had no A records for the domain name ? That question has intrigued me for years. I used to manage a network where were lots of labels in domain names e.g. a.b.c.example.com where only the machine "a" had addresses (the others may or may not have been associated with machines and hence IP addresses but not necessarily A RRs). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From alif.terranson at gmail.com Sun Oct 26 22:01:59 2008 From: alif.terranson at gmail.com (J.A. Terranson) Date: Sun, 26 Oct 2008 22:01:59 -0500 Subject: Nanog History In-Reply-To: References: Message-ID: And, as I said, you're a pathological liar, and everyone knows it: your IADL page is a testament to your illness. //Alif On Tue, Oct 21, 2008 at 4:44 PM, Dean Anderson wrote: > The net.trash is documented at http://www.iadl.org. You have a page > there for good reason. > > --Dean > > > On Sat, 18 Oct 2008, J.A. Terranson wrote: > >> On Thu, Oct 16, 2008 at 10:32 PM, Dean Anderson wrote: >> > On Thu, 16 Oct 2008, Dean Anderson wrote: >> >> > contains "So Harris banned me from NANOG." . Not sure if thats the >> >> > meeting, the NANOG list, or one of the NANOG/Merit other lists. >> >> >> >> The list, I don't know if this applies to meetings. >> > >> > The Jan 2000 ban also stopped my participation in RADB. Mail to all of >> > merit.edu was affected. I think this was to prevent me from emailing >> > Harris' boss---she hung up on me in a phone call when I asked who her >> > boss was. >> > >> > --Dean >> Well Dean, considering that you are a pathological liar (as well as >> an IP theif), I can certainly understand people being defensive around >> you. As to your non-participation in NANOG and related flora, >> remember that the Innernets are a *cooperative* being. Encouraging >> the participation of loose screws, cerebral derelicts, and other >> assorted net.trash such as yourself can only *improve* the quality of >> the venture. >> >> //Alif >> >> -- >> "Never belong to any party, always oppose privileged classes and public >> plunderers, never lack sympathy with the poor, always remain devoted to >> the public welfare, never be satisfied with merely printing news, always >> be drastically independent, never be afraid to attack wrong, whether by >> predatory plutocracy or predatory poverty." >> >> Joseph Pulitzer >> 1907 Speech >> >> >> > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > From iradsn09 at zju.edu.cn Sun Oct 26 23:30:11 2008 From: iradsn09 at zju.edu.cn (iradsn09 at zju.edu.cn) Date: Mon, 27 Oct 2008 12:30:11 +0800 Subject: Paper submission deadlines of IRADSN'09 have been extended References: <200810241611575315974@zju.edu.cn> Message-ID: <425080882.27838@zju.edu.cn> Dear Colleagues, Please accept our apologies if you receive multiple copies of this announcement. Due to numerous deadline extension requests from potential IRADSN 2009 authors, the IRADSN organizing committee has decided to extend the paper submission deadline to 11/15/2008. Please note that this is a hard deadline, so that the technical committees can perform their paper reviewing duties in a timely manner. Call for paper can be found in attachments. If you received this email in error, please forward it to the appropriate department at your institution. Please do not reply to this message. If you need to contact us please email us at iradsn09 at zju.edu.cn -------------- next part -------------- A non-text attachment was scrubbed... Name: cfp_iradsn09.pdf Type: application/octet-stream Size: 46428 bytes Desc: not available URL: From hcb at netcases.net Mon Oct 27 10:56:18 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Mon, 27 Oct 2008 11:56:18 -0400 Subject: Pointer to presentations on academic P2P traffic management? Message-ID: <39BF65DF7B924DADA776B92739AD6F0C@HDESK1> I was there. It was at NANOG that I saw good presentations on how academic operators handle P2P overloads in a fair way. Unfortunately, my wetware is not coming up with the when or the where of the there. Could anyone point me to the presentation(s)? Unicast is fine. Incidentally, this particular material is going into an article on P2P at http://www.citizendium.org , where I've started various articles on operational issues (as time permits). Participation is more than welcome! Howard From crogers at marchex.com Mon Oct 27 13:00:15 2008 From: crogers at marchex.com (Christopher Rogers) Date: Mon, 27 Oct 2008 11:00:15 -0700 Subject: philadelphia public internet exchange? Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50A24BB62@exchbe1sea.windows.marchex.com> What's the situation with the philadelphia internet exchange? Their website, www.phlix.net does not resolve. Google is sparse. Anyone have any information regarding that IX? Is it gone? If it's gone, what are some viable alternatives for public peering in the philadelphia area? Thanks kindly Chris Christopher Rogers Network Engineer - Marchex, Inc w:+1.206.331.3368 m:+1.206.234.1423 From ian at cymru.com Mon Oct 27 13:12:00 2008 From: ian at cymru.com (Ian Cook) Date: Mon, 27 Oct 2008 18:12:00 +0000 Subject: New service - the Team Cymru Malware Hash Registry! Message-ID: <49060470.7040402@cymru.com> Hi This email is to announce a new look-up service that Team Cymru is launching today. The Malware Hash Registry (MHR) service allows you to query our database of many millions of unique malware samples for a computed MD5 or SHA-1 hash of a file. If it is malware and we know about it, we return the last time we've seen it along with an approximate anti-virus detection percentage. THERE IS NO COST FOR NON-COMMERCIAL USE OF THIS TOOL. ACCESS IS PUBLICLY AVAILABLE TO ANYONE. Upon submission of a malware hash, the output of the command will return a date the sample was first seen as well as the detection rate we've seen using up to 30 AV packages. The detection rate is based on the first time we scanned the sample. Queries, including reasonable bulk queries, may be made using the command line only. The MHR compliments an anti-virus (AV) strategy by helping to identify unknown or suspicious files that we have already identified as malicious. This enables you to take action earlier than you would otherwise be able to. Full details including command syntax and procedures can be found at: https://www.team-cymru.org/Services/MHR/ This is one of several new (free) data sets and services we are currently providing to the community; if you haven't visited our (recently revamped) site recently please do so for details of the extensive work we do for the security community as well as further advice, data and tips to help you make your networks more secure: https://www.team-cymru.org/Services We very much look forward to working with you all on this new project and we sincerely hope that as many of you as possible will be able to actively participate in the use of this unique and very exciting new service. Warm regards, Team Cymru. From nanog-post at rsuc.gweep.net Mon Oct 27 13:14:49 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 27 Oct 2008 14:14:49 -0400 Subject: philadelphia public internet exchange? In-Reply-To: <9B4191CF8F73B04BB4F437E1F7F86ED50A24BB62@exchbe1sea.windows.marchex.com> References: <9B4191CF8F73B04BB4F437E1F7F86ED50A24BB62@exchbe1sea.windows.marchex.com> Message-ID: <20081027181449.GA77983@gweep.net> On Mon, Oct 27, 2008 at 11:00:15AM -0700, Christopher Rogers wrote: > What's the situation with the philadelphia internet exchange? Their > website, www.phlix.net does not resolve. Google is sparse. Anyone have > any information regarding that IX? Is it gone? If it's gone, what are > some viable alternatives for public peering in the philadelphia area? Historically, there hasn't been much traction beyond regional peering in Philadelphia. Last I knew, 401 North Broad was the only building with a useful confluence of carriers. According to peeringdb.com, S&D still has a colo & switch there, as does 'cross connect solutions'. The S&D site confirms the population (http://www.switchanddata.com/sitelocations.asp?LocationId=27) and that the more enterprise-colo on Market street is still running as well. For your I2/edu connbectivity, MAGPI has the bulk of their connectivity in 401 North Board. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jaw+nanog01 at tcp4me.com Mon Oct 27 16:17:29 2008 From: jaw+nanog01 at tcp4me.com (jaw+nanog01 at tcp4me.com) Date: Mon, 27 Oct 2008 17:17:29 -0400 (EDT) Subject: philadelphia public internet exchange? Message-ID: <200810272117.m9RLHTEj026280@athena.tcp4me.com> | What's the situation with the philadelphia internet exchange? Their | website, www.phlix.net does not resolve. Google is sparse. Anyone have | any information regarding that IX? Is it gone? If it's gone, what are | some viable alternatives for public peering in the philadelphia area? I started the project back in the mid/late 90s with big plans and dreams, but was never able to get enough other people interested. I'm no longer in the ISP business, and let the domain registration lapse. --jeff From frnkblk at iname.com Tue Oct 28 00:17:50 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 28 Oct 2008 00:17:50 -0500 Subject: New service - the Team Cymru Malware Hash Registry! In-Reply-To: <49060470.7040402@cymru.com> References: <49060470.7040402@cymru.com> Message-ID: Interesting idea -- two questions: a) Will Cymru be developing any plugins for sendmail and the like that facilitate Cymru's MHR to be queried? b) Is Cymru cooperating with VirusTotal on this project? They compute hashes, too, and it could be a data feed for Cymru's content Frank -----Original Message----- From: Ian Cook [mailto:ian at cymru.com] Sent: Monday, October 27, 2008 1:12 PM To: nanog at nanog.org Subject: New service - the Team Cymru Malware Hash Registry! Hi This email is to announce a new look-up service that Team Cymru is launching today. The Malware Hash Registry (MHR) service allows you to query our database of many millions of unique malware samples for a computed MD5 or SHA-1 hash of a file. If it is malware and we know about it, we return the last time we've seen it along with an approximate anti-virus detection percentage. THERE IS NO COST FOR NON-COMMERCIAL USE OF THIS TOOL. ACCESS IS PUBLICLY AVAILABLE TO ANYONE. Upon submission of a malware hash, the output of the command will return a date the sample was first seen as well as the detection rate we've seen using up to 30 AV packages. The detection rate is based on the first time we scanned the sample. Queries, including reasonable bulk queries, may be made using the command line only. The MHR compliments an anti-virus (AV) strategy by helping to identify unknown or suspicious files that we have already identified as malicious. This enables you to take action earlier than you would otherwise be able to. Full details including command syntax and procedures can be found at: https://www.team-cymru.org/Services/MHR/ This is one of several new (free) data sets and services we are currently providing to the community; if you haven't visited our (recently revamped) site recently please do so for details of the extensive work we do for the security community as well as further advice, data and tips to help you make your networks more secure: https://www.team-cymru.org/Services We very much look forward to working with you all on this new project and we sincerely hope that as many of you as possible will be able to actively participate in the use of this unique and very exciting new service. Warm regards, Team Cymru. From kris.foster at gmail.com Tue Oct 28 00:33:31 2008 From: kris.foster at gmail.com (kris foster) Date: Mon, 27 Oct 2008 22:33:31 -0700 Subject: [NANOG-announce] Mailing List Committee call for volunteers Message-ID: <06601251-EEAB-4811-91B8-36C6A205D69E@gmail.com> Hi Everyone The Mailing List Committee (MLC) is now seeking volunteers to fill two terms ending November 2010. Please send expressions of interest to admins at nanog.org by Monday, November 3rd. We aim to announce the new MLC members by Tuesday, November 11th. The current members of the MLC are Kris Foster, Simon Lyall, and Sue Joiner (Merit). David Barak and Tim Yocum currently hold the seats with expiring terms. The NANOG mailing list serves an important role in the community by providing a day-to-day forum for network operators. Participating in the MLC gives you the opportunity to make a noticeable contribution. The MLC is covered under section 7.1.2 of the NANOG Charter. If you have any questions about the MLC or its activities please contact admins at nanog.org . http://www.nanog.org/governance/charter/ Thanks Kris Foster MLC Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From robt at cymru.com Tue Oct 28 12:04:04 2008 From: robt at cymru.com (Rob Thomas) Date: Tue, 28 Oct 2008 12:04:04 -0500 Subject: New service - the Team Cymru Malware Hash Registry! In-Reply-To: References: <49060470.7040402@cymru.com> Message-ID: <49074604.9090006@cymru.com> Hi, Frank. > Interesting idea -- two questions: Thanks! > a) Will Cymru be developing any plugins for sendmail and the like that > facilitate Cymru's MHR to be queried? We've not done so, but it's an interesting idea. Would it make more sense to focus on a plugin for sundry anti-spam and anti-virus products instead? We have a few more services to release first, though, so stay tuned. :) > b) Is Cymru cooperating with VirusTotal on this project? They compute > hashes, too, and it could be a data feed for Cymru's content We work with with lots of folks, and are happy to work with even more. Introductions or suggestions are always welcome! Got a name or email address handy? Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From cmurray at apeman.org Tue Oct 28 12:18:57 2008 From: cmurray at apeman.org (Chris Murray) Date: Tue, 28 Oct 2008 10:18:57 -0700 Subject: Google Contact? Message-ID: <49074981.1030207@apeman.org> Hi All - I'm having an issue with Google at the moment, could somebody from google ping me off list? Thanks! -- Chris Murray Network Administrator Stargate Connections Inc. www.stargate.ca From frnkblk at iname.com Tue Oct 28 17:42:49 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 28 Oct 2008 17:42:49 -0500 Subject: New service - the Team Cymru Malware Hash Registry! In-Reply-To: <49074604.9090006@cymru.com> References: <49060470.7040402@cymru.com> <49074604.9090006@cymru.com> Message-ID: Yes, for antivirus checking. I can't direct you on how development on those plugins could be focused, but I'm sure there are listservs/people who could help you with that. I don't have any special inroads, but I'll send you the contact info for Virustotal offline. Frank -----Original Message----- From: Rob Thomas [mailto:robt at cymru.com] Sent: Tuesday, October 28, 2008 12:04 PM To: Frank Bulk Cc: ian at cymru.com; nanog at nanog.org Subject: Re: New service - the Team Cymru Malware Hash Registry! Hi, Frank. > Interesting idea -- two questions: Thanks! > a) Will Cymru be developing any plugins for sendmail and the like that > facilitate Cymru's MHR to be queried? We've not done so, but it's an interesting idea. Would it make more sense to focus on a plugin for sundry anti-spam and anti-virus products instead? We have a few more services to release first, though, so stay tuned. :) > b) Is Cymru cooperating with VirusTotal on this project? They compute > hashes, too, and it could be a data feed for Cymru's content We work with with lots of folks, and are happy to work with even more. Introductions or suggestions are always welcome! Got a name or email address handy? Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From warren at kumari.net Tue Oct 28 21:36:17 2008 From: warren at kumari.net (Warren Kumari) Date: Tue, 28 Oct 2008 22:36:17 -0400 Subject: Google Contact? In-Reply-To: <49074981.1030207@apeman.org> References: <49074981.1030207@apeman.org> Message-ID: <4E5F0849-7A9B-4D3C-9E37-0C3EAFFF7FAE@kumari.net> Hi, Has this been addressed? W On Oct 28, 2008, at 1:18 PM, Chris Murray wrote: > Hi All - > > I'm having an issue with Google at the moment, could somebody from > google ping me off list? > > Thanks! > > -- > Chris Murray > Network Administrator > Stargate Connections Inc. > www.stargate.ca > From smb at cs.columbia.edu Tue Oct 28 21:40:53 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 28 Oct 2008 22:40:53 -0400 Subject: Another driver for v6? Message-ID: <20081028224053.35f85438@cs.columbia.edu> According to http://www.nytimes.com/external/idg/2008/10/28/28idg-10-best-feature.html Windows 7 will have a cool feature called DirectAccess that "requires deploying IPv6 and IPsec". I know nothing more of this feature than is in the article, but if accurate it may create a client-centric demand for v6, i.e., desirable new functionality that isn't available on v4. Of course, Windows 7 will have to ship first, and then get deployed in the enterprise... --Steve Bellovin, http://www.cs.columbia.edu/~smb From warren at kumari.net Tue Oct 28 21:56:55 2008 From: warren at kumari.net (Warren Kumari) Date: Tue, 28 Oct 2008 22:56:55 -0400 Subject: Google Contact? In-Reply-To: <4E5F0849-7A9B-4D3C-9E37-0C3EAFFF7FAE@kumari.net> References: <49074981.1030207@apeman.org> <4E5F0849-7A9B-4D3C-9E37-0C3EAFFF7FAE@kumari.net> Message-ID: <1C4F4140-DF35-46E3-BE1F-438A9ABCD2EA@kumari.net> Warren would like to recall the message: Google Contact? because he didn't mean to click Reply All... Yup, it has been / is being addressed, and no, I don't really believe that the magic mail elves are going to go scrummaging around your mailboxes and delete the message... W On Oct 28, 2008, at 10:36 PM, Warren Kumari wrote: > Hi, > > Has this been addressed? > > W > On Oct 28, 2008, at 1:18 PM, Chris Murray wrote: > >> Hi All - >> >> I'm having an issue with Google at the moment, could somebody from >> google ping me off list? >> >> Thanks! >> >> -- >> Chris Murray >> Network Administrator >> Stargate Connections Inc. >> www.stargate.ca >> > > From nanog at daork.net Tue Oct 28 22:11:54 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 29 Oct 2008 16:11:54 +1300 Subject: Another driver for v6? In-Reply-To: <20081028224053.35f85438@cs.columbia.edu> References: <20081028224053.35f85438@cs.columbia.edu> Message-ID: On 29/10/2008, at 3:40 PM, Steven M. Bellovin wrote: > According to > http://www.nytimes.com/external/idg/2008/10/28/28idg-10-best-feature.html > Windows 7 will have a cool feature called DirectAccess that "requires > deploying IPv6 and IPsec". I know nothing more of this feature than > is > in the article, but if accurate it may create a client-centric demand > for v6, i.e., desirable new functionality that isn't available on v4. > > Of course, Windows 7 will have to ship first, and then get deployed in > the enterprise... Thanks, Teredo. Interesting point, IPSEC is really useful in IPv6, especially transport mode opportunistic encryption/authentication. But, that requires (in my understanding) keys in DNS, which really needs a secure DNS infrastructure to be, well, secure... stir stir stir Notice the DNSSEC support at the end of page one and beginning of page two. -- Nathan Ward From matthew at eeph.com Tue Oct 28 22:13:58 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Tue, 28 Oct 2008 20:13:58 -0700 Subject: Another driver for v6? In-Reply-To: References: <20081028224053.35f85438@cs.columbia.edu> Message-ID: <4907D4F6.7070508@eeph.com> Nathan Ward wrote: > On 29/10/2008, at 3:40 PM, Steven M. Bellovin wrote: > >> According to >> http://www.nytimes.com/external/idg/2008/10/28/28idg-10-best-feature.html >> Windows 7 will have a cool feature called DirectAccess that "requires >> deploying IPv6 and IPsec". ... > > > Thanks, Teredo. > > Interesting point, IPSEC is really useful in IPv6, especially transport > mode opportunistic encryption/authentication. But, that requires (in my > understanding) keys in DNS, which really needs a secure DNS > infrastructure to be, well, secure... > > ... The new UDP-based RTMFP protocol that just shipped in Flash Player 10 will automatically use IPv6 for both client-server (to Flash Media Server) and direct Flash Player-to-Flash Player communication if there is a working IPv6 path between the endpoints and it is at least as fast or faster than the IPv4 path latency-wise. (Not that there are many of those these days... but as they start to exist, you'll start seeing the traffic on them) It is also encrypted and (in some cases) authenticated. Matthew Kaufman matthew at eeph.com http://www.matthew.at From cmurray at apeman.org Tue Oct 28 23:10:54 2008 From: cmurray at apeman.org (Chris Murray) Date: Tue, 28 Oct 2008 21:10:54 -0700 Subject: Google Contact? In-Reply-To: <49074981.1030207@apeman.org> References: <49074981.1030207@apeman.org> Message-ID: <4907E24E.2050603@apeman.org> Thanks to all of those who replied. Google engineers corrected the issue very quickly. Cheers! Chris Murray wrote: > Hi All - > > I'm having an issue with Google at the moment, could somebody from > google ping me off list? > > Thanks! > > -- > Chris Murray > Network Administrator > Stargate Connections Inc. > www.stargate.ca From swmike at swm.pp.se Wed Oct 29 01:59:09 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 29 Oct 2008 07:59:09 +0100 (CET) Subject: Another driver for v6? In-Reply-To: <20081028224053.35f85438@cs.columbia.edu> References: <20081028224053.35f85438@cs.columbia.edu> Message-ID: On Tue, 28 Oct 2008, Steven M. Bellovin wrote: > Windows 7 will have a cool feature called DirectAccess that "requires > deploying IPv6 and IPsec". I know nothing more of this feature than is > in the article, but if accurate it may create a client-centric demand > for v6, i.e., desirable new functionality that isn't available on v4. Microsoft has been at at least two events I've attended and done presentations about a strategy that sounds like what you're talking about. They claim they will deploy IPv6 in their worldwide enterprise network, do away with central based enterprise firewalls and do host-to-host IPv6+IPSEC, Active Directory based certificates for authentication. They indicate this as a strategy to do away with VPN clients, so in order to reach your work resources from home you'd need to have some kind of IPv6 connectivity, tunneled or not. You'd then connect to all resources using IPv6 totally transparently to you. All security would be host based. I am quite impressed by this strategy as it re-implements the end-to-end principle of the Internet that most of us appreciate. I also bought their claim about much improved security and their 5 year long track of no remote exploits like Slammer, when they had to release their emergency patch for that RPC based remote exploit the other week, which kind of broke their streak... :P Let's hope they can sell this to all the enterprise guys, as I am very tired of all the problems caused by multiple layers of NATs and PAT. -- Mikael Abrahamsson email: swmike at swm.pp.se From brandon at rd.bbc.co.uk Wed Oct 29 02:53:56 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 29 Oct 2008 07:53:56 GMT Subject: Another driver for v6? Message-ID: <200810290753.HAA23823@sunf10.rd.bbc.co.uk> > They claim they will deploy IPv6 in their worldwide enterprise network, do > away with central based enterprise firewalls and do host-to-host > IPv6+IPSEC, Active Directory based certificates for authentication. That's why we end up breaking end to end, to cover up for stuff that exposes more than people are comfortable with > All security would be host based. Right, the last thing to trust based on experience so far First they need to get rid of all the bots and other malware before hosts can be trusted. > as I am very tired of all the problems caused by multiple > layers of NATs and PAT. Likewise but more because people keep designing stuff to try and force others to get rid of them, ignoring why they have them. brandon From leo.vegoda at icann.org Wed Oct 29 03:02:34 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 29 Oct 2008 01:02:34 -0700 Subject: 197/8 allocated to AfriNIC Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of one /8 IPv4 block to AfriNIC in October 2008: 197/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJCBdMvBLymJnAzRwRApYGAJ9DfmQ2fvbfMgCVW1M8ZfiMnqSvgACgrCha /biQ/NJ9HS09avyV3UTRlRY= =wQ6t -----END PGP SIGNATURE----- From ge at linuxbox.org Wed Oct 29 03:27:47 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 29 Oct 2008 03:27:47 -0500 (CDT) Subject: [funsec] ICANN Terminates EstDomains' Registrar Accreditation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Tue, 28 Oct 2008 20:47:48 -0700 From: Paul Ferguson To: funsec at linuxbox.org Subject: [funsec] ICANN Terminates EstDomains' Registrar Accreditation -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Dear Mr. Tsastsin, "Be advised that the Internet Corporation for Assigned Names and Numbers (ICANN) Registrar Accreditation Agreement (RAA) for EstDomains, Inc. (customer No. 919, IANA No. 943) is terminated..." Via ICANN.org: http://www.icann.org/correspondence/burnette-to-tsastsin-28oct08-en.pdf - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJB9zaq1pz9mNUZTMRAiNOAKCKGwfwxJxnCxR/5zo4wU77enGQRACeKCY7 Sc2Bwob4aRRtRocYArtoVtU= =ggSS -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list. From simon at darkmere.gen.nz Wed Oct 29 04:40:26 2008 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Wed, 29 Oct 2008 22:40:26 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also containers pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From karnaugh at karnaugh.za.net Wed Oct 29 05:38:56 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 29 Oct 2008 12:38:56 +0200 Subject: Comcast contact Message-ID: <49083D40.1020507@karnaugh.za.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I know NANOG hates these mails but they happen anyway.. I need someone at Comcast who can help with why their server is detecting a host (that is not blacklisted, senderbased or anything) as spam. The URL Comcast gives with the spam block message is invalid. I doubt I'll get action through their support channels either, and I can't even find a useful looking one of those on their website... As an asside - Just give out the darn reason or something, these generic "lol, spam" 554's are getting irritating Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCD1A0FZZWLfHKjURAtUVAKCCBOlagNibH3CxpqulqsHGC9NkRgCfZyDS HB/ol2oXItV7/abflfgJ1dw= =hhmn -----END PGP SIGNATURE----- From jbates at brightok.net Wed Oct 29 09:21:45 2008 From: jbates at brightok.net (Jack Bates) Date: Wed, 29 Oct 2008 09:21:45 -0500 Subject: Another driver for v6? In-Reply-To: <200810290753.HAA23823@sunf10.rd.bbc.co.uk> References: <200810290753.HAA23823@sunf10.rd.bbc.co.uk> Message-ID: <49087179.6090402@brightok.net> Brandon Butterworth wrote: >> as I am very tired of all the problems caused by multiple >> layers of NATs and PAT. > > Likewise but more because people keep designing stuff to try and force > others to get rid of them, ignoring why they have them. A false sense of security? The belief that hiding behind a single IP might disguise how many hosts you have, which in turn might provide some form of hidden security? Inside the network, host to host security is what should be. This can assist in some protection against bots that do make it to the network, or internal maliciousness. Security from within has always been overlooked by many, and yet it is the employees who provide the largest security risk. Stateful firewalls will not be going away entirely, but they can track state and perform proxy services without performing address translation. It just scares people because of their false belief that translating an address shows that security is working. If stateful monitoring/proxying/limiting is not in working, the address translation doesn't really matter. NAT has had it's uses, but it's lazy and a false sense of overall security. I do think Microsoft is crazy if they think the need for VPN will disappear, unless they have another method for the stateful firewalls to snoop, monitor, and alter the IPSEC host to host packets (which isn't entirely impossible). Jack Bates From jmaimon at ttec.com Wed Oct 29 10:32:39 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 29 Oct 2008 11:32:39 -0400 Subject: Another driver for v6? In-Reply-To: References: <20081028224053.35f85438@cs.columbia.edu> Message-ID: <49088217.3030501@ttec.com> Mikael Abrahamsson wrote: > On Tue, 28 Oct 2008, Steven M. Bellovin wrote: > > They claim they will deploy IPv6 in their worldwide enterprise network, > do away with central based enterprise firewalls and do host-to-host > IPv6+IPSEC, Active Directory based certificates for authentication. You know that windows 2000 was released with this functionality. Its nothing new and it is not ipv6 specific. Who is using it precisely? From gherbert at retro.com Wed Oct 29 12:39:21 2008 From: gherbert at retro.com (George William Herbert) Date: Wed, 29 Oct 2008 10:39:21 -0700 Subject: Current subscribe address for outages list? Message-ID: <200810291739.m9THdMAB023538@kw.retro.com> I am advised by someone that there's an OC3 out in California, now being discussed/announced on the outages list. I fell off the outages list, went to resubscribe, and the link at http://www.isotf.org/mailman/listinfo/outages ...doesn't appear to work. I don't see email after Gadi's from June saying that something was moving, with a new subscribe address... Where's the current one? Thanks! -george william herbert gherbert at retro.com From chaim.rieger at gmail.com Wed Oct 29 12:53:00 2008 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 29 Oct 2008 10:53:00 -0700 Subject: Current subscribe address for outages list? In-Reply-To: <200810291739.m9THdMAB023538@kw.retro.com> References: <200810291739.m9THdMAB023538@kw.retro.com> Message-ID: <4908A2FC.9050001@gmail.com> George William Herbert wrote: > I am advised by someone that there's an OC3 out in California, > now being discussed/announced on the outages list. > > I fell off the outages list, went to resubscribe, and the link at > http://www.isotf.org/mailman/listinfo/outages > > ...doesn't appear to work. I don't see email after Gadi's from > June saying that something was moving, with a new subscribe > address... > > Where's the current one? > > Thanks! > > > -george william herbert > gherbert at retro.com > > https://puck.nether.net/mailman/listinfo/outages -- -- Chaim Rieger From chaim.rieger at gmail.com Wed Oct 29 12:58:51 2008 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 29 Oct 2008 10:58:51 -0700 Subject: Current subscribe address for outages list? In-Reply-To: <200810291739.m9THdMAB023538@kw.retro.com> References: <200810291739.m9THdMAB023538@kw.retro.com> Message-ID: <4908A45B.9070808@gmail.com> George William Herbert wrote: > I am advised by someone that there's an OC3 out in California, > now being discussed/announced on the outages list. > > I fell off the outages list, went to resubscribe, and the link at > http://www.isotf.org/mailman/listinfo/outages > > ...doesn't appear to work. I don't see email after Gadi's from > June saying that something was moving, with a new subscribe > address... > > Where's the current one? > > Thanks! > > > -george william herbert > gherbert at retro.com > > actually nobody has posted any info about this other than what you just posted, no details/carrier/location etc..... -- -- Chaim Rieger From yahoo at jimpop.com Wed Oct 29 13:32:01 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Wed, 29 Oct 2008 14:32:01 -0400 Subject: Current subscribe address for outages list? In-Reply-To: <4908A45B.9070808@gmail.com> References: <200810291739.m9THdMAB023538@kw.retro.com> <4908A45B.9070808@gmail.com> Message-ID: <7ff145960810291132o65b3c617gd9769bb90bab91ef@mail.gmail.com> On Wed, Oct 29, 2008 at 13:58, Chaim Rieger wrote: > actually nobody has posted any info about this other than what you just > posted, no details/carrier/location etc..... Perhaps not on NANOG, but on the Outages list itself it was covered quite well. On 21-June-2008, RLVaughn posted to the outages at isotf.org list that the list would end in 12 to 18 hours and would move to a new host (un-identified at that time) On 23-June-2008, Jared Mauch posted the first post from the new Outages mailinglist host: https://puck.nether.net/pipermail/outages/2008-June/000749.html Also on 23-June-2008, virendra rode posted an updated message on the move: https://puck.nether.net/pipermail/outages/2008-June/000755.html To put simply, it seemed (to me) to be an urgent need for the move, and it was handled quickly and professionally by all those involved. -Jim P. From daniel at net2ez.com Wed Oct 29 13:56:01 2008 From: daniel at net2ez.com (Daniel Faubel) Date: Wed, 29 Oct 2008 11:56:01 -0700 Subject: Current subscribe address for outages list? In-Reply-To: <7ff145960810291132o65b3c617gd9769bb90bab91ef@mail.gmail.com> References: <200810291739.m9THdMAB023538@kw.retro.com><4908A45B.9070808@gmail.com> <7ff145960810291132o65b3c617gd9769bb90bab91ef@mail.gmail.com> Message-ID: I think Chaim was talking about the OC3 cut, not the list move. -Daniel -----Original Message----- From: Jim Popovitch [mailto:yahoo at jimpop.com] Sent: Wednesday, October 29, 2008 11:32 AM To: Chaim Rieger Cc: nanog at merit.edu; gherbert at kw.retro.com Subject: Re: Current subscribe address for outages list? On Wed, Oct 29, 2008 at 13:58, Chaim Rieger wrote: > actually nobody has posted any info about this other than what you just > posted, no details/carrier/location etc..... Perhaps not on NANOG, but on the Outages list itself it was covered quite well. On 21-June-2008, RLVaughn posted to the outages at isotf.org list that the list would end in 12 to 18 hours and would move to a new host (un-identified at that time) On 23-June-2008, Jared Mauch posted the first post from the new Outages mailinglist host: https://puck.nether.net/pipermail/outages/2008-June/000749.html Also on 23-June-2008, virendra rode posted an updated message on the move: https://puck.nether.net/pipermail/outages/2008-June/000755.html To put simply, it seemed (to me) to be an urgent need for the move, and it was handled quickly and professionally by all those involved. -Jim P. From pstewart at nexicomgroup.net Wed Oct 29 14:17:45 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 29 Oct 2008 15:17:45 -0400 Subject: Peering - Benefits? Message-ID: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> Hi there... I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges. Besides costs, what other factors are benefits to peering? I can think of some but looking to develop a concrete list of appealing reasons etc. such as: -control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance Just looking for other positive ideas etc...;) Cheers! Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From Valdis.Kletnieks at vt.edu Wed Oct 29 14:28:04 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 29 Oct 2008 15:28:04 -0400 Subject: Peering - Benefits? In-Reply-To: Your message of "Wed, 29 Oct 2008 15:17:45 EDT." <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> Message-ID: <23924.1225308484@turing-police.cc.vt.edu> On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > I can think of some but looking to develop a concrete list of appealing > reasons etc. such as: > > -control over routing between networks > -security aspect (being able to filter/verify routes to some degree) > -latency/performance I'm surprised you didn't include "chance to pick up a redundant connection". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From pstewart at nexicomgroup.net Wed Oct 29 15:04:27 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 29 Oct 2008 16:04:27 -0400 Subject: Peering - Benefits? In-Reply-To: <23924.1225308484@turing-police.cc.vt.edu> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Thanks! That's a really good one and surprised myself I missed it..;) _____________________________________________ From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog at nanog.org Subject: Re: Peering - Benefits? * PGP Signed by an unknown key On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > I can think of some but looking to develop a concrete list of appealing > reasons etc. such as: > > -control over routing between networks > -security aspect (being able to filter/verify routes to some degree) > -latency/performance I'm surprised you didn't include "chance to pick up a redundant connection". * Unknown Key * 0xB4D3D7B0 ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From sking at kingrst.com Wed Oct 29 17:22:13 2008 From: sking at kingrst.com (Steven King) Date: Wed, 29 Oct 2008 18:22:13 -0400 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <4908E215.504@kingrst.com> It would only be a redundant connection if the AS your peering with is a transit AS. The AS that I work with is a stub AS and can not function as a fully redundant link. Just something to watch out for. Paul Stewart wrote: > Thanks! That's a really good one and surprised myself I missed it..;) > > _____________________________________________ > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Wednesday, October 29, 2008 3:28 PM > To: Paul Stewart > Cc: nanog at nanog.org > Subject: Re: Peering - Benefits? > > > * PGP Signed by an unknown key > > On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > > >> I can think of some but looking to develop a concrete list of >> > appealing > >> reasons etc. such as: >> >> -control over routing between networks >> -security aspect (being able to filter/verify routes to some degree) >> -latency/performance >> > > I'm surprised you didn't include "chance to pick up a redundant > connection". > > * Unknown Key > * 0xB4D3D7B0 > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > -- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From pstewart at nexicomgroup.net Wed Oct 29 17:25:05 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 29 Oct 2008 18:25:05 -0400 Subject: Peering - Benefits? In-Reply-To: <4908E215.504@kingrst.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> <4908E215.504@kingrst.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B47532@nexus.nexicomgroup.net> Thanks - I believe the wording meant was "alternative path" versus connection... in other words if an AS has issues with one or more upstream providers for whatever reason, you have good chances the peering connection will remain in better shape (not always granted, but good odds).... Paul -----Original Message----- From: Steven King [mailto:sking at kingrst.com] Sent: October 29, 2008 6:22 PM To: Paul Stewart Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org Subject: Re: Peering - Benefits? It would only be a redundant connection if the AS your peering with is a transit AS. The AS that I work with is a stub AS and can not function as a fully redundant link. Just something to watch out for. Paul Stewart wrote: > Thanks! That's a really good one and surprised myself I missed it..;) > > _____________________________________________ > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Wednesday, October 29, 2008 3:28 PM > To: Paul Stewart > Cc: nanog at nanog.org > Subject: Re: Peering - Benefits? > > > * PGP Signed by an unknown key > > On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > > >> I can think of some but looking to develop a concrete list of >> > appealing > >> reasons etc. such as: >> >> -control over routing between networks >> -security aspect (being able to filter/verify routes to some degree) >> -latency/performance >> > > I'm surprised you didn't include "chance to pick up a redundant > connection". > > * Unknown Key > * 0xB4D3D7B0 > > > > > > > ------------------------------------------------------------------------ ---- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > -- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From sking at kingrst.com Wed Oct 29 17:26:35 2008 From: sking at kingrst.com (Steven King) Date: Wed, 29 Oct 2008 18:26:35 -0400 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B47532@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> <4908E215.504@kingrst.com> <89D27DE3375BB6428DDCC2927489826A01B47532@nexus.nexicomgroup.net> Message-ID: <4908E31B.7000303@kingrst.com> But if that AS is a stub, you still can't use their up stream providers to get data out to the rest of the world. It still wouldn't even function as an "alternative path" it would only function for the subnets which that AS owns. Paul Stewart wrote: > Thanks - I believe the wording meant was "alternative path" versus > connection... in other words if an AS has issues with one or more > upstream providers for whatever reason, you have good chances the > peering connection will remain in better shape (not always granted, but > good odds).... > > Paul > > > -----Original Message----- > From: Steven King [mailto:sking at kingrst.com] > Sent: October 29, 2008 6:22 PM > To: Paul Stewart > Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org > Subject: Re: Peering - Benefits? > > It would only be a redundant connection if the AS your peering with is a > transit AS. The AS that I work with is a stub AS and can not function as > a fully redundant link. > > Just something to watch out for. > > Paul Stewart wrote: > >> Thanks! That's a really good one and surprised myself I missed it..;) >> >> _____________________________________________ >> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >> Sent: Wednesday, October 29, 2008 3:28 PM >> To: Paul Stewart >> Cc: nanog at nanog.org >> Subject: Re: Peering - Benefits? >> >> >> * PGP Signed by an unknown key >> >> On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: >> >> >> >>> I can think of some but looking to develop a concrete list of >>> >>> >> appealing >> >> >>> reasons etc. such as: >>> >>> -control over routing between networks >>> -security aspect (being able to filter/verify routes to some degree) >>> -latency/performance >>> >>> >> I'm surprised you didn't include "chance to pick up a redundant >> connection". >> >> * Unknown Key >> * 0xB4D3D7B0 >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------ > ---- > >> "The information transmitted is intended only for the person or entity >> > to which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all > attachments, without copying, distributing or disclosing same. Thank > you." > >> >> > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From bruce.curtis at ndsu.edu Wed Oct 29 17:29:20 2008 From: bruce.curtis at ndsu.edu (Bruce Curtis) Date: Wed, 29 Oct 2008 17:29:20 -0500 Subject: Another driver for v6? In-Reply-To: <49088217.3030501@ttec.com> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> Message-ID: <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> On Oct 29, 2008, at 10:32 AM, Joe Maimon wrote: > > > Mikael Abrahamsson wrote: >> On Tue, 28 Oct 2008, Steven M. Bellovin wrote: > >> They claim they will deploy IPv6 in their worldwide enterprise >> network, do away with central based enterprise firewalls and do >> host-to-host IPv6+IPSEC, Active Directory based certificates for >> authentication. > > You know that windows 2000 was released with this functionality. Its > nothing new and it is not ipv6 specific. > > Who is using it precisely? Microsoft, on 200,000 computers at the time of the paper below. http://technet.microsoft.com/en-us/library/bb735174.aspx We have a couple of departments using IPsec here and one more seriously looking at it. (Mainly a matter of finding time to test and implement.) Plus there are at least a couple of other Universities. http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=14258&LanguageID=1 https://members.microsoft.com/customerevidence/search/EvidenceDetails.aspx?EvidenceID=14205&LanguageID=1 And I see a City has been added to the list. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000161 http://www.cu.ipv6tf.org/pdf/v6security_6Sense_Jan2006.pdf --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From sking at kingrst.com Wed Oct 29 17:32:31 2008 From: sking at kingrst.com (Steven King) Date: Wed, 29 Oct 2008 18:32:31 -0400 Subject: Another driver for v6? In-Reply-To: <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> Message-ID: <4908E47F.2080109@kingrst.com> Kind of a side question but we have not implemented IPv6 in our network yet, nor have we made any plans to do this in the near future. Our management does not see a need for it as our customer base is not requesting it at this time. Does anyone see any benefits to beginning a small deployment of IPv6 now even if its just for internal usage? Bruce Curtis wrote: > > On Oct 29, 2008, at 10:32 AM, Joe Maimon wrote: > >> >> >> Mikael Abrahamsson wrote: >>> On Tue, 28 Oct 2008, Steven M. Bellovin wrote: >> >>> They claim they will deploy IPv6 in their worldwide enterprise >>> network, do away with central based enterprise firewalls and do >>> host-to-host IPv6+IPSEC, Active Directory based certificates for >>> authentication. >> >> You know that windows 2000 was released with this functionality. Its >> nothing new and it is not ipv6 specific. >> >> Who is using it precisely? > > Microsoft, on 200,000 computers at the time of the paper below. > > http://technet.microsoft.com/en-us/library/bb735174.aspx > > We have a couple of departments using IPsec here and one more > seriously looking at it. (Mainly a matter of finding time to test and > implement.) > > Plus there are at least a couple of other Universities. > > http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=14258&LanguageID=1 > > > https://members.microsoft.com/customerevidence/search/EvidenceDetails.aspx?EvidenceID=14205&LanguageID=1 > > > And I see a City has been added to the list. > > http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000161 > > > > > http://www.cu.ipv6tf.org/pdf/v6security_6Sense_Jan2006.pdf > > > --- > Bruce Curtis bruce.curtis at ndsu.edu > Certified NetAnalyst II 701-231-8527 > North Dakota State University > > -- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From ge at linuxbox.org Wed Oct 29 17:33:47 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 29 Oct 2008 17:33:47 -0500 (CDT) Subject: Current subscribe address for outages list? In-Reply-To: <4908A45B.9070808@gmail.com> References: <200810291739.m9THdMAB023538@kw.retro.com> <4908A45B.9070808@gmail.com> Message-ID: > actually nobody has posted any info about this other than what you just > posted, no details/carrier/location etc..... Jared was kind enough to take the hosting load, and the list is now hosted there. Also, following discussions on nanog-futures I removed myself as moderator, so that we can concentrate on the list rather than me. Check out wwww.outages.org Gadi. From ge at linuxbox.org Wed Oct 29 17:41:11 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 29 Oct 2008 17:41:11 -0500 (CDT) Subject: Current subscribe address for outages list? In-Reply-To: References: <200810291739.m9THdMAB023538@kw.retro.com> <4908A45B.9070808@gmail.com> Message-ID: On Wed, 29 Oct 2008, Gadi Evron wrote: >> actually nobody has posted any info about this other than what you just >> posted, no details/carrier/location etc..... > > Jared was kind enough to take the hosting load, and the list is now hosted > there. > > Also, following discussions on nanog-futures I removed myself as moderator, > so that we can concentrate on the list rather than me. > > Check out wwww.outages.org Sorry, http://www.outages.org/ > Gadi. > From nanog at daork.net Wed Oct 29 17:41:34 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 30 Oct 2008 11:41:34 +1300 Subject: Another driver for v6? In-Reply-To: <4908E47F.2080109@kingrst.com> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> Message-ID: <95EAF749-2EE9-4E61-A516-7AF7DB4AC247@daork.net> On 30/10/2008, at 11:32 AM, Steven King wrote: > Kind of a side question but we have not implemented IPv6 in our > network > yet, nor have we made any plans to do this in the near future. Our > management does not see a need for it as our customer base is not > requesting it at this time. > > Does anyone see any benefits to beginning a small deployment of IPv6 > now > even if its just for internal usage? Do your customers ask for IPv4, or do they just connect to the "Internet" as you tell them? Your customers are never going to ask, unless they have some propeller- head who wants to be on the latest "version of the Internet". If you tell them that you're giving them IPv6 service, you'll find they start using it, and they'll ask other providers for it when re- evaluating their service providers, and decide to stick with you as you're forward looking and all that stuff. I'm so over this chicken/egg thing it's not even funny, just do it already. Well, if you don't it's no problem I suppose, your users are automatically tunnelling across you already. If you're only thinking about doing a small IPv6 deployment now, you're behind the curve. -- Nathan Ward From isabeldias1 at yahoo.com Wed Oct 29 17:42:19 2008 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 29 Oct 2008 15:42:19 -0700 (PDT) Subject: Peering - Benefits? Message-ID: <253097.8104.qm@web52601.mail.re2.yahoo.com> "chance to pick up a redundant connection". Well, traffic will have chances to pick up an alternative AS path - mesh peering (at the public IX). Also go via the redundant physical link if you have one agreed w/ ure peering point, or just take the best egress path via the (or one of the )transit connection(s). Why don't you just go privatly? --- On Wed, 10/29/08, Steven King wrote: > From: Steven King > Subject: Re: Peering - Benefits? > To: "Paul Stewart" > Cc: nanog at nanog.org > Date: Wednesday, October 29, 2008, 11:22 PM > It would only be a redundant connection if the AS your > peering with is a > transit AS. The AS that I work with is a stub AS and can > not function as > a fully redundant link. > > Just something to watch out for. > > Paul Stewart wrote: > > Thanks! That's a really good one and surprised > myself I missed it..;) > > > > _____________________________________________ > > From: Valdis.Kletnieks at vt.edu > [mailto:Valdis.Kletnieks at vt.edu] > > Sent: Wednesday, October 29, 2008 3:28 PM > > To: Paul Stewart > > Cc: nanog at nanog.org > > Subject: Re: Peering - Benefits? > > > > > > * PGP Signed by an unknown key > > > > On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > > > > > >> I can think of some but looking to develop a > concrete list of > >> > > appealing > > > >> reasons etc. such as: > >> > >> -control over routing between networks > >> -security aspect (being able to filter/verify > routes to some degree) > >> -latency/performance > >> > > > > I'm surprised you didn't include "chance > to pick up a redundant > > connection". > > > > * Unknown Key > > * 0xB4D3D7B0 > > > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > "The information transmitted is intended only for > the person or entity to which it is addressed and contains > confidential and/or privileged material. If you received > this in error, please contact the sender immediately and > then destroy this transmission, including all attachments, > without copying, distributing or disclosing same. Thank > you." > > > > -- > Steve King > > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional From isabeldias1 at yahoo.com Wed Oct 29 17:45:23 2008 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 29 Oct 2008 15:45:23 -0700 (PDT) Subject: Another driver for v6? In-Reply-To: <4908E47F.2080109@kingrst.com> Message-ID: <168150.10729.qm@web52601.mail.re2.yahoo.com> question - "beginning a small deployment of IPv6 now even if its just for internal usage" Sure! there are plenty of reasons .........most obvious one is to feel confortable about ipv6 --- On Wed, 10/29/08, Steven King wrote: > From: Steven King > Subject: Re: Another driver for v6? > To: "Bruce Curtis" > Cc: nanog at nanog.org > Date: Wednesday, October 29, 2008, 11:32 PM > Kind of a side question but we have not implemented IPv6 in > our network > yet, nor have we made any plans to do this in the near > future. Our > management does not see a need for it as our customer base > is not > requesting it at this time. > > Does anyone see any benefits to beginning a small > deployment of IPv6 now > even if its just for internal usage? > > Bruce Curtis wrote: > > > > On Oct 29, 2008, at 10:32 AM, Joe Maimon wrote: > > > >> > >> > >> Mikael Abrahamsson wrote: > >>> On Tue, 28 Oct 2008, Steven M. Bellovin wrote: > >> > >>> They claim they will deploy IPv6 in their > worldwide enterprise > >>> network, do away with central based enterprise > firewalls and do > >>> host-to-host IPv6+IPSEC, Active Directory > based certificates for > >>> authentication. > >> > >> You know that windows 2000 was released with this > functionality. Its > >> nothing new and it is not ipv6 specific. > >> > >> Who is using it precisely? > > > > Microsoft, on 200,000 computers at the time of the > paper below. > > > > > http://technet.microsoft.com/en-us/library/bb735174.aspx > > > > We have a couple of departments using IPsec here and > one more > > seriously looking at it. (Mainly a matter of finding > time to test and > > implement.) > > > > Plus there are at least a couple of other > Universities. > > > > > http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=14258&LanguageID=1 > > > > > > > https://members.microsoft.com/customerevidence/search/EvidenceDetails.aspx?EvidenceID=14205&LanguageID=1 > > > > > > And I see a City has been added to the list. > > > > > http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000161 > > > > > > > > > > > http://www.cu.ipv6tf.org/pdf/v6security_6Sense_Jan2006.pdf > > > > > > --- > > Bruce Curtis > bruce.curtis at ndsu.edu > > Certified NetAnalyst II 701-231-8527 > > North Dakota State University > > > > > > -- > Steve King > > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional From sking at kingrst.com Wed Oct 29 17:48:50 2008 From: sking at kingrst.com (Steven King) Date: Wed, 29 Oct 2008 18:48:50 -0400 Subject: Another driver for v6? In-Reply-To: <168150.10729.qm@web52601.mail.re2.yahoo.com> References: <168150.10729.qm@web52601.mail.re2.yahoo.com> Message-ID: <4908E852.4040303@kingrst.com> I personally agree with that. Now only if I can convince our management to start work on that. isabel dias wrote: > question - "beginning a small deployment of IPv6 now > even if its just for internal usage" > > > Sure! there are plenty of reasons .........most obvious one is to feel confortable about ipv6 > > > > > --- On Wed, 10/29/08, Steven King wrote: > > >> From: Steven King >> Subject: Re: Another driver for v6? >> To: "Bruce Curtis" >> Cc: nanog at nanog.org >> Date: Wednesday, October 29, 2008, 11:32 PM >> Kind of a side question but we have not implemented IPv6 in >> our network >> yet, nor have we made any plans to do this in the near >> future. Our >> management does not see a need for it as our customer base >> is not >> requesting it at this time. >> >> Does anyone see any benefits to beginning a small >> deployment of IPv6 now >> even if its just for internal usage? >> >> Bruce Curtis wrote: >> >>> On Oct 29, 2008, at 10:32 AM, Joe Maimon wrote: >>> >>> >>>> Mikael Abrahamsson wrote: >>>> >>>>> On Tue, 28 Oct 2008, Steven M. Bellovin wrote: >>>>> >>>>> They claim they will deploy IPv6 in their >>>>> >> worldwide enterprise >> >>>>> network, do away with central based enterprise >>>>> >> firewalls and do >> >>>>> host-to-host IPv6+IPSEC, Active Directory >>>>> >> based certificates for >> >>>>> authentication. >>>>> >>>> You know that windows 2000 was released with this >>>> >> functionality. Its >> >>>> nothing new and it is not ipv6 specific. >>>> >>>> Who is using it precisely? >>>> >>> Microsoft, on 200,000 computers at the time of the >>> >> paper below. >> >>> >>> >> http://technet.microsoft.com/en-us/library/bb735174.aspx >> >>> We have a couple of departments using IPsec here and >>> >> one more >> >>> seriously looking at it. (Mainly a matter of finding >>> >> time to test and >> >>> implement.) >>> >>> Plus there are at least a couple of other >>> >> Universities. >> >>> >> http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=14258&LanguageID=1 >> >>> >>> >> https://members.microsoft.com/customerevidence/search/EvidenceDetails.aspx?EvidenceID=14205&LanguageID=1 >> >>> And I see a City has been added to the list. >>> >>> >>> >> http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000161 >> >>> >>> >>> >>> >> http://www.cu.ipv6tf.org/pdf/v6security_6Sense_Jan2006.pdf >> >>> --- >>> Bruce Curtis >>> >> bruce.curtis at ndsu.edu >> >>> Certified NetAnalyst II 701-231-8527 >>> North Dakota State University >>> >>> >>> >> -- >> Steve King >> >> Cisco Certified Network Associate >> CompTIA Linux+ Certified Professional >> CompTIA A+ Certified Professional >> > > > > -- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From nanog at daork.net Wed Oct 29 17:58:43 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 30 Oct 2008 11:58:43 +1300 Subject: Another driver for v6? In-Reply-To: <4908E852.4040303@kingrst.com> References: <168150.10729.qm@web52601.mail.re2.yahoo.com> <4908E852.4040303@kingrst.com> Message-ID: On 30/10/2008, at 11:48 AM, Steven King wrote: > I personally agree with that. Now only if I can convince our > management > to start work on that. > > isabel dias wrote: >> question - "beginning a small deployment of IPv6 now >> even if its just for internal usage" >> >> >> Sure! there are plenty of reasons .........most obvious one is to >> feel confortable about ipv6 >> Another related good reason is so that in 18 months when they decide they need it done last week, contractors like myself don't charge you through the nose to implement it because management wouldn't let you guys skill up on a test network now. That makes it a monetary thing, something they understand better perhaps.. Yep, this post is going against my best instincts. -- Nathan Ward From David_Hankins at isc.org Wed Oct 29 18:29:40 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Wed, 29 Oct 2008 16:29:40 -0700 Subject: Another driver for v6? In-Reply-To: <4908E47F.2080109@kingrst.com> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> Message-ID: <20081029232940.GC5212@isc.org> On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: > Does anyone see any benefits to beginning a small deployment of IPv6 now > even if its just for internal usage? It is almost lunacy to deploy IPv6 in a customer-facing sense (note for example Google's choice to put its AAAA on a separate FQDN). At this point, I'd say people are still trying to figure out how clients will migrate to IPv6. Which seems like a pretty bad time to still be trying to figure that out, but ohwell. It is at this time more a question of strategic positioning. The kind of thing your boss should be thinking about. Switching your management network to IPv6 single-stack frees up IPv4 addresses (depending on how big your management network is) to use in customer-facing areas, which gives your network longer legs in the projected IPv4 address shortfall. If you get really pressed, you can tunnel your IPv4 network over an IPv6-only backbone, giving you another handful of precious moneymaking IPv4 addresses. Having your backbone and servers AAAA'd (even on separate FQDN's), tested, and ready to go puts you ahead of the curve if clients start rolling out (you can just move your AAAA's around). Starting now on collecting IPv6 peering wherever you peer puts you ahead of the curve in the quality of your network's connectedness, again presuming this IPv6 thing takes off. And of course you need to "run your own dog food" on internal LANs before you start telling customers these IPv6 address thingies are useful. IPv6: It's kind of like storing dry food in preparation for the apocalypse. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From smb at cs.columbia.edu Wed Oct 29 20:10:41 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 29 Oct 2008 21:10:41 -0400 Subject: Another driver for v6? In-Reply-To: <20081029232940.GC5212@isc.org> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> Message-ID: <20081029211041.63b07c73@cs.columbia.edu> On Wed, 29 Oct 2008 16:29:40 -0700 "David W. Hankins" wrote: > On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: > > Does anyone see any benefits to beginning a small deployment of > > IPv6 now even if its just for internal usage? > > It is almost lunacy to deploy IPv6 in a customer-facing sense (note > for example Google's choice to put its AAAA on a separate FQDN). At > this point, I'd say people are still trying to figure out how clients > will migrate to IPv6. Which seems like a pretty bad time to still be > trying to figure that out, but ohwell. > Once, after hearing Vint Cerf give a cheerleading talk for v6, I asked why google.com didn't have a AAAA record. He just groaned -- but of course I knew the answer just as well as he did. > > It is at this time more a question of strategic positioning. The > kind of thing your boss should be thinking about. > > Switching your management network to IPv6 single-stack frees up > IPv4 addresses (depending on how big your management network is) > to use in customer-facing areas, which gives your network longer > legs in the projected IPv4 address shortfall. If you get really > pressed, you can tunnel your IPv4 network over an IPv6-only backbone, > giving you another handful of precious moneymaking IPv4 addresses. > > Having your backbone and servers AAAA'd (even on separate FQDN's), > tested, and ready to go puts you ahead of the curve if clients start > rolling out (you can just move your AAAA's around). > > Starting now on collecting IPv6 peering wherever you peer puts you > ahead of the curve in the quality of your network's connectedness, > again presuming this IPv6 thing takes off. > > And of course you need to "run your own dog food" on internal LANs > before you start telling customers these IPv6 address thingies are > useful. > > > IPv6: It's kind of like storing dry food in preparation for the > apocalypse. > I'd rate the probability of v6 as rather higher... More seriously -- you need to get experience with it, and you need to at least understand where your internal support systems and databases have v4-only wired in. I'm not saying that substantial, real-world demand for v6 is imminent or even certain (although frankly, I regard it as more likely than not). I am saying that the probability of it is high enough that preparation is simply ordinary prudence. I posted the story link because for the first time since v6 was real, there's a *feature* that people will want that relies on it. Never mind lots of addresses; you can't easily sell that to management. But something that will make security management easier and cheaper -- you may be able to avoid triangle routing, with the consequent need for bigger pipes -- is a story they'll understand. You want to be ready to serve those customers. --Steve Bellovin, http://www.cs.columbia.edu/~smb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 304 bytes Desc: not available URL: From randy at psg.com Thu Oct 30 00:10:32 2008 From: randy at psg.com (Randy Bush) Date: Thu, 30 Oct 2008 09:10:32 +0400 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> Message-ID: <490941C8.1090201@psg.com> allows geeks to go on junkets almost as cool as droids get From nanog-post at rsuc.gweep.net Thu Oct 30 00:22:46 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 30 Oct 2008 01:22:46 -0400 Subject: Peering - Benefits? In-Reply-To: <23924.1225308484@turing-police.cc.vt.edu> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> Message-ID: <20081030052246.GA5261@gweep.net> On Wed, Oct 29, 2008 at 03:28:04PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > > > I can think of some but looking to develop a concrete list of appealing > > reasons etc. such as: > > > > -control over routing between networks > > -security aspect (being able to filter/verify routes to some degree) > > -latency/performance > > I'm surprised you didn't include "chance to pick up a redundant connection". ...specifically, in non-carrier-owned colos you have a better chance of factoring out loop costs for pricing decisions. A couple to add: - failure scoping: issues on a remote network can be better isolated from the rest of your traffic (or completely if it is the peer). - product variation: if you sell connectivity, a different/diverse/rich set of paths to offfer your downstreams is a win. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From swmike at swm.pp.se Thu Oct 30 02:10:26 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 30 Oct 2008 08:10:26 +0100 (CET) Subject: Another driver for v6? In-Reply-To: <20081029232940.GC5212@isc.org> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> Message-ID: On Wed, 29 Oct 2008, David W. Hankins wrote: > On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: >> Does anyone see any benefits to beginning a small deployment of IPv6 now >> even if its just for internal usage? > > It is almost lunacy to deploy IPv6 in a customer-facing sense (note > for example Google's choice to put its AAAA on a separate FQDN). At Could you please elaborate on this point? My data presented indicates that there are very very few (the longer I collected the data, the better the ratio got) who cannot properly fetch a resource that has A/AAAA. > this point, I'd say people are still trying to figure out how clients > will migrate to IPv6. Which seems like a pretty bad time to still be > trying to figure that out, but ohwell. 6to4 and Teredo traffic is increasing very rapidly, so that seems to be one path taken right now: (We have all our IPv6 related stats and info on ) But yes, how to get native to residential users is still not hammered out. > And of course you need to "run your own dog food" on internal LANs > before you start telling customers these IPv6 address thingies are > useful. Quite, I think OSS/BSS is going to be a bigger challenge than actually moving the IPv6 packets. > IPv6: It's kind of like storing dry food in preparation for the > apocalypse. If you actually KNOW the apocalypse is coming (but not when), this is correct. -- Mikael Abrahamsson email: swmike at swm.pp.se From mmc at internode.com.au Thu Oct 30 03:14:01 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 30 Oct 2008 18:44:01 +1030 Subject: Peering - Benefits? In-Reply-To: <20081030052246.GA5261@gweep.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <20081030052246.GA5261@gweep.net> Message-ID: <49096CC9.6090005@internode.com.au> Joe Provo wrote: > > > A couple to add: > - failure scoping: issues on a remote network can be better isolated > from the rest of your traffic (or completely if it is the peer). > Related to this is ability to contact the right people more quickly. If you've got a problem with/on someone's network then typically you can call their NOC directly. Compared with having to bounce through your transit providers helpdesk, who then escalate to their NOC, to the other NOC etc. This right is usually enshrined in most people's peering policy requirements. It's a powerful thing and not to be underestimated. MMC From mmc at internode.com.au Thu Oct 30 03:23:40 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 30 Oct 2008 18:53:40 +1030 Subject: Another driver for v6? In-Reply-To: References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> Message-ID: <49096F0C.1030703@internode.com.au> Mikael Abrahamsson wrote: > But yes, how to get native to residential users is still not hammered > out. It's been an issuing weighing our our minds for a while. We've gone dual stack but getting it into the last mile (ADSL) is quite hard and running a tunnel server is ugly. Main issue is BRAS support from our vendor as well as ADSL CPE under US$100 (eg. not Cisco 8xx series). > Quite, I think OSS/BSS is going to be a bigger challenge than actually > moving the IPv6 packets. Moving packets is pretty easy. We went to dual stack in the core in just a couple of months for a network spanning 3 continents. Getting our customer management systems and BRASes talking IPv6 is going to take a lot longer. Getting our systems group to IPv6 enable resolvers, dns etc is also taking longer than it should. MMC From michael.dillon at bt.com Thu Oct 30 05:28:06 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 30 Oct 2008 10:28:06 -0000 Subject: Another driver for v6? In-Reply-To: <4908E47F.2080109@kingrst.com> Message-ID: > Does anyone see any benefits to beginning a small deployment > of IPv6 now even if its just for internal usage? According to you should deploy some IPv6 transition technology to make sure that your network does not cause problems for the growing number of your customers who are already using IPv6. Of course, getting up to speed on IPv6 is also a worthy goal especially since it enables you to move much more quickly if IPv6 takes off suddenly. --Michael Dillon From ford at isoc.org Thu Oct 30 05:39:06 2008 From: ford at isoc.org (Matthew Ford) Date: Thu, 30 Oct 2008 10:39:06 +0000 Subject: Another driver for v6? In-Reply-To: References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> Message-ID: <49098ECA.4090901@isoc.org> On 30/10/08 07:10, Mikael Abrahamsson wrote: > On Wed, 29 Oct 2008, David W. Hankins wrote: > >> On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: >>> Does anyone see any benefits to beginning a small deployment of IPv6 now >>> even if its just for internal usage? >> >> It is almost lunacy to deploy IPv6 in a customer-facing sense (note >> for example Google's choice to put its AAAA on a separate FQDN). At > > Could you please elaborate on this point? My data presented > indicates > that there are very very few (the longer I collected the data, the > better the ratio got) who cannot properly fetch a resource that has A/AAAA. Your stats (which are very interesting btw, thanks for doing the work) suggest that the number of clients that would make use of the AAAA record for a dual-stack service is about the same as the number of clients that would fail in the event that both A and AAAA were present. That's not exactly an incentive to content providers is it? >> IPv6: It's kind of like storing dry food in preparation for the >> apocalypse. > > If you actually KNOW the apocalypse is coming (but not when), this is > correct. The end is nigh - http://penrose.uk6x.com/ Mat From michael.dillon at bt.com Thu Oct 30 05:45:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 30 Oct 2008 10:45:10 -0000 Subject: Another driver for v6? In-Reply-To: <20081029232940.GC5212@isc.org> Message-ID: > It is almost lunacy to deploy IPv6 in a customer-facing sense > (note for example Google's choice to put its AAAA on a > separate FQDN). If you're going to use emotionally charged language then don't shoot yourself in the foot by using such an illogical and contrary example. Google is a very big network-oriented company and they have indeed deployed IPv6 in a customer-facing sense. To follow in their footsteps is not lunacy. They have shown that when you have a large distributed load-sharing platform, it is perfectly safe to deploy IPv6 as an alternate service entry point, in the same way that they have mail.google.com and docs.google as separate service entry points. Most people who are urging ISPs to deploy IPv6 are not telling them to do stupid things like run out and add AAAA records to all their domain names. We are telling people to trial and test IPv6 in the lab, and then roll out specific targeted IPv6 services like a 6to4 relay. Above all, don't be a lunatic, and do educate yourself and your staff before you make a move. IPv6 deployment is not a greenfield deployment so you have to weave it into the fabric of your own unique network architecture. That requires understanding of IPv6 which you can only get by trying it out yourself in your lab environment. > At this point, I'd say people are still > trying to figure out how clients will migrate to IPv6. That is a pretty dumb thing to do. Clients have already migrated to IPv6 years ago using the technology given to them by Apple, Microsoft and the free UNIXes. Job 1 is to support those clients. Job 2 is to figure out how you can deploy IPv6 at your network edge in such a way that you can grow the edge without consuming IPv4 addresses. For many small and mid-size ISPs, Job 2 does not involve anything to do with the customer's "modem" device because you don't have the kind of relationship with "modem" vendors to influence their product development. So focus on your own network edge, not on your customers' network edges. > It is at this time more a question of strategic positioning. > The kind of thing your boss should be thinking about. Bosses really appreciate well-reasoned white papers with a clear and straightforward management summary on the first page. Do you have the information and understanding of IPv6 in order to write such a white paper? > Switching your management network to IPv6 single-stack This may actually be the last and toughest thing that ISPs do because of the variety of software and stuff in the management network. --Michael Dillon From swmike at swm.pp.se Thu Oct 30 06:08:51 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 30 Oct 2008 12:08:51 +0100 (CET) Subject: Another driver for v6? In-Reply-To: <49098ECA.4090901@isoc.org> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <49098ECA.4090901@isoc.org> Message-ID: On Thu, 30 Oct 2008, Matthew Ford wrote: > Your stats (which are very interesting btw, thanks for doing the work) > suggest that the number of clients that would make use of the AAAA > record for a dual-stack service is about the same as the number of > clients that would fail in the event that both A and AAAA were present. > That's not exactly an incentive to content providers is it? The last couple of days the ratio went down to less than 0.3% who would potentially get in trouble (factor is most likely less as the measurement method penalises later objects). But yes, there is absolutely no upside to deploying IPv6 for content providers in the short term. It's like Y2K, there was NO upside to fixing it until December 31 1999. -- Mikael Abrahamsson email: swmike at swm.pp.se From sven at cyberbunker.com Thu Oct 30 08:03:55 2008 From: sven at cyberbunker.com (HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP) Date: Thu, 30 Oct 2008 13:03:55 +0000 (GMT) Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: internet exchanges are not per-se "redundant" they basically are a switch which actually, because of the many connected parties, most of which do not have enough PAID transit to cover any outages on it, causes more problems than they are good for. (the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here) internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-, but when they do work that's "nice" (always make sure you have enough paid capacity to cover for it when they do not work however!) peering on only one of them therefore does not make your network more reliable in any way (it becomes a different story when you connect to like 10 or so worldwide). as for "peering" agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others). those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc). -- HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. Minister of Telecommunications, Republic CyberBunker. Phone: +49/163-4405069 Phone: +49/30-36731425 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 29 Oct 2008, Paul Stewart wrote: > Thanks! That's a really good one and surprised myself I missed it..;) > > _____________________________________________ > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Wednesday, October 29, 2008 3:28 PM > To: Paul Stewart > Cc: nanog at nanog.org > Subject: Re: Peering - Benefits? > > > * PGP Signed by an unknown key > > On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > > > I can think of some but looking to develop a concrete list of > appealing > > reasons etc. such as: > > > > -control over routing between networks > > -security aspect (being able to filter/verify routes to some degree) > > -latency/performance > > I'm surprised you didn't include "chance to pick up a redundant > connection". > > * Unknown Key > * 0xB4D3D7B0 > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > X-CONTACT-FILTER-MATCH: "nanog" > From pstewart at nexicomgroup.net Thu Oct 30 08:09:13 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 30 Oct 2008 09:09:13 -0400 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B475D8@nexus.nexicomgroup.net> Thanks - no I understand that... We have multiple transit providers today and are already present on a couple of smaller peering exchanges with an open peering policy... our experience with them has been very positive. The redundancy perspective is that you now have more paths to the same AS - and an assumption that the peering route will always be best (I know that's not always true). We of course have enough transit in case of a peering outage - would never "put all our eggs into one basket" that it sounds like some others are doing.... also, we are looking at a number of them in various parts of the world currently which adds another level of redundancy per say.... Take care, Paul -----Original Message----- From: HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP [mailto:sven at cyberbunker.com] Sent: Thursday, October 30, 2008 9:04 AM To: Paul Stewart Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org Subject: RE: Peering - Benefits? internet exchanges are not per-se "redundant" they basically are a switch which actually, because of the many connected parties, most of which do not have enough PAID transit to cover any outages on it, causes more problems than they are good for. (the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here) internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-, but when they do work that's "nice" (always make sure you have enough paid capacity to cover for it when they do not work however!) peering on only one of them therefore does not make your network more reliable in any way (it becomes a different story when you connect to like 10 or so worldwide). as for "peering" agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others). those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc). -- HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. Minister of Telecommunications, Republic CyberBunker. Phone: +49/163-4405069 Phone: +49/30-36731425 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 29 Oct 2008, Paul Stewart wrote: > Thanks! That's a really good one and surprised myself I missed it..;) > > _____________________________________________ > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Wednesday, October 29, 2008 3:28 PM > To: Paul Stewart > Cc: nanog at nanog.org > Subject: Re: Peering - Benefits? > > > * PGP Signed by an unknown key > > On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: > > > I can think of some but looking to develop a concrete list of > appealing > > reasons etc. such as: > > > > -control over routing between networks > > -security aspect (being able to filter/verify routes to some degree) > > -latency/performance > > I'm surprised you didn't include "chance to pick up a redundant > connection". > > * Unknown Key > * 0xB4D3D7B0 > > > > > > > ------------------------------------------------------------------------ ---- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > X-CONTACT-FILTER-MATCH: "nanog" > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From will at harg.net Thu Oct 30 08:16:54 2008 From: will at harg.net (Will Hargrave) Date: Thu, 30 Oct 2008 13:16:54 +0000 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <4909B3C6.3050904@harg.net> HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote: > as for "peering" agreements, just implement an open peering policy > (doesn't nessesarily have to take place over an ix, also applies to pieces > of ethernet running from your network to others). > > those basically are contracts that force anyone who has also signed one to > peer with your network, wether they like you or not (saves the trouble > when you are a content provider and others do not want to peer with you > because they provide content too and you are a competing party etc). It is not practice in this community for 'open peering policy' to mean 'must peer with anyone'. You might still refuse to peer on the basis that the other party is unreliable or run by idiots, and this is perfectly acceptable even with an advertised open peering policy. Nor does such a statement create any form of contract or obligation under any law I am aware of, as such an indicative offer does not fulfill the requirements to form a binding contract. Any device which has REQUIRED e.g. participants in an IX to peer with others has proved very unpopular in the industry. From andy at nosignal.org Thu Oct 30 08:20:39 2008 From: andy at nosignal.org (Andy Davidson) Date: Thu, 30 Oct 2008 13:20:39 +0000 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <9AFB2A51-6EE0-440C-9A71-4C0A4D678455@nosignal.org> On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote: > internet exchanges are not per-se "redundant" Those networks who *choose* connect to peers via a single fabric, in a single location, will suffer a similar fate to those networks who single home to one transit provider. > (the amsix with their many outages and connected parties that rely > primarliy on it's functionality is a prime example here) I run interconnection for three networks connected to the ams-ix and can't understand why you think that the ams-ix fabric has "many outages" - I have found it, to borrow a phrase from another stable European IXP, rock solid. > internet exchanges usually are some sort of hobby computer club, you > cannot rely on them to actually -work-, You shouldn't bet the farm on a single one of anything. My alarm clock failed once, this doesn't mean that all alarm clocks are hobbyist timekeeping devices. Most internet exchanges are professional organisations run by a team of experts who care about the operational stability of the platform. Most in Europe are association based organisations, who's leaders are held accountable for the operational and commercial stability of the exchange, to all of the participants, at legally mandated meetings. Its a shame if your experience at the local IXP has been less positive, perhaps look at the procedures and policies of a more sound exchange and encourage your local IXP to be run along those lines. Andy From lists at memetic.org Thu Oct 30 08:21:18 2008 From: lists at memetic.org (Adam Armstrong) Date: Thu, 30 Oct 2008 13:21:18 +0000 Subject: Peering - Benefits? In-Reply-To: <4908E31B.7000303@kingrst.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> <4908E215.504@kingrst.com> <89D27DE3375BB6428DDCC2927489826A01B47532@nexus.nexicomgroup.net> <4908E31B.7000303@kingrst.com> Message-ID: <4909B4CE.4030504@memetic.org> Sure, but we're talking about settlement-free peering. He's only expecting to be able to reach his peer's subnets and perhaps those of his peer's customers. If he peers with ASx in two locations, he does have redundant connections to ASx's tiny corner of the internet. adam. > But if that AS is a stub, you still can't use their up stream providers > to get data out to the rest of the world. It still wouldn't even > function as an "alternative path" it would only function for the subnets > which that AS owns. > > Paul Stewart wrote: > >> Thanks - I believe the wording meant was "alternative path" versus >> connection... in other words if an AS has issues with one or more >> upstream providers for whatever reason, you have good chances the >> peering connection will remain in better shape (not always granted, but >> good odds).... >> >> Paul >> >> >> -----Original Message----- >> From: Steven King [mailto:sking at kingrst.com] >> Sent: October 29, 2008 6:22 PM >> To: Paul Stewart >> Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org >> Subject: Re: Peering - Benefits? >> >> It would only be a redundant connection if the AS your peering with is a >> transit AS. The AS that I work with is a stub AS and can not function as >> a fully redundant link. >> >> Just something to watch out for. >> >> Paul Stewart wrote: >> >> >>> Thanks! That's a really good one and surprised myself I missed it..;) >>> >>> _____________________________________________ >>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >>> Sent: Wednesday, October 29, 2008 3:28 PM >>> To: Paul Stewart >>> Cc: nanog at nanog.org >>> Subject: Re: Peering - Benefits? >>> >>> >>> * PGP Signed by an unknown key >>> >>> On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said: >>> >>> >>> >>> >>>> I can think of some but looking to develop a concrete list of >>>> >>>> >>>> >>> appealing >>> >>> >>> >>>> reasons etc. such as: >>>> >>>> -control over routing between networks >>>> -security aspect (being able to filter/verify routes to some degree) >>>> -latency/performance >>>> >>>> >>>> >>> I'm surprised you didn't include "chance to pick up a redundant >>> connection". >>> >>> * Unknown Key >>> * 0xB4D3D7B0 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------ >> ---- >> >> >>> "The information transmitted is intended only for the person or entity >>> >>> >> to which it is addressed and contains confidential and/or privileged >> material. If you received this in error, please contact the sender >> immediately and then destroy this transmission, including all >> attachments, without copying, distributing or disclosing same. Thank >> you." >> >> >>> >>> >>> >> >> > > From will at harg.net Thu Oct 30 08:37:10 2008 From: will at harg.net (Will Hargrave) Date: Thu, 30 Oct 2008 13:37:10 +0000 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B475D8@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01B475D8@nexus.nexicomgroup.net> Message-ID: <4909B886.7000702@harg.net> Paul Stewart wrote: > We have multiple transit providers today and are already present on a couple > of smaller peering exchanges with an open peering policy... our experience > with them has been very positive. As an IX operator I'm glad to hear it :-) > The redundancy perspective is that you now have more paths to the same AS - > and an assumption that the peering route will always be best (I know that's > not always true). Something to remember is that you are a network *operator* not a network *purchaser*. If the peering route isn't working for you, pick up the phone and talk to your peering partner. The whole point of being a network operator is that you control who you connect with and take an active hand in fixing problems! As others have stated, rich interconnection gives you greater abilities in this area. > We of course have enough transit in case of a peering outage - would never > "put all our eggs into one basket" that it sounds like some others are That attitude is quite 'old-school' - the idea that you can back up your peering with transit often does not ring true in practice. You have less visibility into your transit providers network than into your IXes networks, and what information you do have is clouded by commercial concerns (read: sales bullshit). The traffic has to go somewhere, and if everyone in a metro area tries to send to their transits it will just result in congestion within those networks - even more likely when you consider the typical way their are built with ports tiered off at layer2 from routers; traffic in the same metro area is likely to simply hairpin up/down the router uplink. Traffic between major transits within a metro area is also subject to complicated commercial considerations which might mean the connectivity via that route isn't so great. > also, we are looking at a number of them in various parts of the world > currently which adds another level of redundancy per say.... Many metro areas have more than one IX fabric often with considerable numbers of operators on both. At LONAP in London we have members with big ports expressly for backing up their private interconnects as well as to back up sessions at other IXes. In (primarily) Europe, the Euro-ix website has some useful resources to help people select IXes: e.g https://www.euro-ix.net/member/m/peeringmatrix Will From lists at memetic.org Thu Oct 30 08:49:35 2008 From: lists at memetic.org (Adam Armstrong) Date: Thu, 30 Oct 2008 13:49:35 +0000 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <4909BB6F.7050102@memetic.org> HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote: > internet exchanges are not per-se "redundant" > they basically are a switch which actually, because of the many connected > parties, most of which do not have enough PAID transit to cover any > outages on it, causes more problems than they are good for. > (the amsix with their many outages and connected parties that rely > primarliy on it's functionality is a prime example here) > > internet exchanges usually are some sort of hobby computer club, you > cannot rely on them to actually -work-, but when they do work that's > "nice" (always make sure you have enough paid capacity to cover for it > when they do not work however!) > > peering on only one of them therefore does not make your network more > reliable in any way (it becomes a different story when you connect to like > 10 or so worldwide). > > as for "peering" agreements, just implement an open peering policy > (doesn't nessesarily have to take place over an ix, also applies to pieces > of ethernet running from your network to others). > > those basically are contracts that force anyone who has also signed one to > peer with your network, wether they like you or not (saves the trouble > when you are a content provider and others do not want to peer with you > because they provide content too and you are a competing party etc). > Dear me, that smells of extreme ignorance of the design and management of the major exchanges. LINX and AMS-IX for example go to great lengths to make sure their exchanges have high availability. I've had far fewer issues with individual exchanges with 100s of members than I have with single transit providers. The LINX for example provides TWO fabrics, and encourage members to peer on both of them. My transit providers have a single network which they break from time to time. It's far harder for an IX to break anything as they're less involved in the whole process. It is true, of course, that there are tiny badly-run exchanges run as a hobby, but just as it's best not to buy transit from a bargain-basement transit provider, I wouldn't trust any important traffic to one of the tiny exchanges. I'd say that LINX/AMS-IX are amongst the most reliable places you can pass your traffic. Since you bring up the "PAID" issue, as if to suggest that people who peer are cheap and don't care about their traffic, most organisations who peer do so to *improve* the performance of their networks. The cheaper route for me is not to buy a bunch of peering routers to manage 1000s of peering sessions, but I spend the extra cash to make the service I provide to my customers better. If you don't have the understanding or desire to provide the best service you can to your customers, perha1ps you'd like to become a politician? Peering on one would make youre network more reliable if you have sufficiently burstable transit links. Only a fool would try to offload 180mbit of traffic via 100mbit of transit and 100mbit of peering. User stupidity isn't the fault of the exchanges and certainly don't diminish the viability of internet exchanges as a concept. I think others have already rubbished your contracts nonsense, so I won't even bother. adam. From michael.dillon at bt.com Thu Oct 30 09:06:59 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 30 Oct 2008 14:06:59 -0000 Subject: Peering - Benefits? In-Reply-To: <9AFB2A51-6EE0-440C-9A71-4C0A4D678455@nosignal.org> Message-ID: > On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von > CyberBunker-Kamphuis MP wrote: > > > internet exchanges are not per-se "redundant" > > Those networks who *choose* connect to peers via a single > fabric, in a single location, will suffer a similar fate to > those networks who single home to one transit provider. Are you referring to his royal highness' network? In any case, if you are really interested in achieving highly reliable connectivity to the Internet, you need to start by engineering it into your design. It's not just a matter of choosing the right mix of peering and transit. --Michael Dillon From p.caci at seabone.net Thu Oct 30 09:31:54 2008 From: p.caci at seabone.net (Pierfrancesco Caci) Date: Thu, 30 Oct 2008 15:31:54 +0100 Subject: Peering - Benefits? In-Reply-To: (HRH Sven Olaf Prinz von CyberBunker-Kamphuis's message of "Thu, 30 Oct 2008 13:03:55 +0000 (GMT)") References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <87vdvacfxh.fsf@clarabella.noc.seabone.net> :-> "HRH" == HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP writes: > internet exchanges are not per-se "redundant" depends on your concept of redundancy. > they basically are a switch which actually, because of the many > connected > parties, most of which do not have enough PAID transit to cover any > outages on it, causes more problems than they are good for. depends who you peer with, and your comment on the IX being "a switch" depends on which IX you connect to. > (the amsix with their many outages and connected parties that rely > primarliy on it's functionality is a prime example here) How many of the outages at AMS-IX really affected you directly? or weren't they rather limited to a bunch of your peers? And you know that you can get multiple links to separate switches in different location, don't you? Same goes for DE-CIX, LINX, the various Equinix, PAIX etc... > internet exchanges usually are some sort of hobby computer club, > you I think your choice of which internet exchanges to join has some flaws. > cannot rely on them to actually -work-, but when they do work that's > "nice" (always make sure you have enough paid capacity to cover for it > when they do not work however!) no, always make sure you have N+1 redundancy with a particular peer in dispersed locations. or N+2 if you can afford the capex. > peering on only one of them therefore does not make your network more > reliable in any way (it becomes a different story when you connect to like > 10 or so worldwide). > as for "peering" agreements, just implement an open peering policy > (doesn't nessesarily have to take place over an ix, also applies to pieces > of ethernet running from your network to others). > those basically are contracts that force anyone who has also signed one to > peer with your network, wether they like you or not (saves the trouble > when you are a content provider and others do not want to peer with you > because they provide content too and you are a competing party etc). you will find that most peering contracts or agreement have nice clauses to terminate the peering at some agreed notice, as well as a whole host of clauses that give the peering manager the power to say no if he feels so. > -- > HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. > Minister of Telecommunications, Republic CyberBunker. ok, you're a troll and I bit... -- Pf From todd-nanog at renesys.com Thu Oct 30 09:49:27 2008 From: todd-nanog at renesys.com (Todd Underwood) Date: Thu, 30 Oct 2008 14:49:27 +0000 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> Message-ID: <20081030144927.GU20914@renesys.com> On Thu, Oct 30, 2008 at 01:03:55PM +0000, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote: > (the amsix with their many outages and connected parties that rely > primarliy on it's functionality is a prime example here) > > internet exchanges usually are some sort of hobby computer club, you > cannot rely on them to actually -work-, but when they do work that's > "nice" (always make sure you have enough paid capacity to cover for it > when they do not work however!) http://www.ams-ix.net/technical/stats/ certainly looks like over 500Gb/s of traffic across ams-ix. that's a big 'sort of hobby computer club'. i wonder what all those hobbiests are doing. in all seriousness, the above post is ludicrous. ams-ix runs one of the most reliable exchange platforms on the planet due to an incredible investment in optical switches and duplicate hardware. it's expensive to run that way but the results have been incredible. none of that is actually on-target for the original question about the *value* (other than cost savings) of peering. so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events). are there others? > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. i was not an individual addressed but the attached mail was sent to a mailing list of 10k people. HRH Sven Olaf is in violation of his own policy about dissemination, distribution or copying. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From David_Hankins at isc.org Thu Oct 30 10:47:38 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 30 Oct 2008 08:47:38 -0700 Subject: Another driver for v6? In-Reply-To: References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> Message-ID: <20081030154738.GA5482@isc.org> On Thu, Oct 30, 2008 at 08:10:26AM +0100, Mikael Abrahamsson wrote: > On Wed, 29 Oct 2008, David W. Hankins wrote: >> It is almost lunacy to deploy IPv6 in a customer-facing sense (note >> for example Google's choice to put its AAAA on a separate FQDN). At > > Could you please elaborate on this point? My data presented > indicates > that there are very very few (the longer I collected the data, the better > the ratio got) who cannot properly fetch a resource that has A/AAAA. I'm sorry I led you down the wrong ferret hole. The issue isn't directly the involvement of a A/AAAA mixed RRsets. The issue is that such dual placement complicates debugging and operations. If someone can't reach www.google.com now, you know that it is either a DNS or IPv4 issue. It is very straightforward. If someone can't reach the hypothetical A/AAAA www.google.com RRset, you've just increased your support costs. "My network is slow." "Are you using IPv4 or IPv6?" "Netscape." This costs you something, but doesn't gain anything. Nevermind that IPv6 often breaks at some networks, and no one at the remote network seems to care to fix it. It is someone's experiment. I'm recommending a variety of caution which is to go ahead and deploy your initial/experimental IPv6 on separate FQDN's, so that you can easily migrate your AAAA's onto "production names" when there is an advantage to doing so, and in the meantime you aren't breaking anything for the rest of the planet. >> will migrate to IPv6. Which seems like a pretty bad time to still be >> trying to figure that out, but ohwell. > > 6to4 and Teredo traffic is increasing very rapidly, so that seems to be one > path taken right now: > > I don't know how to ask this question without sounding mean, but did the graph spike out of zero, or did you start collecting two months ago? Both Teredo and 6to4 strike me as a kind of network operations "terrorism." That is, the clients that engage in this automatically. It proposes precisely the same support-cost-increase problem for the ISP ("My network is slow." "Are you using IPv4 or IPv6?" "Netscape."), and it's not clear to me how an ISP can "opt out". So it's kind of like these OS manufacturers are sending ISP's a little message; spend your support costs, or we'll spend them for you. I'm not sure that's productive overall. >> IPv6: It's kind of like storing dry food in preparation for the >> apocalypse. > > If you actually KNOW the apocalypse is coming (but not when), this is > correct. I think everyone knows the IPv4 shortfall is coming. I do not think the world's view of the consequences is consistent yet. So I don't think it matters; it's prudent to get a defensible position today. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From andy at nosignal.org Thu Oct 30 10:55:01 2008 From: andy at nosignal.org (Andy Davidson) Date: Thu, 30 Oct 2008 15:55:01 +0000 Subject: Another driver for v6? In-Reply-To: <20081030154738.GA5482@isc.org> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> Message-ID: On 30 Oct 2008, at 15:47, David W. Hankins wrote: > If someone can't reach the hypothetical A/AAAA www.google.com RRset, > you've just increased your support costs. "My network is slow." > "Are you using IPv4 or IPv6?" "Netscape." Do you think that industry should be working to some kind of well supported / worldwide flag day when lots of popular resources add v6 records at the same time ? In the same way that in the UK, appliance manufacturers have been educating people about the analogue terrestrial TV switchoff by 2012, do you think that we should be advocating a 'internet PLUS day' some time in (date plucked from the air) 2014 ? -a From michael.dillon at bt.com Thu Oct 30 11:04:02 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 30 Oct 2008 16:04:02 -0000 Subject: Another driver for v6? In-Reply-To: Message-ID: > In the same way that in the UK, appliance manufacturers have > been educating people about the analogue terrestrial TV > switchoff by 2012, do you think that we should be advocating > a 'internet PLUS day' some time in (date plucked from the air) 2014 ? Actually, the Internet PLUS day should be tied to some other event, say the London 2012 Olympics. That would be a kind of launch event for a lot of people to make IPv6 services available. Then, a few years after this, we could have an Internet version 4 eulogy event and get a lot of ISPs to shut off legacy IPv4 services. That would have to be 2016 or later and it wouldn't be like the analog TV shutoff, because it would not be a 100% shutoff. I think that technical people underestimate the impact that this type of an event can provide. While we want to avoid being forced into a flag-day switchover, that does not mean that a flag day is all bad. We could have the Internet PLUS flag day in order to raise awareness and give ISPs a target to shoot for. --Michael Dillon From patrick at ianai.net Thu Oct 30 11:15:11 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 30 Oct 2008 12:15:11 -0400 Subject: Peering - Benefits? In-Reply-To: <20081030144927.GU20914@renesys.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <23924.1225308484@turing-police.cc.vt.edu> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> <20081030144927.GU20914@renesys.com> Message-ID: On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote: > so far there have been some good values articulated and there may be > more (reach, latency, diversity of path, diversity of capacity, > control, flexibility, options, price negotation) and some additional > costs have been mentioned (capex for peering routing, opex for the > peering itself + cross connects + switch fees + additional time spent > troubleshooting routing events). > > are there others? Almost certainly. But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point. Just be sure to consider everything when deciding whether to peer. -- TTFN, patrick P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet. From mike at mtcc.com Thu Oct 30 11:15:51 2008 From: mike at mtcc.com (Michael Thomas) Date: Thu, 30 Oct 2008 09:15:51 -0700 Subject: Another driver for v6? In-Reply-To: References: Message-ID: <4909DDB7.8020806@mtcc.com> michael.dillon at bt.com wrote: > I think that technical people underestimate the impact that this > type of an event can provide. While we want to avoid being forced > into a flag-day switchover, that does not mean that a flag day is > all bad. We could have the Internet PLUS flag day in order to > raise awareness and give ISPs a target to shoot for. > "This new internet is brought to you by Pepsi: the choice a new version!" or maybe "IPv6 tastes good, like an Internet should" or, oh never mind :) Mike > --Michael Dillon > > From swmike at swm.pp.se Thu Oct 30 11:17:16 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 30 Oct 2008 17:17:16 +0100 (CET) Subject: Another driver for v6? In-Reply-To: <20081030154738.GA5482@isc.org> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> Message-ID: On Thu, 30 Oct 2008, David W. Hankins wrote: > I don't know how to ask this question without sounding mean, but did the > graph spike out of zero, or did you start collecting two months ago? It spiked out of zero as we put up our 6to4 and teredo relays approx two months ago. I don't know where the traffic was before, probably at other peoples 6to4 relays. -- Mikael Abrahamsson email: swmike at swm.pp.se From pstewart at nexicomgroup.net Thu Oct 30 11:38:45 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 30 Oct 2008 12:38:45 -0400 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><23924.1225308484@turing-police.cc.vt.edu><89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net><20081030144927.GU20914@renesys.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B476B6@nexus.nexicomgroup.net> Hey Patrick... Thanks for playing devil's advocate... I am truly trying to cover both sides of the discussion - technically it's what we want for sure but the top of the food chain looks beyond just what a technical team wants to do as I'm sure we're all plagued by sometimes ... In our specific case, after factoring in ALL costs in an extensive analysis - transit and peering end up very close .. peering being a very slight amount above transit in our case. At the end of the day it's almost a moot point from a cost perspective (you can tell I'm not a bean counter lol) I would argue though that even with 4 transit providers (which we have now), that peering is an excellent venue to take on - even for the time/management involved. Of course that opinion I can only speak for our situation in that regard..;) Appreciate your input - and I agree though that peering isn't for everyone... definitely... Take care, Paul -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Thursday, October 30, 2008 12:15 PM To: NANOG list Subject: Re: Peering - Benefits? On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote: > so far there have been some good values articulated and there may be > more (reach, latency, diversity of path, diversity of capacity, > control, flexibility, options, price negotation) and some additional > costs have been mentioned (capex for peering routing, opex for the > peering itself + cross connects + switch fees + additional time spent > troubleshooting routing events). > > are there others? Almost certainly. But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point. Just be sure to consider everything when deciding whether to peer. -- TTFN, patrick P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From Valdis.Kletnieks at vt.edu Thu Oct 30 11:45:09 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 Oct 2008 12:45:09 -0400 Subject: Another driver for v6? In-Reply-To: Your message of "Thu, 30 Oct 2008 15:55:01 -0000." References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> Message-ID: <17325.1225385109@turing-police.cc.vt.edu> On Thu, 30 Oct 2008 15:55:01 -0000, Andy Davidson said: > In the same way that in the UK, appliance manufacturers have been > educating people about the analogue terrestrial TV switchoff by 2012, Is your side of the pond any more ready than our side is for next Febuary's drop-dead cutoff? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From patrick at ianai.net Thu Oct 30 12:05:58 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 30 Oct 2008 13:05:58 -0400 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B476B6@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><23924.1225308484@turing-police.cc.vt.edu><89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net><20081030144927.GU20914@renesys.com> <89D27DE3375BB6428DDCC2927489826A01B476B6@nexus.nexicomgroup.net> Message-ID: <7E62522B-E485-4BB9-8B7F-36FB10FF72B3@ianai.net> On Oct 30, 2008, at 12:38 PM, Paul Stewart wrote: > Thanks for playing devil's advocate... I am truly trying to cover > both > sides of the discussion - technically it's what we want for sure but > the > top of the food chain looks beyond just what a technical team wants to > do as I'm sure we're all plagued by sometimes ... > > In our specific case, after factoring in ALL costs in an extensive > analysis - transit and peering end up very close .. peering being a > very > slight amount above transit in our case. At the end of the day it's > almost a moot point from a cost perspective (you can tell I'm not a > bean > counter lol) If it is break even, the "intangibles" of peering clearly make it a winner. Plus, as traffic increases, I bet the "cost" of peering goes down. And everyone's traffic is increasing. > I would argue though that even with 4 transit providers (which we have > now), that peering is an excellent venue to take on - even for the > time/management involved. Of course that opinion I can only speak for > our situation in that regard..;) Perhaps dropping to 3 or even 2 transit providers is in order when you start peering? That would allow you to give larger commits, reducing unit costs. You still have plenty of vectors if you can peer off a significant fraction of your traffic. For instance, lets say you can peer at least 25% of your traffic (a pretty modest amount). If you split your traffic evenly across four providers, this lets you drop one with no loss of redundancy. Plus you get all the other things peering is good for. -- TTFN, patrick > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Thursday, October 30, 2008 12:15 PM > To: NANOG list > Subject: Re: Peering - Benefits? > > On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote: > >> so far there have been some good values articulated and there may be >> more (reach, latency, diversity of path, diversity of capacity, >> control, flexibility, options, price negotation) and some additional >> costs have been mentioned (capex for peering routing, opex for the >> peering itself + cross connects + switch fees + additional time spent >> troubleshooting routing events). >> >> are there others? > > Almost certainly. > > But I'm sure the OP has a nice list to at least get him started of > peering benefits. Interestingly, no one has mentioned the downside of > peering. Just to play devil's advocate, allow me to mention some > "cons" about peering: If you drop all peering and push traffic to > transit providers, you can frequently get lower price per bit. > Picking 2/3/4 transit providers and committing large amounts to them > gives you flexibility, control, reliability, lowers your CapEx, and > lowers your network complexity which can (should) lower your OpEx. > There are others, but you get the point. > > Just be sure to consider everything when deciding whether to peer. > > -- > TTFN, > patrick > > P.S. Obviously, I think peering is better for the "network" I run, but > that cannot and should not be generalized to every network on the > Internet. > > From pstewart at nexicomgroup.net Thu Oct 30 12:12:51 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 30 Oct 2008 13:12:51 -0400 Subject: Peering - Benefits? In-Reply-To: <7E62522B-E485-4BB9-8B7F-36FB10FF72B3@ianai.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><23924.1225308484@turing-police.cc.vt.edu><89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net><20081030144927.GU20914@renesys.com><89D27DE3375BB6428DDCC2927489826A01B476B6@nexus.nexicomgroup.net> <7E62522B-E485-4BB9-8B7F-36FB10FF72B3@ianai.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B476E2@nexus.nexicomgroup.net> Absolutely... I can see us dropping at least one of the transit providers over time - with current growth we might end up keeping all of them to meet needs though. Just depends on how fast traffic moves from transit to peering versus how quickly our overall requirements grow (pretty dramatic climb right now).... And yes, with our peering costs - the unit costs drop off considerably as they pick up so the longer term will be that peering will be considerably more economical than transit even with long haul costs... Cheers! Paul -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Thursday, October 30, 2008 1:06 PM To: NANOG list Subject: Re: Peering - Benefits? On Oct 30, 2008, at 12:38 PM, Paul Stewart wrote: > Thanks for playing devil's advocate... I am truly trying to cover > both > sides of the discussion - technically it's what we want for sure but > the > top of the food chain looks beyond just what a technical team wants to > do as I'm sure we're all plagued by sometimes ... > > In our specific case, after factoring in ALL costs in an extensive > analysis - transit and peering end up very close .. peering being a > very > slight amount above transit in our case. At the end of the day it's > almost a moot point from a cost perspective (you can tell I'm not a > bean > counter lol) If it is break even, the "intangibles" of peering clearly make it a winner. Plus, as traffic increases, I bet the "cost" of peering goes down. And everyone's traffic is increasing. > I would argue though that even with 4 transit providers (which we have > now), that peering is an excellent venue to take on - even for the > time/management involved. Of course that opinion I can only speak for > our situation in that regard..;) Perhaps dropping to 3 or even 2 transit providers is in order when you start peering? That would allow you to give larger commits, reducing unit costs. You still have plenty of vectors if you can peer off a significant fraction of your traffic. For instance, lets say you can peer at least 25% of your traffic (a pretty modest amount). If you split your traffic evenly across four providers, this lets you drop one with no loss of redundancy. Plus you get all the other things peering is good for. -- TTFN, patrick > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Thursday, October 30, 2008 12:15 PM > To: NANOG list > Subject: Re: Peering - Benefits? > > On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote: > >> so far there have been some good values articulated and there may be >> more (reach, latency, diversity of path, diversity of capacity, >> control, flexibility, options, price negotation) and some additional >> costs have been mentioned (capex for peering routing, opex for the >> peering itself + cross connects + switch fees + additional time spent >> troubleshooting routing events). >> >> are there others? > > Almost certainly. > > But I'm sure the OP has a nice list to at least get him started of > peering benefits. Interestingly, no one has mentioned the downside of > peering. Just to play devil's advocate, allow me to mention some > "cons" about peering: If you drop all peering and push traffic to > transit providers, you can frequently get lower price per bit. > Picking 2/3/4 transit providers and committing large amounts to them > gives you flexibility, control, reliability, lowers your CapEx, and > lowers your network complexity which can (should) lower your OpEx. > There are others, but you get the point. > > Just be sure to consider everything when deciding whether to peer. > > -- > TTFN, > patrick > > P.S. Obviously, I think peering is better for the "network" I run, but > that cannot and should not be generalized to every network on the > Internet. > > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jgreco at ns.sol.net Thu Oct 30 17:08:24 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 30 Oct 2008 16:08:24 -0600 (CST) Subject: Sprint / Cogent Message-ID: <200810302208.m9UM8OrO009591@aurora.sol.net> Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From patrick at ianai.net Thu Oct 30 17:10:35 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 30 Oct 2008 18:10:35 -0400 Subject: Sprint / Cogent In-Reply-To: <200810302208.m9UM8OrO009591@aurora.sol.net> References: <200810302208.m9UM8OrO009591@aurora.sol.net> Message-ID: On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: > Looks like maybe Sprint and Cogent are experiencing communications > difficulties in the DC (and probably other) areas. Theories include > a potential depeering. Not a theory. -- TTFN, patrick From tme at multicasttech.com Thu Oct 30 17:40:55 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 30 Oct 2008 18:40:55 -0400 Subject: Sprint / Cogent In-Reply-To: <200810302208.m9UM8OrO009591@aurora.sol.net> References: <200810302208.m9UM8OrO009591@aurora.sol.net> Message-ID: <677ACFD1-D08B-47A4-9E46-EAAD9CBD983E@multicasttech.com> On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: > Looks like maybe Sprint and Cogent are experiencing communications > difficulties in the DC (and probably other) areas. Theories include > a potential depeering. I am seeing issues Cogent -> Sprint at Tyco Road, Tysons Corner VA. arin_whois 206.159.101.241 Sprint SPRINT-W (NET-206-159-0-0-1) 206.159.0.0 - 206.159.255.255 Sprint com FON-34665525765801 (NET-206-159-101-0-1) 206.159.101.0 - 206.159.101.255 ping 206.159.101.241 PING 206.159.101.241 (206.159.101.241) from 63.105.122.7 : 56(84) bytes of data. From 63.105.122.1: Destination Host Unreachable From 63.105.122.1: Destination Host Unreachable show ip bgp 206.159.101.241 % Network not in table It was there as recently as Noon EDT : grep 206.159.101.0 bgp.full* bgp.full.Oct_30_00:07:00_EST_2008:*> 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i bgp.full.Oct_30_06:07:00_EST_2008:*> 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i bgp.full.Oct_30_12:07:00_EST_2008:*> 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i Regards Marshall > > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance > [and] then I > won't contact you again." - Direct Marketing Ass'n position on e- > mail spam(CNN) > With 24 million small businesses in the US alone, that's way too > many apples. > From michal at krsek.cz Thu Oct 30 17:46:46 2008 From: michal at krsek.cz (Michal Krsek) Date: Fri, 31 Oct 2008 02:46:46 +0400 Subject: Sprint / Cogent References: <200810302208.m9UM8OrO009591@aurora.sol.net> <677ACFD1-D08B-47A4-9E46-EAAD9CBD983E@multicasttech.com> Message-ID: <013e01c93ae1$d753b650$cb00470a@w2lan.cesnet.cz> >> Looks like maybe Sprint and Cogent are experiencing communications >> difficulties in the DC (and probably other) areas. Theories include >> a potential depeering. > > I am seeing issues Cogent -> Sprint at Tyco Road, Tysons Corner VA. > .......... > ....... .. > > show ip bgp 206.159.101.241 > % Network not in table > > It was there as recently as Noon EDT : > > grep 206.159.101.0 bgp.full* > bgp.full.Oct_30_00:07:00_EST_2008:*> 206.159.101.0 38.101.161.116 > 62050 0 174 1239 6157 i > bgp.full.Oct_30_06:07:00_EST_2008:*> 206.159.101.0 38.101.161.116 > 62050 0 174 1239 6157 i > bgp.full.Oct_30_12:07:00_EST_2008:*> 206.159.101.0 38.101.161.116 > 62050 0 174 1239 6157 i All my traffic to Sprint is not being trasported over Cogent backbone here in Central Europe. Regards Michal From brandon.galbraith at gmail.com Thu Oct 30 17:54:21 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 30 Oct 2008 17:54:21 -0500 Subject: Sprint / Cogent In-Reply-To: References: <200810302208.m9UM8OrO009591@aurora.sol.net> Message-ID: <366100670810301554k6f43754bm8e91ba7f4564e586@mail.gmail.com> On 10/30/08, Patrick W. Gilmore wrote: > > On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: > > Looks like maybe Sprint and Cogent are experiencing communications >> difficulties in the DC (and probably other) areas. Theories include >> a potential depeering. >> > > Not a theory. > > Indeed. It appears, using Sprint's looking glass, that they're completely partitioned from Cogent. YMMV. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From deepak at ai.net Thu Oct 30 17:55:29 2008 From: deepak at ai.net (Deepak Jain) Date: Thu, 30 Oct 2008 18:55:29 -0400 Subject: Depeering as an IPv6 driver (was: Re: Sprint / Cogent) In-Reply-To: <200810302208.m9UM8OrO009591@aurora.sol.net> References: <200810302208.m9UM8OrO009591@aurora.sol.net> Message-ID: <490A3B61.9080905@ai.net> I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single homed) user to access now missing parts of the Internet. Me thinks, yes. Deepak Joe Greco wrote: > Looks like maybe Sprint and Cogent are experiencing communications > difficulties in the DC (and probably other) areas. Theories include > a potential depeering. > > ... JG From jared at puck.nether.net Thu Oct 30 18:02:35 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 30 Oct 2008 19:02:35 -0400 Subject: Depeering as an IPv6 driver (was: Re: Sprint / Cogent) In-Reply-To: <490A3B61.9080905@ai.net> References: <200810302208.m9UM8OrO009591@aurora.sol.net> <490A3B61.9080905@ai.net> Message-ID: <5E32C00D-9BBE-42D6-93E0-3651CD46ADBA@puck.nether.net> On Oct 30, 2008, at 6:55 PM, Deepak Jain wrote: > I wonder if judicious use of 6to4 and Teredo would allow an IPv6 > (single homed) user to access now missing parts of the Internet. Me > thinks, yes. So would some "CGN" (Carrier Grade Nat anyone) too. Last I knew Cogent wasn't doing any IPv6.. has that changed? - Jared From brandon.galbraith at gmail.com Thu Oct 30 18:11:06 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 30 Oct 2008 18:11:06 -0500 Subject: Depeering as an IPv6 driver (was: Re: Sprint / Cogent) In-Reply-To: <5E32C00D-9BBE-42D6-93E0-3651CD46ADBA@puck.nether.net> References: <200810302208.m9UM8OrO009591@aurora.sol.net> <490A3B61.9080905@ai.net> <5E32C00D-9BBE-42D6-93E0-3651CD46ADBA@puck.nether.net> Message-ID: <366100670810301611j2bce0814kac1cfff72bf50de0@mail.gmail.com> On 10/30/08, Jared Mauch wrote: > > > On Oct 30, 2008, at 6:55 PM, Deepak Jain wrote: > > I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single >> homed) user to access now missing parts of the Internet. Me thinks, yes. >> > > So would some "CGN" (Carrier Grade Nat anyone) too. > > Last I knew Cogent wasn't doing any IPv6.. has that changed? > > - Jared > > Not that I know of. We tried to get IPv6 transit from Cogent several months ago (we already have IPv4 transit), and were told it's not available yet. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From vgill at vijaygill.com Thu Oct 30 21:19:46 2008 From: vgill at vijaygill.com (vijay gill) Date: Thu, 30 Oct 2008 19:19:46 -0700 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> Message-ID: <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off. To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering. /vijay On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart wrote: > Hi there... > > I'm in a meeting next week to discuss settlement-free peering etc..... > always an interesting time. A push is on (by myself) to get into other > physical locations and participate on the peering exchanges. > > Besides costs, what other factors are benefits to peering? > > I can think of some but looking to develop a concrete list of appealing > reasons etc. such as: > > -control over routing between networks > -security aspect (being able to filter/verify routes to some degree) > -latency/performance > > > Just looking for other positive ideas etc...;) > > Cheers! > > Paul > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > From tomb at byrneit.net Thu Oct 30 21:34:00 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 30 Oct 2008 18:34:00 -0800 Subject: Peering - Benefits? In-Reply-To: <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy. So far, most of the discussion has focused on peering as a substitute for transit. The idea behind peering is not that the peer takes your traffic destined for other networks, but that you each deliver the traffic destined for each other directly, without the need to transit. This should save BOTH of you $ on transit, reduce routing complexity for the peered networks, make troubleshooting traffic issues between the networks easier, and improve user experience. Common examples of where peering makes a lot of sense are: Major hosting providers to major national end-user networks. CDNs to end-user networks. Local data centers and DR facilities to metropolitan Ethernet providers. Hosting facilities to networks that service certain specific user communities, such as local realty MLS systems to the local cable and DSL providers. If you're using peering for transit, you're kind of missing the point, and introducing a lot of potential network (route leakage or excessive route prepends) and business (at what point does a transit imbalance become unfair) problems. IMO, peer for direct delivery, use transit for all else. YMMV >-----Original Message----- >From: vijay gill [mailto:vgill at vijaygill.com] >Sent: Thursday, October 30, 2008 7:20 PM >To: Paul Stewart >Cc: nanog at nanog.org >Subject: Re: Peering - Benefits? > >This is probably going to be a somewhat unpopular opinion, mostly >because people cannot figure out their COGS. If you can get transit >for cheaper than your COGS, you are better off buying transit and not >peering. There are some small arguments to be made for latency and >'cheap/free' peering if you are already buying transit at an exchange >and your port/xconn fee is cheaper than your capital/opex for the >amount of traffic you peer off. > >To be completely realistic, at current transit pricing, you are almost >always better off just buying transit from two upstreams and calling >it done, especially if you are posting to nanog asking about peering. > >/vijay > > >On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart > wrote: >> Hi there... >> >> I'm in a meeting next week to discuss settlement-free peering etc..... >> always an interesting time. A push is on (by myself) to get into >other >> physical locations and participate on the peering exchanges. >> >> Besides costs, what other factors are benefits to peering? >> >> I can think of some but looking to develop a concrete list of >appealing >> reasons etc. such as: >> >> -control over routing between networks >> -security aspect (being able to filter/verify routes to some degree) >> -latency/performance >> >> >> Just looking for other positive ideas etc...;) >> >> Cheers! >> >> Paul >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >------ >> >> "The information transmitted is intended only for the person or entity >to which it is addressed and contains confidential and/or privileged >material. If you received this in error, please contact the sender >immediately and then destroy this transmission, including all >attachments, without copying, distributing or disclosing same. Thank >you." >> >> From jbates at brightok.net Thu Oct 30 22:21:55 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 30 Oct 2008 22:21:55 -0500 Subject: Depeering as an IPv6 driver In-Reply-To: <366100670810301611j2bce0814kac1cfff72bf50de0@mail.gmail.com> References: <200810302208.m9UM8OrO009591@aurora.sol.net> <490A3B61.9080905@ai.net> <5E32C00D-9BBE-42D6-93E0-3651CD46ADBA@puck.nether.net> <366100670810301611j2bce0814kac1cfff72bf50de0@mail.gmail.com> Message-ID: <490A79D3.4040307@brightok.net> Brandon Galbraith wrote: > Not that I know of. We tried to get IPv6 transit from Cogent several months > ago (we already have IPv4 transit), and were told it's not available yet. > What a shame. It's extremely miserable, but Sprint has a 6to4 at least. No clue what they have beyond that. It's been a big motivator for us peering native IPv6 so we can push our customers away from that death trap. Yeah, we can tunnel, but most tunnel peers seem low band. Jack From paul.f at hostdime.com Thu Oct 30 22:35:46 2008 From: paul.f at hostdime.com (Paul Fleming) Date: Thu, 30 Oct 2008 23:35:46 -0400 Subject: Sprint / Cogent In-Reply-To: <366100670810301554k6f43754bm8e91ba7f4564e586@mail.gmail.com> References: <200810302208.m9UM8OrO009591@aurora.sol.net> <366100670810301554k6f43754bm8e91ba7f4564e586@mail.gmail.com> Message-ID: <490A7D12.9010804@hostdime.com> http://www.earthtimes.org/articles/show/sprint-nextel-severs-its-internet-connection-to-cogent-communications,603138.shtml Brandon Galbraith wrote: > On 10/30/08, Patrick W. Gilmore wrote: > >> On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: >> >> Looks like maybe Sprint and Cogent are experiencing communications >> >>> difficulties in the DC (and probably other) areas. Theories include >>> a potential depeering. >>> >>> >> Not a theory. >> >> >> > Indeed. It appears, using Sprint's looking glass, that they're completely > partitioned from Cogent. YMMV. > > -brandon > > > -- Paul R Fleming Lead Network Administrator Dimenoc Inc Cell - (407)-267-0227 Office - (407)-756-1126 ext 3001 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature URL: From brandon.galbraith at gmail.com Thu Oct 30 22:41:02 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 30 Oct 2008 22:41:02 -0500 Subject: Sprint / Cogent In-Reply-To: <490A7D12.9010804@hostdime.com> References: <200810302208.m9UM8OrO009591@aurora.sol.net> <366100670810301554k6f43754bm8e91ba7f4564e586@mail.gmail.com> <490A7D12.9010804@hostdime.com> Message-ID: <366100670810302041o4f6e1de5v17ed08f1d02a2db2@mail.gmail.com> On 10/30/08, Paul Fleming wrote: > > > http://www.earthtimes.org/articles/show/sprint-nextel-severs-its-internet-connection-to-cogent-communications,603138.shtml > > The most interesting part of the press release to me is: In the over 1300 on-net locations worldwide where Cogent provides service, Cogent is offering every Sprint-Nextel wireline customer that is unable to connect to Cogent's customers a free 100 megabit per second connection to the Internet for as long as Sprint continues to keep this partitioning of the Internet in place. Unfortunately, there is no way that Cogent can do the same for the wireless customers of Sprint-Nextel. -brandon From repstein at chello.at Thu Oct 30 22:53:37 2008 From: repstein at chello.at (Randy Epstein) Date: Thu, 30 Oct 2008 23:53:37 -0400 Subject: Sprint / Cogent In-Reply-To: <366100670810302041o4f6e1de5v17ed08f1d02a2db2@mail.gmail.com> References: <200810302208.m9UM8OrO009591@aurora.sol.net><366100670810301554k6f43754bm8e91ba7f4564e586@mail.gmail.com><490A7D12.9010804@hostdime.com> <366100670810302041o4f6e1de5v17ed08f1d02a2db2@mail.gmail.com> Message-ID: <6C9EBD9CB27E4097A4DFC695A03CF523@D88CFA77634F40F> >The most interesting part of the press release to me is: >In the over 1300 on-net locations worldwide where Cogent provides service, >Cogent is offering every Sprint-Nextel wireline customer that is unable to >connect to Cogent's customers a free 100 megabit per second connection to >the Internet for as long as Sprint continues to keep this partitioning of >the Internet in place. Unfortunately, there is no way that Cogent can do >the same for the wireless customers of Sprint-Nextel. This wasn't the first time Cogent offered something similar. They did the same thing when Level3 depeered them. Randy From patrick at ianai.net Thu Oct 30 23:41:04 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 31 Oct 2008 00:41:04 -0400 Subject: Peering - Benefits? In-Reply-To: <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> Message-ID: <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> On Oct 30, 2008, at 10:19 PM, vijay gill wrote: > This is probably going to be a somewhat unpopular opinion, mostly > because people cannot figure out their COGS. If you can get transit > for cheaper than your COGS, you are better off buying transit and not > peering. There are some small arguments to be made for latency and > 'cheap/free' peering if you are already buying transit at an exchange > and your port/xconn fee is cheaper than your capital/opex for the > amount of traffic you peer off. One of us is confused. Transit is _part_ of COGS, at least for most of the group reading this list. Finding transit "cheaper than your COGS" just means cheaper than you get it now. And that in no way way means you should dump peering. What if peering is cheaper than transit? The part where we do agree is that most people cannot figure out their COGS. And you might even convince me that "you don't know what peering really costs you" is a valid reason to shy away from it. But that is not what you said. Assuming you can figure your actual costs, and peering is at least break even with transit, I would suggest you peer. If peering is not cheaper, then I would suggest not doing it. (Obviously a generalization - there are corner cases which go against the rule.) And if you cannot figure your actual costs, it is much safer to stick with the more simple solution - i.e. transit. > To be completely realistic, at current transit pricing, you are almost > always better off just buying transit from two upstreams and calling > it done, especially if you are posting to nanog asking about peering. That is a pretty broad statement. Not that I think you are wrong.... I honestly am not sure at this point. (Mostly 'cause I'm not sure who would e-mail NANOG asking about it. :-) -- TTFN, patrick > On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart > wrote: >> Hi there... >> >> I'm in a meeting next week to discuss settlement-free peering >> etc..... >> always an interesting time. A push is on (by myself) to get into >> other >> physical locations and participate on the peering exchanges. >> >> Besides costs, what other factors are benefits to peering? >> >> I can think of some but looking to develop a concrete list of >> appealing >> reasons etc. such as: >> >> -control over routing between networks >> -security aspect (being able to filter/verify routes to some degree) >> -latency/performance >> >> >> Just looking for other positive ideas etc...;) >> >> Cheers! >> >> Paul >> >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "The information transmitted is intended only for the person or >> entity to which it is addressed and contains confidential and/or >> privileged material. If you received this in error, please contact >> the sender immediately and then destroy this transmission, >> including all attachments, without copying, distributing or >> disclosing same. Thank you." >> >> > From vgill at vijaygill.com Fri Oct 31 00:05:58 2008 From: vgill at vijaygill.com (vijay gill) Date: Thu, 30 Oct 2008 22:05:58 -0700 Subject: Peering - Benefits? In-Reply-To: <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> Message-ID: <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore wrote: > On Oct 30, 2008, at 10:19 PM, vijay gill wrote: > >> This is probably going to be a somewhat unpopular opinion, mostly >> because people cannot figure out their COGS. If you can get transit >> for cheaper than your COGS, you are better off buying transit and not >> peering. There are some small arguments to be made for latency and >> 'cheap/free' peering if you are already buying transit at an exchange >> and your port/xconn fee is cheaper than your capital/opex for the >> amount of traffic you peer off. > > One of us is confused. precisely. > > Transit is _part_ of COGS, at least for most of the group reading this list. > Finding transit "cheaper than your COGS" just means cheaper than you get it > now. And that in no way way means you should dump peering. What if peering > is cheaper than transit? Cost of transport, opex and capital to build out to a peering point, ports for interconnect, vs the expected money saved by peering away sufficient traffic is the analysis that will inform your strategy. This is why I said if you are already at a place where you are buying transit, it probably worth it to peer with the folks locally. The point is if you are building out specifically to peer, the effort is not worth it if you are not operating at scale, and if you are operating at scale, you are not going to ask nanog about peering. /vijay > > The part where we do agree is that most people cannot figure out their COGS. > And you might even convince me that "you don't know what peering really > costs you" is a valid reason to shy away from it. But that is not what you > said. > > > Assuming you can figure your actual costs, and peering is at least break > even with transit, I would suggest you peer. If peering is not cheaper, > then I would suggest not doing it. (Obviously a generalization - there are > corner cases which go against the rule.) And if you cannot figure your > actual costs, it is much safer to stick with the more simple solution - i.e. > transit. > >> To be completely realistic, at current transit pricing, you are almost >> always better off just buying transit from two upstreams and calling >> it done, especially if you are posting to nanog asking about peering. > > That is a pretty broad statement. > > Not that I think you are wrong.... I honestly am not sure at this point. > (Mostly 'cause I'm not sure who would e-mail NANOG asking about it. :-) > > -- > TTFN, > patrick > > > >> On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart >> wrote: >>> >>> Hi there... >>> >>> I'm in a meeting next week to discuss settlement-free peering etc..... >>> always an interesting time. A push is on (by myself) to get into other >>> physical locations and participate on the peering exchanges. >>> >>> Besides costs, what other factors are benefits to peering? >>> >>> I can think of some but looking to develop a concrete list of appealing >>> reasons etc. such as: >>> >>> -control over routing between networks >>> -security aspect (being able to filter/verify routes to some degree) >>> -latency/performance >>> >>> >>> Just looking for other positive ideas etc...;) >>> >>> Cheers! >>> >>> Paul >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> "The information transmitted is intended only for the person or entity to >>> which it is addressed and contains confidential and/or privileged material. >>> If you received this in error, please contact the sender immediately and >>> then destroy this transmission, including all attachments, without copying, >>> distributing or disclosing same. Thank you." >>> >>> >> > > > From randy at psg.com Fri Oct 31 00:12:24 2008 From: randy at psg.com (Randy Bush) Date: Fri, 31 Oct 2008 09:12:24 +0400 Subject: Peering - Benefits? In-Reply-To: <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> Message-ID: <490A93B8.2010809@psg.com> > The point is if you are building out specifically to peer, the effort > is not worth it if you are not operating at scale, ^ probably i can think of situations where there may be very low cost to build-out to peer. but they are unusual. > and if you are operating at scale, you are not going to ask nanog > about peering. bingo! ( unless you're a shill being paid to give us old dogs an excuse to pontificate :) randy From patrick at ianai.net Fri Oct 31 00:13:03 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 31 Oct 2008 01:13:03 -0400 Subject: Peering - Benefits? In-Reply-To: <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> Message-ID: On Oct 31, 2008, at 1:05 AM, vijay gill wrote: > On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore > wrote: >> On Oct 30, 2008, at 10:19 PM, vijay gill wrote: >> >>> This is probably going to be a somewhat unpopular opinion, mostly >>> because people cannot figure out their COGS. If you can get transit >>> for cheaper than your COGS, you are better off buying transit >>> There are some small arguments to be made for latency and >>> 'cheap/free' peering if you are already buying transit at an >>> exchange >>> and your port/xconn fee is cheaper than your capital/opex for the >>> amount of traffic you peer off. >> >> One of us is confused. > > precisely. Well, I could also be confused, which would make two of us. But I will agree with you here and say precisely one. >> Transit is _part_ of COGS, at least for most of the group reading >> this list. >> Finding transit "cheaper than your COGS" just means cheaper than >> you get it >> now. And that in no way way means you should dump peering. What >> if peering >> is cheaper than transit? > > Cost of transport, opex and capital to build out to a peering point, > ports for interconnect, vs the expected money saved by peering away > sufficient traffic is the analysis that will inform your strategy. > This is why I said if you are already at a place where you are buying > transit, it probably worth it to peer with the folks locally. None of that is in question. However, you also said: "If you can get transit for cheaper than your COGS, you are better off buying transit and not peering." So either you were confused, or .. well, let's be generous and say you were confused. :-) I'm glad you have cleared your confusion. -- TTFN, patrick From vgill at vijaygill.com Fri Oct 31 00:17:21 2008 From: vgill at vijaygill.com (vijay gill) Date: Thu, 30 Oct 2008 22:17:21 -0700 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> Message-ID: <21ef2c1c0810302217m406e85edq414652d3234110d2@mail.gmail.com> On Thu, Oct 30, 2008 at 10:13 PM, Patrick W. Gilmore wrote: > On Oct 31, 2008, at 1:05 AM, vijay gill wrote: >> >> On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore >> wrote: >>> >>> On Oct 30, 2008, at 10:19 PM, vijay gill wrote: >>> >>>> This is probably going to be a somewhat unpopular opinion, mostly >>>> because people cannot figure out their COGS. If you can get transit >>>> for cheaper than your COGS, you are better off buying transit There are >>>> some small arguments to be made for latency and >>>> 'cheap/free' peering if you are already buying transit at an exchange >>>> and your port/xconn fee is cheaper than your capital/opex for the >>>> amount of traffic you peer off. >>> >>> One of us is confused. >> >> precisely. > > Well, I could also be confused, which would make two of us. But I will > agree with you here and say precisely one. > > >>> Transit is _part_ of COGS, at least for most of the group reading this >>> list. >>> Finding transit "cheaper than your COGS" just means cheaper than you get >>> it >>> now. And that in no way way means you should dump peering. What if >>> peering >>> is cheaper than transit? >> >> Cost of transport, opex and capital to build out to a peering point, >> ports for interconnect, vs the expected money saved by peering away >> sufficient traffic is the analysis that will inform your strategy. >> This is why I said if you are already at a place where you are buying >> transit, it probably worth it to peer with the folks locally. > > None of that is in question. However, you also said: "If you can get > transit for cheaper than your COGS, you are better off buying transit and > not peering." So either you were confused, or .. well, let's be generous > and say you were confused. :-) > > I'm glad you have cleared your confusion. Yeah, I was using COGs as a shorthand for cost to build out to peering locations, I should have really further broken it down into specific cases. /vijay > > -- > TTFN, > patrick > > > From jlloret at dcom.upv.es Fri Oct 31 04:19:08 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Fri, 31 Oct 2008 10:19:08 +0100 Subject: Deadline extension: ICNS 2009 + 1st Workshop LMPCNAP | April 21-25, 2009 - Valencia, Spain Message-ID: <200810310919.m9V9J86g026999@smtp.upv.es> Note that the deadline extension for ICNS 2009 has been extended to November 10. We would like to make ICNS 2009 a primary reference event. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Please note that extended versions of highly ranked papers will be invited for journals submission. Full contributions are expected by the submission deadline. =========== ICNS 2009 + 1st Workshop LMPCNAP | Call for Papers =========== CALL FOR PAPERS, TUTORIALS, PANELS - ICNS 2009, The Fifth International Conference on Networking and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/ICNS09.html Call for Papers: http://www.iaria.org/conferences2009/CfPICNS09.html - The first International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy Program (CNAP), LMPCNAP 2009 will be held during ICNS 2009 in April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/LMPCNAP.html Important deadlines: Submission (full paper) November 10, 2008 Authors notification December 5, 2008 Registration December 20, 2008 Camera ready December 25, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum special submission with on progress and challenging ideas. ICNS 2009 Area Tracks are the following (details in the CfP on site): ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications IPv6DFI: Deploying the Future Infrastructure IPDy: Internet Packet Dynamics GOBS: GRID over Optical Burst Switching Networks ================================= - ICNS General Chair Jaime Lloret Mauri, Polytechnic University of Valencia, Spain - ICNS 2009 Industry Chairs Kevin Y Ung, Boeing, USA Leo Lehmann, OFCOM, Switzerland Francisco Javier S?nchez, Administrador de Infraestructuras Ferroviarias (ADIF), Spain - ICNS 2009 Technical Program Committee Chair Giancarlo Fortino, Universit? della Calabria, Italy Salvador Sales, Polytechnic University of Valencia, Spain Feng Xia, Queensland University of Technology, Australia / Zhejiang University, China - ICNS Advisory Chairs Wojciech Burakowski, Warsaw University of Technology, Poland Vicente Casares, Polytechnic University of Valencia, Spain Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Xiaohua Jia, City University of Hong Kong - Kowloon, Hong Kong Manuel Sierra-P?rez, Universidad Polit?cnica de Madrid, Spain - LMPCNAP 2009 General Chair Rafael Tomas, Mediterranean Cisco Academy Training Center (CATC), Spain - LMPCNAP 2009 Technical Program Commitee chair Prof. Tomeu Serra, Universitat de les Illes Balears, Spain ================================ From pstewart at nexicomgroup.net Fri Oct 31 05:06:32 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 31 Oct 2008 06:06:32 -0400 Subject: Peering - Benefits? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B4782D@nexus.nexicomgroup.net> There was no attempt to provoke controversy - I'm in the OP in this... there have been many replies that don't relate to my question though... I don't believe I have a lack of understanding neither - we do smaller scale peering today. I was however trying to look for positive and negative reasons for peering that perhaps we didn't take into consideration beyond how we do it today... the only change for our peering will be the element of long hauling the traffic and expanding it into larger scales - that's about it. Basically I have all the answers I'm looking for now - thank you. Paul -----Original Message----- From: Tomas L. Byrnes [mailto:tomb at byrneit.net] Sent: October 30, 2008 10:34 PM To: vijay gill; Paul Stewart Cc: nanog at nanog.org Subject: RE: Peering - Benefits? As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From pstewart at nexicomgroup.net Fri Oct 31 05:14:37 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 31 Oct 2008 06:14:37 -0400 Subject: Peering - Benefits? In-Reply-To: <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com><2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B4782E@nexus.nexicomgroup.net> Hi there... We've done the financial study and we've taken great lengths in netflow analysis to do estimated traffic flows at each peering location etc. This was factored before I posted and as I mentioned in an earlier posting - the cost element is pretty much addressed already with our transit/peering coming in almost at the same cost when the built-out is completed. We are already peering locally with the folks where most of our transit comes from - been doing that for quite a period of time... >Cost of transport, opex and capital to build out to a peering point, >ports for interconnect, vs the expected money saved by peering away >sufficient traffic is the analysis that will inform your strategy. >This is why I said if you are already at a place where you are buying >transit, it probably worth it to peer with the folks locally. My question was meant at a much higher level - a level where costs are equal for peering/transit and all the "technical" and the "financial" homework has been done already.... now I'm the stage of one last meeting with top level management to explain "peering" and it's magic. These are mainly non-technical people - so my question to NANOG was for viewpoints on peering of which hopefully I could reinforce some of my own thoughts with. Whether or not someone operating at scale isn't the discussion - and it's funny how many people involved with companies (that are "operating at scale") have emailed me offline since this discussion started a few days ago with questions/thoughts and strategy. >The point is if you are building out specifically to peer, the effort >is not worth it if you are not operating at scale, and if you are >operating at scale, you are not going to ask nanog about peering. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From cidr-report at potaroo.net Fri Oct 31 06:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Oct 2008 22:00:04 +1100 (EST) Subject: BGP Update Report Message-ID: <200810311100.m9VB040S043898@wattle.apnic.net> BGP Update Report Interval: 29-Sep-08 -to- 30-Oct-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 194959 1.8% 174.2 -- SIFY-AS-IN Sify Limited 2 - AS4538 117869 1.1% 23.2 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS6389 96967 0.9% 22.0 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS1803 93586 0.9% 67.4 -- ICMNET-5 - Sprint 5 - AS6629 71416 0.7% 1098.7 -- NOAA-AS - NOAA 6 - AS20115 67120 0.6% 28.7 -- CHARTER-NET-HKY-NC - Charter Communications 7 - AS8151 65720 0.6% 27.4 -- Uninet S.A. de C.V. 8 - AS5691 64633 0.6% 4971.8 -- MITRE-AS-5 - The MITRE Corporation 9 - AS9051 61506 0.6% 384.4 -- IDM Autonomous System 10 - AS10396 50322 0.5% 653.5 -- COQUI-NET - DATACOM CARIBE, INC. 11 - AS7046 48974 0.5% 82.9 -- UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 12 - AS2386 45822 0.4% 27.8 -- INS-AS - AT&T Data Communications Services 13 - AS22492 44217 0.4% 14739.0 -- 14 - AS20255 43679 0.4% 1409.0 -- Tecnowind S.A. 15 - AS209 43308 0.4% 13.6 -- ASN-QWEST - Qwest Communications Corporation 16 - AS6458 43061 0.4% 106.9 -- Telgua 17 - AS10986 42338 0.4% 475.7 -- Intermedia Comunicaciones S.A. 18 - AS7643 41356 0.4% 23.8 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 19 - AS17974 40394 0.4% 49.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS34116 39164 0.4% 391.6 -- CYBER-AS Cyber Net AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 37576 0.3% 37576.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS43299 21481 0.2% 21481.0 -- TELECONTACT-AS Telecontact Ltd. 3 - AS22492 44217 0.4% 14739.0 -- 4 - AS37026 21593 0.2% 10796.5 -- SALT-ASN 5 - AS5691 64633 0.6% 4971.8 -- MITRE-AS-5 - The MITRE Corporation 6 - AS30287 4469 0.0% 4469.0 -- ALON-USA - ALON USA, LP 7 - AS21603 36845 0.3% 3684.5 -- Universidad La Salle, AC 8 - AS23082 18245 0.2% 3649.0 -- MPHI - Michigan Public Health Institute 9 - AS30969 29150 0.3% 3643.8 -- TAN-NET TransAfrica Networks 10 - AS29910 3501 0.0% 3501.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 11 - AS41007 15591 0.1% 3118.2 -- CTCASTANA CTC ASTANA, KZ 12 - AS4130 15251 0.1% 3050.2 -- UPITT-AS - University of Pittsburgh 13 - AS8266 2934 0.0% 2934.0 -- NEXUSTEL Nexus Telecommunications 14 - AS38180 2450 0.0% 2450.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 15 - AS5033 20329 0.2% 2258.8 -- ISW - Internet Specialties West Inc. 16 - AS23917 2238 0.0% 2238.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 17 - AS44194 2078 0.0% 2078.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 18 - AS25799 1998 0.0% 1998.0 -- HOLMAN - Holman Enterprises 19 - AS39105 1888 0.0% 1888.0 -- CLASS-AS SC Class Computers And Service SRL 20 - AS42521 1724 0.0% 1724.0 -- COFUND-AS Fundacja Fundusz Wspolpracy TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 64364 0.6% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 62651 0.6% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 60986 0.6% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 46255 0.4% AS9583 -- SIFY-AS-IN Sify Limited 5 - 194.126.143.0/24 44980 0.4% AS9051 -- IDM Autonomous System 6 - 12.2.46.0/24 44187 0.4% AS22492 -- 7 - 12.8.7.0/24 37576 0.3% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 8 - 200.33.104.0/23 36176 0.3% AS21603 -- Universidad La Salle, AC 9 - 221.128.192.0/18 25369 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 10 - 192.102.88.0/24 23637 0.2% AS6629 -- NOAA-AS - NOAA 11 - 196.42.0.0/20 23578 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 12 - 198.77.177.0/24 23532 0.2% AS6629 -- NOAA-AS - NOAA 13 - 72.50.96.0/20 23493 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 192.35.129.0/24 23460 0.2% AS6629 -- NOAA-AS - NOAA 15 - 78.40.24.0/21 21481 0.2% AS43299 -- TELECONTACT-AS Telecontact Ltd. 16 - 200.108.200.0/24 21443 0.2% AS20255 -- Tecnowind S.A. 17 - 200.108.220.0/24 21434 0.2% AS20255 -- Tecnowind S.A. 18 - 64.162.116.0/24 20217 0.2% AS5033 -- ISW - Internet Specialties West Inc. 19 - 89.4.131.0/24 15291 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 150.212.224.0/19 15199 0.1% AS4130 -- UPITT-AS - University of Pittsburgh Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 31 06:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Oct 2008 22:00:01 +1100 (EST) Subject: The Cidr Report Message-ID: <200810311100.m9VB01uL043888@wattle.apnic.net> This report has been generated at Fri Oct 31 21:32:47 2008 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 24-10-08 285588 174160 25-10-08 286298 174393 25-10-08 285672 174887 27-10-08 285587 175208 28-10-08 285651 174054 29-10-08 286163 173898 30-10-08 286157 174074 31-10-08 286084 173860 AS Summary 29805 Number of ASes in routing system 12615 Number of ASes announcing only one prefix 5049 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88278016 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 31Oct08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 285791 173743 112048 39.2% All ASes AS4538 5049 871 4178 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4359 351 4008 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3052 1326 1726 56.6% ASN-QWEST - Qwest Communications Corporation AS1785 1696 164 1532 90.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 2045 681 1364 66.7% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS4755 1499 251 1248 83.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1403 303 1100 78.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1562 479 1083 69.3% TWTC - tw telecom holdings, inc. AS22773 1001 66 935 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1400 543 857 61.2% Uninet S.A. de C.V. AS11492 1211 462 749 61.8% CABLEONE - CABLE ONE, INC. AS19262 946 223 723 76.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1594 916 678 42.5% INS-AS - AT&T Data Communications Services AS6478 1324 649 675 51.0% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 426 633 59.8% COVAD - Covad Communications Co. AS9498 692 115 577 83.4% BBIL-AP BHARTI Airtel Ltd. AS18101 782 208 574 73.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1056 484 572 54.2% LEVEL3 Level 3 Communications AS4808 627 155 472 75.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 611 140 471 77.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS855 590 142 448 75.9% CANET-ASN-4 - Bell Aliant AS17676 522 79 443 84.9% GIGAINFRA BB TECHNOLOGY Corp. AS9443 526 84 442 84.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS24560 601 159 442 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 566 127 439 77.6% VTR BANDA ANCHA S.A. AS7018 1426 990 436 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS7011 923 495 428 46.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4134 869 447 422 48.6% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 688 276 412 59.9% LGNET-AS-KR LG CNS AS4804 484 84 400 82.6% MPX-AS Microplex PTY LTD Total 40163 11696 28467 70.9% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 94.228.144.0/20 AS31662 KNSURSELVA aurax connecta AG 94.232.80.0/21 AS6799 OTENET-GR OTEnet S.A. Multiprotocol Backbone & ISP 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 124.109.16.0/21 AS38137 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 169.254.0.0/16 AS13184 HANSENET HanseNet Telekommunikation GmbH 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.168.80.0/21 AS24034 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nick at inex.ie Fri Oct 31 06:47:39 2008 From: nick at inex.ie (Nick Hilliard) Date: Fri, 31 Oct 2008 11:47:39 +0000 Subject: Sprint / Cogent Message-ID: <490AF05B.7000502@inex.ie> >>The most interesting part of the press release to me is: > >>In the over 1300 on-net locations worldwide where Cogent provides service, >>Cogent is offering every Sprint-Nextel wireline customer that is unable to >>connect to Cogent's customers a free 100 megabit per second connection to >>the Internet for as long as Sprint continues to keep this partitioning of >>the Internet in place. Unfortunately, there is no way that Cogent can do >>the same for the wireless customers of Sprint-Nextel. > > This wasn't the first time Cogent offered something similar. They did the > same thing when Level3 depeered them. And they'll do it to others in future peering spats. It's just a bullying tactic - entertaining if you're on the sideline; irritating if you're Sprint. Cogent reminds me of Ethan Coen's poem, which starts: The loudest has the final say, The wanton win, the rash hold sway, The realist's rules of order say The drunken driver has the right of way. Nick From tore at linpro.no Fri Oct 31 07:45:05 2008 From: tore at linpro.no (Tore Anderson) Date: Fri, 31 Oct 2008 13:45:05 +0100 Subject: Another driver for v6? In-Reply-To: <20081029232940.GC5212@isc.org> References: <20081028224053.35f85438@cs.columbia.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> Message-ID: <200810311345.05174.tore@linpro.no> * David W. Hankins > It is almost lunacy to deploy IPv6 in a customer-facing sense (note > for example Google's choice to put its AAAA on a separate FQDN). At > this point, I'd say people are still trying to figure out how clients > will migrate to IPv6. Which seems like a pretty bad time to still be > trying to figure that out, but ohwell. Google has been testing this a bit on their main pages. Select quotes from the presentation of their results: > 0.238% of users have useful IPv6 connectivity (and prefer IPv6) > 0.09% of users have broken IPv6 connectivity The summary disagrees with you about the ?almost lunacy? part: > It's not that broken > - ~0.09% clients lost, ~150ms extra latency - don't believe the FUD The slides are here, they're worth a look in my opinion: http://rosie.ripe.net/ripe/meetings/ripe-57/presentations/uploads/Thursday/Plenary 14:00/upl/Colitti-Global_IPv6_statistics_-_Measuring_the_current_state_of_IPv6_for_ordinary_users.xD5A.pdf Best regards, -- Tore Anderson From justin at justinshore.com Fri Oct 31 08:03:11 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 31 Oct 2008 08:03:11 -0500 Subject: Sprint / Cogent In-Reply-To: <490AF05B.7000502@inex.ie> References: <490AF05B.7000502@inex.ie> Message-ID: <490B020F.7040101@justinshore.com> Nick Hilliard wrote: > And they'll do it to others in future peering spats. It's just a > bullying tactic - entertaining if you're on the sideline; irritating if > you're Sprint. > > Cogent reminds me of Ethan Coen's poem, which starts: > > The loudest has the final say, > The wanton win, the rash hold sway, > The realist's rules of order say > The drunken driver has the right of way. So why do SPs keep depeering Cogent? Serious question, why? I'm not aware of any Intercage-like issues with them. I've actually considered them as a potential upstream when we expand into a market they serve. Justin From pstewart at nexicomgroup.net Fri Oct 31 08:17:24 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 31 Oct 2008 09:17:24 -0400 Subject: Sprint / Cogent In-Reply-To: <490B020F.7040101@justinshore.com> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B4787A@nexus.nexicomgroup.net> Best guess would be traffic ratio related - that always seems to be related to de-peering. One side doesn't like the amount of traffic coming in versus going out etc... Paul -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Friday, October 31, 2008 9:03 AM To: Nick Hilliard Cc: nanog at nanog.org Subject: Re: Sprint / Cogent Nick Hilliard wrote: > And they'll do it to others in future peering spats. It's just a > bullying tactic - entertaining if you're on the sideline; irritating if > you're Sprint. > > Cogent reminds me of Ethan Coen's poem, which starts: > > The loudest has the final say, > The wanton win, the rash hold sway, > The realist's rules of order say > The drunken driver has the right of way. So why do SPs keep depeering Cogent? Serious question, why? I'm not aware of any Intercage-like issues with them. I've actually considered them as a potential upstream when we expand into a market they serve. Justin ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jgreco at ns.sol.net Fri Oct 31 08:23:12 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 31 Oct 2008 07:23:12 -0600 (CST) Subject: Sprint / Cogent In-Reply-To: <490AF05B.7000502@inex.ie> from "Nick Hilliard" at Oct 31, 2008 11:47:39 AM Message-ID: <200810311323.m9VDNCcI081807@aurora.sol.net> > > This wasn't the first time Cogent offered something similar. They did the > > same thing when Level3 depeered them. > > And they'll do it to others in future peering spats. It's just a bullying > tactic - entertaining if you're on the sideline; irritating if you're Sprint. It is certainly not "just" a bullying tactic. It may be "A" bullying tactic, I won't even attempt to guess at the intent, but the tactic also has the very real side effect of re-establishing full connectivity to Sprint-connected sites that lose it. Given that other very significant result of the tactic, it is clearly not "just a bullying tactic." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cfriacas at fccn.pt Fri Oct 31 08:23:47 2008 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 31 Oct 2008 13:23:47 +0000 (WET) Subject: Depeering as an IPv6 driver (was: Re: Sprint / Cogent) In-Reply-To: <366100670810301611j2bce0814kac1cfff72bf50de0@mail.gmail.com> References: <200810302208.m9UM8OrO009591@aurora.sol.net> <490A3B61.9080905@ai.net> <5E32C00D-9BBE-42D6-93E0-3651CD46ADBA@puck.nether.net> <366100670810301611j2bce0814kac1cfff72bf50de0@mail.gmail.com> Message-ID: On Thu, 30 Oct 2008, Brandon Galbraith wrote: > On 10/30/08, Jared Mauch wrote: >> >> >> On Oct 30, 2008, at 6:55 PM, Deepak Jain wrote: >> >> I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single >>> homed) user to access now missing parts of the Internet. Me thinks, yes. >>> >> >> So would some "CGN" (Carrier Grade Nat anyone) too. >> >> Last I knew Cogent wasn't doing any IPv6.. has that changed? >> >> - Jared >> >> > Not that I know of. We tried to get IPv6 transit from Cogent several months > ago (we already have IPv4 transit), and were told it's not available yet. Did they provide you with a roadmap ? :-) ./Carlos > -brandon > > -- > Brandon Galbraith > Voice: 630.400.6992 > Email: brandon.galbraith at gmail.com > From alex at corp.nac.net Fri Oct 31 08:47:35 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 31 Oct 2008 09:47:35 -0400 Subject: Sprint / Cogent In-Reply-To: <490B020F.7040101@justinshore.com> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> Message-ID: > So why do SPs keep depeering Cogent? Serious question, why? I'm not > aware of any Intercage-like issues with them. I've actually considered > them as a potential upstream when we expand into a market they serve. Because some SP's still have a sour taste in their mouth about what Cogent did to the marketplace when they started. If you recall, they were the most disturbing force in the transit wars (not to be confused with the cola or fast-food wars), when they came out with $3,000 fast-Ethernets, and everyone else was enjoying $100+/meg. In my opinion, this was the free market at work, and look -- the market as continued to thrive with plenty of competition. Not being a customer of either of these guys, I could care less about this. While Sprint most certainly has their reasons, I think generally speaking people care less about this sort of thing these days. 1239 is certainly not the force that they used to be, and they should realize it and stop being stupid. Why do I say stupid? Because, if companies like Sprint continue to do things like what Sprint is doing, this will certainly lead to being noticed by legislators, and the next thing we know we will have federally regulated peering or backbone network operating. I can see it now, the Bureau of Peering will be part of the Federal Networking Committee. Does anyone want that? I certainly don't. Again, not because it would overly affect me, it's just more regulation which we don't need. I'll crawl back under my rock now. From tme at multicasttech.com Fri Oct 31 08:49:31 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 31 Oct 2008 09:49:31 -0400 Subject: Sprint / Cogent In-Reply-To: <490AF05B.7000502@inex.ie> References: <490AF05B.7000502@inex.ie> Message-ID: On Oct 31, 2008, at 7:47 AM, Nick Hilliard wrote: >>> The most interesting part of the press release to me is: >> >>> In the over 1300 on-net locations worldwide where Cogent provides >>> service, >>> Cogent is offering every Sprint-Nextel wireline customer that is >>> unable to >>> connect to Cogent's customers a free 100 megabit per second >>> connection to >>> the Internet for as long as Sprint continues to keep this >>> partitioning of >>> the Internet in place. Unfortunately, there is no way that Cogent >>> can do >>> the same for the wireless customers of Sprint-Nextel. >> >> This wasn't the first time Cogent offered something similar. They >> did the >> same thing when Level3 depeered them. > > And they'll do it to others in future peering spats. It's just a > bullying tactic - entertaining if you're on the sideline; irritating > if you're Sprint. I would regard this as a good sales tactic. I don't see bullying. Regards Marshall > > > Cogent reminds me of Ethan Coen's poem, which starts: > > The loudest has the final say, > The wanton win, the rash hold sway, > The realist's rules of order say > The drunken driver has the right of way. > > Nick > From LarrySheldon at cox.net Fri Oct 31 08:52:27 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 31 Oct 2008 08:52:27 -0500 Subject: Sprint / Cogent In-Reply-To: References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> Message-ID: <490B0D9B.4070709@cox.net> Alex Rubenstein wrote: > Why do I say stupid? > > Because, if companies like Sprint continue to do things like what > Sprint is doing, this will certainly lead to being noticed by > legislators, and the next thing we know we will have federally > regulated peering or backbone network operating. I can see it now, > the Bureau of Peering will be part of the Federal Networking > Committee. I think you are wrong to the extent that BOP will be under the Department Of Fairness. From LarrySheldon at cox.net Fri Oct 31 08:54:07 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 31 Oct 2008 08:54:07 -0500 Subject: Sprint / Cogent In-Reply-To: <490B0D9B.4070709@cox.net> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> <490B0D9B.4070709@cox.net> Message-ID: <490B0DFF.4040705@cox.net> Larry Sheldon wrote: > I think you are wrong to the extent that BOP will be under the > Department Of Fairness. OOps. My bad. Ministry of Fairness. From miquels at cistron.nl Fri Oct 31 08:57:09 2008 From: miquels at cistron.nl (Miquel van Smoorenburg) Date: 31 Oct 2008 13:57:09 GMT Subject: Peering - Benefits? In-Reply-To: <9AFB2A51-6EE0-440C-9A71-4C0A4D678455@nosignal.org> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01B474A8@nexus.nexicomgroup.net> <9AFB2A51-6EE0-440C-9A71-4C0A4D678455@nosignal.org> Message-ID: <490b0eb4$0$187$e4fe514c@news.xs4all.nl> In article <9AFB2A51-6EE0-440C-9A71-4C0A4D678455 at nosignal.org>, Andy Davidson wrote: >On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von CyberBunker-Kamphuis >MP wrote: >> (the amsix with their many outages and connected parties that rely >> primarliy on it's functionality is a prime example here) > >I run interconnection for three networks connected to the ams-ix and >can't understand why you think that the ams-ix fabric has "many >outages" - I have found it, to borrow a phrase from another stable >European IXP, rock solid. The AMS-IX is a service that is present at multiple colocation providers. One or two of these are, let's say, not state of the art anymore. But that's a colo issue and doesn't have anything to do with the AMS-IX network. This is different from the US, where an internet exchange is usually tied in with one colocation provider, so I can see where the confusion comes from. Mike. From jlewis at lewis.org Fri Oct 31 08:59:19 2008 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 31 Oct 2008 09:59:19 -0400 (EDT) Subject: Sprint / Cogent In-Reply-To: <490AF05B.7000502@inex.ie> References: <490AF05B.7000502@inex.ie> Message-ID: On Fri, 31 Oct 2008, Nick Hilliard wrote: >> This wasn't the first time Cogent offered something similar. They did the >> same thing when Level3 depeered them. > > And they'll do it to others in future peering spats. It's just a bullying > tactic - entertaining if you're on the sideline; irritating if you're Sprint. It seems to me, it's a rather empty offer though. How many Sprint customers affected by the Sprint/Cogent depeering are actually in facilities where they can get that free Cogent connection without paying for expensive backhaul to reach Cogent and already have an ASN, BGP capable router(s), and globally routable CIDRS so they can access both the Sprint and Cogent views of the internet? Does anyone know how many Level3 customers Cogent actually hooked up when Level3 and Cogent stopped peering? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From elmi at 4ever.de Fri Oct 31 09:04:49 2008 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 31 Oct 2008 15:04:49 +0100 Subject: Sprint / Cogent In-Reply-To: References: <490AF05B.7000502@inex.ie> Message-ID: <20081031140449.GI93039@ronin.4ever.de> jlewis at lewis.org (Jon Lewis) wrote: > It seems to me, it's a rather empty offer though. How many Sprint > customers affected by the Sprint/Cogent depeering are actually in > facilities where they can get that free Cogent connection without paying > for expensive backhaul to reach Cogent and already have an ASN, BGP > capable router(s), and globally routable CIDRS so they can access both the > Sprint and Cogent views of the internet? The profitable ones. El "ask something complicated" mar. From jared at puck.nether.net Fri Oct 31 09:12:33 2008 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 31 Oct 2008 10:12:33 -0400 Subject: Sprint / Cogent In-Reply-To: <490B0D9B.4070709@cox.net> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> <490B0D9B.4070709@cox.net> Message-ID: <704775AC-D7FD-4DF2-A823-DF154C8B1B57@puck.nether.net> On Oct 31, 2008, at 9:52 AM, Larry Sheldon wrote: > Alex Rubenstein wrote: > >> Why do I say stupid? >> Because, if companies like Sprint continue to do things like what >> Sprint is doing, this will certainly lead to being noticed by >> legislators, and the next thing we know we will have federally >> regulated peering or backbone network operating. I can see it now, >> the Bureau of Peering will be part of the Federal Networking >> Committee. > > I think you are wrong to the extent that BOP will be under the > Department Of Fairness. the two likely entities in the United States would be either the FCC or DHS. (DHS you say?) The NCS lives under DHS. I wonder if sprint reported the "outage" to the FCC yet, or what answer you would get from calling the NCS or NCC watch. - Jared From tme at multicasttech.com Fri Oct 31 09:33:28 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 31 Oct 2008 10:33:28 -0400 Subject: Sprint / Cogent In-Reply-To: <704775AC-D7FD-4DF2-A823-DF154C8B1B57@puck.nether.net> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> <490B0D9B.4070709@cox.net> <704775AC-D7FD-4DF2-A823-DF154C8B1B57@puck.nether.net> Message-ID: <7BB9EF8A-D9A7-473A-B453-6755298041A5@multicasttech.com> On Oct 31, 2008, at 10:12 AM, Jared Mauch wrote: > > On Oct 31, 2008, at 9:52 AM, Larry Sheldon wrote: > >> Alex Rubenstein wrote: >> >>> Why do I say stupid? >>> Because, if companies like Sprint continue to do things like what >>> Sprint is doing, this will certainly lead to being noticed by >>> legislators, and the next thing we know we will have federally >>> regulated peering or backbone network operating. I can see it now, >>> the Bureau of Peering will be part of the Federal Networking >>> Committee. >> >> I think you are wrong to the extent that BOP will be under the >> Department Of Fairness. > > the two likely entities in the United States would be either the > FCC or DHS. > > (DHS you say?) The NCS lives under DHS. I wonder if sprint > reported the "outage" to the FCC yet, or what answer you would get > from calling the NCS or NCC watch. Maybe they can bring it up at the November 4th FCC open meeting : http://www.publish.com/c/a/Mobile/FCC-to-Consider-SprintClearwire-Merger/ http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-286069A1.pdf From the tentative agenda : A Memorandum Opinion and Order addressing the applications filed by Sprint Nextel and Clearwire for approval of the transfer ofcontrol of licenses, authorizations and leasing arrangements held by Sprint Nextel and its subsidiaries to New Clearwire. Regards Marshall > > > - Jared > From ops.lists at gmail.com Fri Oct 31 09:40:55 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 31 Oct 2008 20:10:55 +0530 Subject: Comcast contact In-Reply-To: <49083D40.1020507@karnaugh.za.net> References: <49083D40.1020507@karnaugh.za.net> Message-ID: On Wed, Oct 29, 2008 at 4:08 PM, Colin Alston wrote: > The URL Comcast gives with the spam block message is invalid. I doubt > I'll get action through their support channels either, and I can't even > find a useful looking one of those on their website... The URL you want is http://www.comcastsupport.com/rbl/ - and it looks quite valid from where I sit. --srs From braaen at zcorum.com Fri Oct 31 10:03:07 2008 From: braaen at zcorum.com (Brian Raaen) Date: Fri, 31 Oct 2008 11:03:07 -0400 Subject: Sprint / Cogent In-Reply-To: References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> Message-ID: <200810311103.08309.braaen@zcorum.com> I would have to agree with Alex that if behavior like this doesn't stop that the Fed would get involved(regardless of which party is in office). Is this type of behavior called 'peer pressure', maybe there are care groups to help these victims. Overall... it is one thing if Sprint and Cogent get into a shouting match, it would be a whole other ballpark if say AT&T, Qwest, Verizon or Time Warner de-peered. ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Friday 31 October 2008, Alex Rubenstein wrote: > > So why do SPs keep depeering Cogent? Serious question, why? I'm not > > aware of any Intercage-like issues with them. I've actually considered > > them as a potential upstream when we expand into a market they serve. > > Because some SP's still have a sour taste in their mouth about what Cogent did to the marketplace when they started. If you recall, they were the most disturbing force in the transit wars (not to be confused with the cola or fast-food wars), when they came out with $3,000 fast-Ethernets, and everyone else was enjoying $100+/meg. In my opinion, this was the free market at work, and look -- the market as continued to thrive with plenty of competition. > > Not being a customer of either of these guys, I could care less about this. While Sprint most certainly has their reasons, I think generally speaking people care less about this sort of thing these days. 1239 is certainly not the force that they used to be, and they should realize it and stop being stupid. > > Why do I say stupid? > > Because, if companies like Sprint continue to do things like what Sprint is doing, this will certainly lead to being noticed by legislators, and the next thing we know we will have federally regulated peering or backbone network operating. I can see it now, the Bureau of Peering will be part of the Federal Networking Committee. > > Does anyone want that? I certainly don't. Again, not because it would overly affect me, it's just more regulation which we don't need. > > I'll crawl back under my rock now. > > From nick at inex.ie Fri Oct 31 10:19:49 2008 From: nick at inex.ie (Nick Hilliard) Date: Fri, 31 Oct 2008 15:19:49 +0000 Subject: Sprint / Cogent In-Reply-To: <200810311323.m9VDNCcI081807@aurora.sol.net> References: <200810311323.m9VDNCcI081807@aurora.sol.net> Message-ID: <490B2215.6000601@inex.ie> On 31/10/2008 13:23, Joe Greco wrote: > It is certainly not "just" a bullying tactic. It may be "A" bullying > tactic, I won't even attempt to guess at the intent, but the tactic also > has the very real side effect of re-establishing full connectivity to > Sprint-connected sites that lose it. you-re right - it's a bullying tactic, not "just a". Apart from the sales and publicity stunt value, it will put a certain amount of pressure on Sprint to actually do something about the problem rather than sit back, ignore it and hope it goes away. Nick From morrowc.lists at gmail.com Fri Oct 31 10:21:51 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 31 Oct 2008 11:21:51 -0400 Subject: Sprint / Cogent In-Reply-To: References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> Message-ID: <75cb24520810310821hba95bfbveb110186712948f0@mail.gmail.com> On Fri, Oct 31, 2008 at 9:47 AM, Alex Rubenstein wrote: > Why do I say stupid? > > Because, if companies like Sprint continue to do things like what Sprint is doing, this will > certainly lead to being noticed by legislators, and the next thing we know we will have federally > regulated peering or backbone network operating. I can see it now, the Bureau of Peering will be > part of the Federal Networking Committee. > This is different than the 3yr hold on peering changes imposed on UUNET/MCI when they merged with Verizon (were borged by verizon) or the same hold imposed on ATT when the SBC/ATT merger went down? -chris From David_Hankins at isc.org Fri Oct 31 11:17:43 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 31 Oct 2008 09:17:43 -0700 Subject: Another driver for v6? In-Reply-To: <200810311345.05174.tore@linpro.no> References: <20081028224053.35f85438@cs.columbia.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <200810311345.05174.tore@linpro.no> Message-ID: <20081031161743.GE16800@isc.org> Google's statistics are using themselves as the subject, a fixed point in the network. It's hard to guarantee that subjective experience is going to be equal across the entirety of the network, but let us presume for the purpose of discussion that they are. I think the point in the final analysis for customer-facing FQDN's is; 1) How much in USD is 0.09% loss of sales/customer-experience/etc? 2) What amount in USD is acceptable to lose, in order to gain IPv6's advantages? Be sure to include recurring support costs, abuse, and engineering manhours for the design and deployment. Note that the second question is a subjective cost/value analysis, and the typical operator may not find much value in IPv6 (today). So again, in summary, I absolutely think every network needs to be getting IPv6 into their workshops. You have to be prepared for what's coming. I'm still recommending a variety of caution in that first deployment on production systems. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From David_Hankins at isc.org Fri Oct 31 11:32:48 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 31 Oct 2008 09:32:48 -0700 Subject: Another driver for v6? In-Reply-To: References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> Message-ID: <20081031163248.GF16800@isc.org> On Thu, Oct 30, 2008 at 03:55:01PM +0000, Andy Davidson wrote: > Do you think that industry should be working to some kind of well supported > / worldwide flag day when lots of popular resources add v6 records at the > same time ? This is a sound evolutionary tactic lemmings use. =) But I'll take you one step simpler; get the industry to choose a day where it will no longer be acceptable to treat IPv6 like an experimental project. Sometime last year would have been great. If you can do that, then the RRset changes would come naturally afterwards. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From mike at rockynet.com Fri Oct 31 11:41:01 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 31 Oct 2008 10:41:01 -0600 Subject: Another driver for v6? In-Reply-To: <20081031163248.GF16800@isc.org> References: <20081028224053.35f85438@cs.columbia.edu> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> <20081031163248.GF16800@isc.org> Message-ID: <490B351D.2030503@rockynet.com> David W. Hankins wrote: > On Thu, Oct 30, 2008 at 03:55:01PM +0000, Andy Davidson wrote: >> Do you think that industry should be working to some kind of well supported >> / worldwide flag day when lots of popular resources add v6 records at the >> same time ? > > This is a sound evolutionary tactic lemmings use. =) I know this is way OT, but I can't let it pass. The lemming suicide myth was created by a very questionable Walt Disney documentary: http://www.wildlifenews.alaska.gov/index.cfm?adfg=wildlife_news.view_article&issue_id=6&articles_id=56 From David_Hankins at isc.org Fri Oct 31 11:49:40 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 31 Oct 2008 09:49:40 -0700 Subject: Another driver for v6? In-Reply-To: <490B351D.2030503@rockynet.com> References: <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> <20081031163248.GF16800@isc.org> <490B351D.2030503@rockynet.com> Message-ID: <20081031164940.GH16800@isc.org> On Fri, Oct 31, 2008 at 10:41:01AM -0600, Mike Lewinski wrote: >> This is a sound evolutionary tactic lemmings use. =) > > I know this is way OT, but I can't let it pass. The lemming suicide myth > was created by a very questionable Walt Disney documentary: This is also way OT, but I was actually thinking more of Lemmings(TM), the video game, as I am not really very familiar with rodents. We've already got sixxs and hurricane electric set as tunnel lemmings, we can get through the IPv4 address shortfall by setting a variety of other ISP's to explode and build bridges... The only thing to iron out is: Who gets to be (golden) parachute lemmings? -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From vixie at isc.org Fri Oct 31 11:53:16 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 31 Oct 2008 16:53:16 +0000 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B4782E@nexus.nexicomgroup.net> (Paul Stewart's message of "Fri\, 31 Oct 2008 06\:14\:37 -0400") References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01B4782E@nexus.nexicomgroup.net> Message-ID: "Paul Stewart" writes: > ... > > My question was meant at a much higher level - a level where costs are > equal for peering/transit and all the "technical" and the "financial" > homework has been done already.... now I'm the stage of one last meeting > with top level management to explain "peering" and it's magic. These are > mainly non-technical people - so my question to NANOG was for viewpoints > on peering of which hopefully I could reinforce some of my own thoughts > with. Whether or not someone operating at scale isn't the discussion - > and it's funny how many people involved with companies (that are > "operating at scale") have emailed me offline since this discussion > started a few days ago with questions/thoughts and strategy. if the financials and technicals are similar enough to be factored out, then what you have to look at is possible variance between tactical and strategic cost/benefit ratios. basically this boils down to the cost of lock-in. if you're going to avoid lock-in then you have get your own address space and build out to at least one IXP and then, buy diverse transit. once you have done all that, the cost of also peering is in the noise, whereas the advantage of also peering is noticeable if not always easily measureable. if you're not going to avoid lock-in, then everything you'd need to spend to avoid it can be avoided, and you won't be peering unless it's for purely strategic reasons. -- Paul Vixie From pstewart at nexicomgroup.net Fri Oct 31 11:56:25 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 31 Oct 2008 12:56:25 -0400 Subject: Peering - Benefits? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> Message-ID: <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> Why does the controversy word keep coming up? You're the third person now to ask if I was trying to provide controversy and for the third time , NO I AM NOT. And again, I *do* understand the issues at hand - although some new viewpoints I hadn't considered before came up and thank you. My question should have read specifically - "what points do you make with senior management to move towards larger, more diverse peering options compared to today?" Thank you however - I do have all the info I require and we're moving ahead... Best regards, Paul -----Original Message----- From: Tomas L. Byrnes [mailto:tomb at byrneit.net] Sent: Thursday, October 30, 2008 10:34 PM To: vijay gill; Paul Stewart Cc: nanog at nanog.org Subject: RE: Peering - Benefits? As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy. So far, most of the discussion has focused on peering as a substitute for transit. The idea behind peering is not that the peer takes your traffic destined for other networks, but that you each deliver the traffic destined for each other directly, without the need to transit. This should save BOTH of you $ on transit, reduce routing complexity for the peered networks, make troubleshooting traffic issues between the networks easier, and improve user experience. Common examples of where peering makes a lot of sense are: Major hosting providers to major national end-user networks. CDNs to end-user networks. Local data centers and DR facilities to metropolitan Ethernet providers. Hosting facilities to networks that service certain specific user communities, such as local realty MLS systems to the local cable and DSL providers. If you're using peering for transit, you're kind of missing the point, and introducing a lot of potential network (route leakage or excessive route prepends) and business (at what point does a transit imbalance become unfair) problems. IMO, peer for direct delivery, use transit for all else. YMMV >-----Original Message----- >From: vijay gill [mailto:vgill at vijaygill.com] >Sent: Thursday, October 30, 2008 7:20 PM >To: Paul Stewart >Cc: nanog at nanog.org >Subject: Re: Peering - Benefits? > >This is probably going to be a somewhat unpopular opinion, mostly >because people cannot figure out their COGS. If you can get transit >for cheaper than your COGS, you are better off buying transit and not >peering. There are some small arguments to be made for latency and >'cheap/free' peering if you are already buying transit at an exchange >and your port/xconn fee is cheaper than your capital/opex for the >amount of traffic you peer off. > >To be completely realistic, at current transit pricing, you are almost >always better off just buying transit from two upstreams and calling >it done, especially if you are posting to nanog asking about peering. > >/vijay > > >On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart > wrote: >> Hi there... >> >> I'm in a meeting next week to discuss settlement-free peering etc..... >> always an interesting time. A push is on (by myself) to get into >other >> physical locations and participate on the peering exchanges. >> >> Besides costs, what other factors are benefits to peering? >> >> I can think of some but looking to develop a concrete list of >appealing >> reasons etc. such as: >> >> -control over routing between networks >> -security aspect (being able to filter/verify routes to some degree) >> -latency/performance >> >> >> Just looking for other positive ideas etc...;) >> >> Cheers! >> >> Paul >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >------ >> >> "The information transmitted is intended only for the person or entity >to which it is addressed and contains confidential and/or privileged >material. If you received this in error, please contact the sender >immediately and then destroy this transmission, including all >attachments, without copying, distributing or disclosing same. Thank >you." >> >> ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From sking at kingrst.com Fri Oct 31 11:58:14 2008 From: sking at kingrst.com (Steven King) Date: Fri, 31 Oct 2008 12:58:14 -0400 Subject: Peering - Benefits? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <2EF4C1AF-F8D2-4CE8-B9E2-5A0E45EE69E1@ianai.net> <21ef2c1c0810302205t2f7e2ec4t127966ed0ee0b4b3@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01B4782E@nexus.nexicomgroup.net> Message-ID: <490B3926.1070402@kingrst.com> My company will be peering with two other SPs in the area purely for business strategic purposes. It turns out that at least one of these SPs owns the fiber running to the first CO in our transit back to Chicago. So it helps to be buddies with these companies. Paul Vixie wrote: > "Paul Stewart" writes: > > >> ... >> >> My question was meant at a much higher level - a level where costs are >> equal for peering/transit and all the "technical" and the "financial" >> homework has been done already.... now I'm the stage of one last meeting >> with top level management to explain "peering" and it's magic. These are >> mainly non-technical people - so my question to NANOG was for viewpoints >> on peering of which hopefully I could reinforce some of my own thoughts >> with. Whether or not someone operating at scale isn't the discussion - >> and it's funny how many people involved with companies (that are >> "operating at scale") have emailed me offline since this discussion >> started a few days ago with questions/thoughts and strategy. >> > > if the financials and technicals are similar enough to be factored out, > then what you have to look at is possible variance between tactical and > strategic cost/benefit ratios. basically this boils down to the cost of > lock-in. if you're going to avoid lock-in then you have get your own > address space and build out to at least one IXP and then, buy diverse > transit. once you have done all that, the cost of also peering is in the > noise, whereas the advantage of also peering is noticeable if not always > easily measureable. if you're not going to avoid lock-in, then everything > you'd need to spend to avoid it can be avoided, and you won't be peering > unless it's for purely strategic reasons. > -- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From tme at multicasttech.com Fri Oct 31 12:00:24 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 31 Oct 2008 13:00:24 -0400 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> Message-ID: On Oct 31, 2008, at 12:56 PM, Paul Stewart wrote: > Why does the controversy word keep coming up? You're the third person > now to ask if I was trying to provide controversy and for the third > time > , NO I AM NOT. > > And again, I *do* understand the issues at hand - although some new > viewpoints I hadn't considered before came up and thank you. > > My question should have read specifically - "what points do you make > with senior management to move towards larger, more diverse peering > options compared to today?" > Refer them to the Cogent / Sprint thread also occurring on NANOG. (I know it is too late to enter but I thought this was too apropos to pass up.) Regards Marshall > Thank you however - I do have all the info I require and we're moving > ahead... > > Best regards, > > Paul > > > -----Original Message----- > From: Tomas L. Byrnes [mailto:tomb at byrneit.net] > Sent: Thursday, October 30, 2008 10:34 PM > To: vijay gill; Paul Stewart > Cc: nanog at nanog.org > Subject: RE: Peering - Benefits? > > As with all things, this isn't so cut and dried as everyone makes it > seem. The OP was asking for an easy answer to a complex question, > which > usually shows a lack of understanding of the issues, or is an > attempt to > provoke controversy. > > So far, most of the discussion has focused on peering as a substitute > for transit. > > The idea behind peering is not that the peer takes your traffic > destined > for other networks, but that you each deliver the traffic destined for > each other directly, without the need to transit. > > This should save BOTH of you $ on transit, reduce routing complexity > for > the peered networks, make troubleshooting traffic issues between the > networks easier, and improve user experience. > > Common examples of where peering makes a lot of sense are: > > Major hosting providers to major national end-user networks. > > CDNs to end-user networks. > > Local data centers and DR facilities to metropolitan Ethernet > providers. > > Hosting facilities to networks that service certain specific user > communities, such as local realty MLS systems to the local cable and > DSL > providers. > > If you're using peering for transit, you're kind of missing the point, > and introducing a lot of potential network (route leakage or excessive > route prepends) and business (at what point does a transit imbalance > become unfair) problems. > > IMO, peer for direct delivery, use transit for all else. > > YMMV > > > >> -----Original Message----- >> From: vijay gill [mailto:vgill at vijaygill.com] >> Sent: Thursday, October 30, 2008 7:20 PM >> To: Paul Stewart >> Cc: nanog at nanog.org >> Subject: Re: Peering - Benefits? >> >> This is probably going to be a somewhat unpopular opinion, mostly >> because people cannot figure out their COGS. If you can get transit >> for cheaper than your COGS, you are better off buying transit and not >> peering. There are some small arguments to be made for latency and >> 'cheap/free' peering if you are already buying transit at an exchange >> and your port/xconn fee is cheaper than your capital/opex for the >> amount of traffic you peer off. >> >> To be completely realistic, at current transit pricing, you are >> almost >> always better off just buying transit from two upstreams and calling >> it done, especially if you are posting to nanog asking about peering. >> >> /vijay >> >> >> On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart >> wrote: >>> Hi there... >>> >>> I'm in a meeting next week to discuss settlement-free peering > etc..... >>> always an interesting time. A push is on (by myself) to get into >> other >>> physical locations and participate on the peering exchanges. >>> >>> Besides costs, what other factors are benefits to peering? >>> >>> I can think of some but looking to develop a concrete list of >> appealing >>> reasons etc. such as: >>> >>> -control over routing between networks >>> -security aspect (being able to filter/verify routes to some degree) >>> -latency/performance >>> >>> >>> Just looking for other positive ideas etc...;) >>> >>> Cheers! >>> >>> Paul >>> >>> >>> >>> >>> >>> >>> >>> > ---------------------------------------------------------------------- >> ------ >>> >>> "The information transmitted is intended only for the person or > entity >> to which it is addressed and contains confidential and/or privileged >> material. If you received this in error, please contact the sender >> immediately and then destroy this transmission, including all >> attachments, without copying, distributing or disclosing same. Thank >> you." >>> >>> > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or > entity to which it is addressed and contains confidential and/or > privileged material. If you received this in error, please contact > the sender immediately and then destroy this transmission, including > all attachments, without copying, distributing or disclosing same. > Thank you." > From jmalcolm at uraeus.com Fri Oct 31 12:02:23 2008 From: jmalcolm at uraeus.com (Joe Malcolm) Date: Fri, 31 Oct 2008 17:02:23 +0000 Subject: Peering - Benefits? In-Reply-To: <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net> <21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> Message-ID: <18699.14879.344685.962711@shoggoth.uraeus.com> vijay gill writes: >This is probably going to be a somewhat unpopular opinion, mostly >because people cannot figure out their COGS. If you can get transit >for cheaper than your COGS, you are better off buying transit and not >peering. There are some small arguments to be made for latency and >'cheap/free' peering if you are already buying transit at an exchange >and your port/xconn fee is cheaper than your capital/opex for the >amount of traffic you peer off. The other factor worth considering is the level of control your business plan supports giving up to third parties. This is more of a problem for things like real-time voice or video, but the circumstance can exist that depending on two even very good carriers may be uncomfortable - particular the first time one of them has a systemic issue. >To be completely realistic, at current transit pricing, you are almost >always better off just buying transit from two upstreams and calling >it done, especially if you are posting to nanog asking about peering. Yep. Joe From jeroen at unfix.org Fri Oct 31 12:09:40 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 31 Oct 2008 18:09:40 +0100 Subject: Another driver for v6? In-Reply-To: <20081031164940.GH16800@isc.org> References: <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> <20081031163248.GF16800@isc.org> <490B351D.2030503@rockynet.com> <20081031164940.GH16800@isc.org> Message-ID: <490B3BD4.6060900@spaghetti.zurich.ibm.com> David W. Hankins wrote: > On Fri, Oct 31, 2008 at 10:41:01AM -0600, Mike Lewinski wrote: >>> This is a sound evolutionary tactic lemmings use. =) >> I know this is way OT, but I can't let it pass. The lemming suicide myth >> was created by a very questionable Walt Disney documentary: > > This is also way OT, but I was actually thinking more of Lemmings(TM), > the video game, as I am not really very familiar with rodents. > > We've already got sixxs and hurricane electric set as tunnel lemmings, > we can get through the IPv4 address shortfall by setting a variety of > other ISP's to explode and build bridges... For the end-users who use those services, I am pretty sure it is more the user playing the game (aka the services providing guidance), than being the lemmings who just keep on running and commit suicide (aka the networks who are not moving, getting experience and doing something). Greets, Jeroen (Who still ranks Lemmings(tm) as one of the top games ever, simple and way too much fun, Amiga Lemmings X-mas special anyone? :) ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From repstein at chello.at Fri Oct 31 12:20:23 2008 From: repstein at chello.at (Randy Epstein) Date: Fri, 31 Oct 2008 13:20:23 -0400 Subject: Sprint / Cogent In-Reply-To: <490B2215.6000601@inex.ie> References: <200810311323.m9VDNCcI081807@aurora.sol.net> <490B2215.6000601@inex.ie> Message-ID: If you haven't already seen it, the great Todd Underwood of Renesys published an article today on his blog regarding this subject: http://www.renesys.com/blog/2008/10/wrestling-with-the-zombie-spri.shtml An aside, WV Fiber (AS19151) is currently partitioned from Cogent since AS19151 only contracts with Sprint for transit and is settlement-free with the rest of its peers. As previously reported, late last year, Cogent depeered AS19151 for unknown reasons. Up until yesterday, this wasn't much of a problem. Now unfortunately, the two networks (AS19151 and AS174) are partitioned. Any single homed WV Fiber customer and any single homed Cogent customer can not reach each other. WV Fiber hosts over 7 million eyeballs and many networks under its AS. We hope Sprint and Cogent work out their differences, but in the mean time, we unfortunately will remain partitioned from Cogent. Regards, Randy Epstein President WV Fiber From msa at latt.net Fri Oct 31 12:44:55 2008 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 31 Oct 2008 17:44:55 +0000 Subject: Sprint / Cogent In-Reply-To: References: <200810311323.m9VDNCcI081807@aurora.sol.net> <490B2215.6000601@inex.ie> Message-ID: <20081031174455.GA19625@mx1.latt.net> On Fri, Oct 31, 2008 at 01:20:23PM -0400, Randy Epstein wrote: > We hope Sprint and Cogent work out their differences, but in the mean time, > we unfortunately will remain partitioned from Cogent. Randy, This brings up something I've always wondered. Why do we have public depeerings, rather than public deprefings? You'd think both sides could at least agree to set localpref to 1, and not send each other anything that they don't absolutely have to until they resolve their issues. Bypass them if at all possible, but don't partition the interwebs. Or am I dreaming of ponies again? --msa From patrick at ianai.net Fri Oct 31 13:03:38 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 31 Oct 2008 14:03:38 -0400 Subject: Sprint / Cogent In-Reply-To: <20081031174455.GA19625@mx1.latt.net> References: <200810311323.m9VDNCcI081807@aurora.sol.net> <490B2215.6000601@inex.ie> <20081031174455.GA19625@mx1.latt.net> Message-ID: <9D92384F-0816-4894-9CFB-F1B48B7E88BA@ianai.net> On Oct 31, 2008, at 1:44 PM, Majdi S. Abbas wrote: > On Fri, Oct 31, 2008 at 01:20:23PM -0400, Randy Epstein wrote: >> We hope Sprint and Cogent work out their differences, but in the >> mean time, >> we unfortunately will remain partitioned from Cogent. > > Randy, > > This brings up something I've always wondered. Why do we have > public depeerings, rather than public deprefings? You'd think both > sides could at least agree to set localpref to 1, and not send each > other anything that they don't absolutely have to until they resolve > their issues. Bypass them if at all possible, but don't partition > the interwebs. > > Or am I dreaming of ponies again? Dreaming. If Sprint is upset that Cogent is sending Sprint much more traffic than Sprint is sending Cogent, how does Sprint sending Cogent even less traffic (and making the ratio even worse) help Sprint? Why would Cogent care? -- TTFN, patrick From patrick at ianai.net Fri Oct 31 13:05:09 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 31 Oct 2008 14:05:09 -0400 Subject: Sprint / Cogent In-Reply-To: <7BB9EF8A-D9A7-473A-B453-6755298041A5@multicasttech.com> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> <490B0D9B.4070709@cox.net> <704775AC-D7FD-4DF2-A823-DF154C8B1B57@puck.nether.net> <7BB9EF8A-D9A7-473A-B453-6755298041A5@multicasttech.com> Message-ID: <72C3A668-1F96-47B9-8280-53B96E913EDB@ianai.net> On Oct 31, 2008, at 10:33 AM, Marshall Eubanks wrote: > Maybe they can bring it up at the November 4th FCC open meeting : [snip] While I agree regulation is a possible outcome, I am always amazed at the US gov't self-delusion that they can somehow regulate something like the Internet. End of day, regulation will just make things more difficult, it will not actually change the way networks make decisions. But we all knew that. -- TTFN, patrick From cscora at apnic.net Fri Oct 31 13:10:43 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Nov 2008 04:10:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200810311810.m9VIAhXg019392@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 01 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 272468 Prefixes after maximum aggregation: 131440 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 132812 Total ASes present in the Internet Routing Table: 29655 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25822 Origin ASes announcing only one prefix: 12567 Transit ASes present in the Internet Routing Table: 3833 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 551 Unregistered ASNs in the Routing Table: 198 Number of 32-bit ASNs allocated by the RIRs: 61 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 198 Number of addresses announced to Internet: 1919227072 Equivalent to 114 /8s, 101 /16s and 20 /24s Percentage of available address space announced: 51.8 Percentage of allocated address space announced: 62.5 Percentage of available address space allocated: 82.8 Percentage of address space in use by end-sites: 74.0 Total number of prefixes smaller than registry allocations: 134099 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62538 Total APNIC prefixes after maximum aggregation: 23309 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59466 Unique aggregates announced from the APNIC address blocks: 26845 APNIC Region origin ASes present in the Internet Routing Table: 3429 APNIC Prefixes per ASN: 17.34 APNIC Region origin ASes announcing only one prefix: 920 APNIC Region transit ASes present in the Internet Routing Table: 532 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 380054176 Equivalent to 22 /8s, 167 /16s and 42 /24s Percentage of available APNIC address space announced: 80.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/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, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123152 Total ARIN prefixes after maximum aggregation: 64896 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92700 Unique aggregates announced from the ARIN address blocks: 35162 ARIN Region origin ASes present in the Internet Routing Table: 12558 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4858 ARIN Region transit ASes present in the Internet Routing Table: 1191 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 368557728 Equivalent to 21 /8s, 247 /16s and 190 /24s Percentage of available ARIN address space announced: 75.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/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, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 59984 Total RIPE prefixes after maximum aggregation: 35947 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 55619 Unique aggregates announced from the RIPE address blocks: 37167 RIPE Region origin ASes present in the Internet Routing Table: 12115 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6369 RIPE Region transit ASes present in the Internet Routing Table: 1838 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 377144224 Equivalent to 22 /8s, 122 /16s and 195 /24s Percentage of available RIPE address space announced: 86.5 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-49151 RIPE Address Blocks 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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22123 Total LACNIC prefixes after maximum aggregation: 5537 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 20171 Unique aggregates announced from the LACNIC address blocks: 11290 LACNIC Region origin ASes present in the Internet Routing Table: 1025 LACNIC Prefixes per ASN: 19.68 LACNIC Region origin ASes announcing only one prefix: 340 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 57602048 Equivalent to 3 /8s, 110 /16s and 240 /24s Percentage of available LACNIC address space announced: 57.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4130 Total AfriNIC prefixes after maximum aggregation: 1325 AfriNIC Deaggregation factor: 3.12 Prefixes being announced from the AfriNIC address blocks: 4420 Unique aggregates announced from the AfriNIC address blocks: 2125 AfriNIC Region origin ASes present in the Internet Routing Table: 264 AfriNIC Prefixes per ASN: 16.74 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC addresses announced to Internet: 12880640 Equivalent to 0 /8s, 196 /16s and 139 /24s Percentage of available AfriNIC address space announced: 25.6 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1494 522 200 TATA Communications formerly 17488 1403 97 102 Hathway IP Over Cable Interne 9583 1110 87 475 Sify Limited 4766 883 6408 363 Korea Telecom (KIX) 4134 869 13760 355 CHINANET-BACKBONE 23577 816 35 701 Korea Telecom (ATM-MPLS) 18101 782 161 67 Reliance Infocom Ltd Internet 4780 724 357 63 Digital United Inc. 9498 692 295 54 BHARTI BT INTERNET LTD. 4808 627 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4356 3416 339 bellsouth.net, inc. 209 3051 4035 622 Qwest 6298 2047 323 683 Cox Communicatons 1785 1692 717 154 PaeTec Communications, Inc. 20115 1655 1441 723 Charter Communications 2386 1588 699 896 AT&T Data Communications Serv 4323 1567 1084 376 Time Warner Telecom 7018 1415 5872 981 AT&T WorldNet Services 6478 1370 289 209 AT&T Worldnet Services 11492 1211 152 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 432 1777 384 TDC Tele Danmark 30890 348 94 188 SC Kappa Invexim SRL 8866 330 111 23 Bulgarian Telecommunication C 3301 329 1428 300 TeliaNet Sweden 3215 328 2756 106 France Telecom Transpac 3320 326 7063 275 Deutsche Telekom AG 8452 322 188 11 TEDATA 5462 300 794 27 Telewest Broadband 25233 296 45 28 Awalnet 8551 287 270 37 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2833 220 UniNet S.A. de C.V. 11830 670 299 9 Instituto Costarricense de El 22047 566 270 14 VTR PUNTO NET S.A. 10620 545 126 59 TVCABLE BOGOTA 7303 494 243 70 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 419 85 48 ENTEL CHILE S.A. 11172 407 118 72 Servicios Alestra S.A de C.V 28573 338 464 23 NET Servicos de Comunicao S.A 14117 330 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 545 72 43 LINKdotNET AS number 3741 269 856 225 The Internet Solution 20858 259 34 3 EgyNet 2018 236 215 139 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 138 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 114 555 63 Telkom SA Ltd 29571 113 13 9 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4356 3416 339 bellsouth.net, inc. 209 3051 4035 622 Qwest 6298 2047 323 683 Cox Communicatons 1785 1692 717 154 PaeTec Communications, Inc. 20115 1655 1441 723 Charter Communications 2386 1588 699 896 AT&T Data Communications Serv 4323 1567 1084 376 Time Warner Telecom 4755 1494 522 200 TATA Communications formerly 7018 1415 5872 981 AT&T WorldNet Services 17488 1403 97 102 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3051 2429 Qwest 1785 1692 1538 PaeTec Communications, Inc. 6298 2047 1364 Cox Communicatons 17488 1403 1301 Hathway IP Over Cable Interne 4755 1494 1294 TATA Communications formerly 11492 1211 1200 Cable One 4323 1567 1191 Time Warner Telecom 8151 1400 1180 UniNet S.A. de C.V. 6478 1370 1161 AT&T Worldnet Services 18566 1059 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. Complete listing at http://thyme.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:18 /9:9 /10:18 /11:46 /12:149 /13:298 /14:538 /15:1066 /16:10138 /17:4406 /18:7655 /19:16460 /20:19364 /21:18859 /22:23884 /23:24861 /24:141928 /25:819 /26:1007 /27:839 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2852 4356 bellsouth.net, inc. 6298 2021 2047 Cox Communicatons 209 1767 3051 Qwest 2386 1270 1588 AT&T Data Communications Serv 17488 1194 1403 Hathway IP Over Cable Interne 11492 1187 1211 Cable One 1785 1155 1692 PaeTec Communications, Inc. 6478 1105 1370 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 977 1110 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:140 12:2176 13:2 15:21 16:3 17:5 20:35 24:1082 32:50 38:515 40:92 41:748 43:1 44:2 47:13 52:3 55:3 56:3 57:26 58:511 59:530 60:452 61:1024 62:1139 63:2019 64:3267 65:2429 66:3497 67:1288 68:802 69:2337 70:875 71:138 72:2054 73:7 74:1273 75:168 76:284 77:940 78:631 79:282 80:937 81:870 82:609 83:395 84:583 85:1069 86:507 87:719 88:346 89:1365 90:22 91:1647 92:291 93:947 94:268 95:4 96:80 97:121 98:370 99:14 113:38 114:113 115:137 116:1000 117:385 118:239 119:503 120:98 121:613 122:854 123:461 124:853 125:1222 128:354 129:207 130:135 131:421 132:72 133:9 134:187 135:31 136:218 137:99 138:146 139:82 140:412 141:105 142:390 143:298 144:325 145:51 146:374 147:141 148:531 149:212 150:128 151:208 152:145 153:135 154:10 155:280 156:174 157:302 158:169 159:302 160:273 161:139 162:255 163:135 164:519 165:503 166:363 167:339 168:631 169:155 170:450 171:40 172:10 173:66 187:18 188:1 189:298 190:2332 192:5761 193:4150 194:3282 195:2645 196:1018 198:3706 199:3280 200:5551 201:1469 202:7778 203:8038 204:3928 205:2170 206:2294 207:2769 208:3734 209:3441 210:2579 211:1089 212:1532 213:1635 214:67 215:25 216:4422 217:1261 218:348 219:440 220:1060 221:416 222:301 End of report From jlloret at dcom.upv.es Fri Oct 31 13:30:11 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Fri, 31 Oct 2008 19:30:11 +0100 Subject: Deadline extension: ICNS 2009 + 1st Workshop LMPCNAP | April 21-25, 2009 - Valencia, Spain Message-ID: <200810311830.m9VIUAoX013586@smtp.upv.es> Note that the deadline for ICNS 2009 + 1st Workshop LMPCNAP has been extended to November 10. We would like to make ICNS 2009 a primary reference event. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Please note that extended versions of highly ranked papers will be invited for journals submission. Full contributions are expected by the submission deadline. =========== ICNS 2009 + 1st Workshop LMPCNAP | Call for Papers =========== CALL FOR PAPERS, TUTORIALS, PANELS - ICNS 2009, The Fifth International Conference on Networking and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/ICNS09.html Call for Papers: http://www.iaria.org/conferences2009/CfPICNS09.html - The first International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy Program (CNAP), LMPCNAP 2009 will be held during ICNS 2009 in April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/LMPCNAP.html Important deadlines: Submission (full paper) November 10, 2008 Authors notification December 5, 2008 Registration December 20, 2008 Camera ready December 25, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum special submission with on progress and challenging ideas. ICNS 2009 Area Tracks are the following (details in the CfP on site): ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications IPv6DFI: Deploying the Future Infrastructure IPDy: Internet Packet Dynamics GOBS: GRID over Optical Burst Switching Networks ================================= - ICNS General Chair Jaime Lloret Mauri, Polytechnic University of Valencia, Spain - ICNS 2009 Industry Chairs Kevin Y Ung, Boeing, USA Leo Lehmann, OFCOM, Switzerland Francisco Javier S?nchez, Administrador de Infraestructuras Ferroviarias (ADIF), Spain - ICNS 2009 Technical Program Committee Chair Giancarlo Fortino, Universit? della Calabria, Italy Salvador Sales, Polytechnic University of Valencia, Spain Feng Xia, Queensland University of Technology, Australia / Zhejiang University, China - ICNS Advisory Chairs Wojciech Burakowski, Warsaw University of Technology, Poland Vicente Casares, Polytechnic University of Valencia, Spain Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Xiaohua Jia, City University of Hong Kong - Kowloon, Hong Kong Manuel Sierra-P?rez, Universidad Polit?cnica de Madrid, Spain - LMPCNAP 2009 General Chair Rafael Tomas, Mediterranean Cisco Academy Training Center (CATC), Spain - LMPCNAP 2009 Technical Program Commitee chair Prof. Tomeu Serra, Universitat de les Illes Balears, Spain ================================ From kurtis at kurtis.pp.se Fri Oct 31 14:06:59 2008 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 31 Oct 2008 20:06:59 +0100 Subject: Sprint / Cogent In-Reply-To: <72C3A668-1F96-47B9-8280-53B96E913EDB@ianai.net> References: <490AF05B.7000502@inex.ie> <490B020F.7040101@justinshore.com> <490B0D9B.4070709@cox.net> <704775AC-D7FD-4DF2-A823-DF154C8B1B57@puck.nether.net> <7BB9EF8A-D9A7-473A-B453-6755298041A5@multicasttech.com> <72C3A668-1F96-47B9-8280-53B96E913EDB@ianai.net> Message-ID: <26109490-1F8C-4BB7-9C61-DE5545455ACD@kurtis.pp.se> Sent from my iPhone On 31 okt 2008, at 19.05, "Patrick W. Gilmore" wrote: > On Oct 31, 2008, at 10:33 AM, Marshall Eubanks wrote: > >> Maybe they can bring it up at the November 4th FCC open meeting : > > [snip] > > While I agree regulation is a possible outcome, I am always amazed > at the US gov't self-delusion that they can somehow regulate > something like the Internet. > > End of day, regulation will just make things more difficult, it will > not actually change the way networks make decisions. > > But we all knew that. If the eu attempt at regulating last mile copper acces prices is to serve as example I doubt regulation of interconnects will be for the better... - kurtis - From sven at cyberbunker.com Fri Oct 31 14:27:21 2008 From: sven at cyberbunker.com (HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP) Date: Fri, 31 Oct 2008 19:27:21 +0000 (GMT) Subject: Another driver for v6? In-Reply-To: <490B3BD4.6060900@spaghetti.zurich.ibm.com> References: <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> <20081031163248.GF16800@isc.org> <490B351D.2030503@rockynet.com> <20081031164940.GH16800@isc.org> <490B3BD4.6060900@spaghetti.zurich.ibm.com> Message-ID: ever heard of the concept "open market" ipv4 address space delegations will just move from the rirs to places like ebay, problem solved. most of it is unused anyway (milnet, amateur radio ranges, etc) -- HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. Minister of Telecommunications, Republic CyberBunker. Phone: +49/163-4405069 Phone: +49/30-36731425 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 31 Oct 2008, Jeroen Massar wrote: > David W. Hankins wrote: > > On Fri, Oct 31, 2008 at 10:41:01AM -0600, Mike Lewinski wrote: > >>> This is a sound evolutionary tactic lemmings use. =) > >> I know this is way OT, but I can't let it pass. The lemming suicide myth > >> was created by a very questionable Walt Disney documentary: > > > > This is also way OT, but I was actually thinking more of Lemmings(TM), > > the video game, as I am not really very familiar with rodents. > > > > We've already got sixxs and hurricane electric set as tunnel lemmings, > > we can get through the IPv4 address shortfall by setting a variety of > > other ISP's to explode and build bridges... > > For the end-users who use those services, I am pretty sure it is more > the user playing the game (aka the services providing guidance), than > being the lemmings who just keep on running and commit suicide (aka the > networks who are not moving, getting experience and doing something). > > Greets, > Jeroen > (Who still ranks Lemmings(tm) as one of the top games ever, > simple and way too much fun, Amiga Lemmings X-mas special anyone? :) ) > > From brandon at rd.bbc.co.uk Fri Oct 31 15:05:30 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 31 Oct 2008 20:05:30 GMT Subject: Sprint / Cogent Message-ID: <200810312005.UAA17081@sunf10.rd.bbc.co.uk> > So why do SPs keep depeering Cogent? Karma. brandon From hamster at twistedfaith.co.uk Fri Oct 31 17:08:06 2008 From: hamster at twistedfaith.co.uk (hamster at twistedfaith.co.uk) Date: Fri, 31 Oct 2008 22:08:06 -0000 Subject: BBC Contact Message-ID: <490B81C6.24031.7C19023@hamster.twistedfaith.co.uk> Hello, If there is anyone from the BBC ip/peering dept here, please could they contact me offlist concerning a problem we have? Thanks, Chris From simon at slimey.org Fri Oct 31 17:09:44 2008 From: simon at slimey.org (Simon Lockhart) Date: Fri, 31 Oct 2008 22:09:44 +0000 Subject: BBC Contact In-Reply-To: <490B81C6.24031.7C19023@hamster.twistedfaith.co.uk> References: <490B81C6.24031.7C19023@hamster.twistedfaith.co.uk> Message-ID: <20081031220944.GX18579@virtual.bogons.net> On Fri Oct 31, 2008 at 10:08:06PM -0000, hamster at twistedfaith.co.uk wrote: > If there is anyone from the BBC ip/peering dept here, please could they > contact me offlist concerning a problem we have? noc at bbc.co.uk should reach the right people. Let me know if you get no response from that address and I can prod people. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From nelson.lai at indiatimes.com Fri Oct 31 00:32:25 2008 From: nelson.lai at indiatimes.com (Nelson Lai) Date: Fri, 31 Oct 2008 11:02:25 +0530 (IST) Subject: Why do some companies get depeered and some don't? Message-ID: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com> Why do some companies like Cogent get depeered relatively often and companies like Teleglobe don't even get talked about and operate in silence free from depeering? -- Hyundai to launch the i20 in India. Catch the exclusive preview on ZigWheels.com http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW