五工变频器，中国唯一与世界竞争的产品简介
节约你的设备成本，提高你的设备质量――请选用中国五工变频器！ ■五工变频器――中国唯一与世界竞争的产品！ ――德国技术合作！ ――国际认可的中国品牌！ ――节约成本，提高质量，取代进口变频，一年为你节约几十万至几百万，甚至几千万资金！ ――2010年取代进口变频快速上升！ （因是产品简介，内容简短，以免占用你的邮箱空间） ■五工变频器优势简介 详细产品请查看 ――五工变频网站：http://wugon.letgo.com.cn（无病毒，请放心查看） 注意：咨询、合作、代理请按以下正确的联系方式： 联系方式： 单位：五工能源系统制造(惠州)有限公司 (变频器产品商务部） 地址：中国电子生产基地――广东省惠州市三新工业区 电 话：0752-2350566 传真：0752-2352166 手 机：15917753055（沈先生） 商务QQ：906270997 E-mail：wugong...@163.com 网站：http://wugon.letgo.com.cn （友情告知：因你的邮址在各网站是公开的，如有打扰或重复，敬请谅解）
五工变频器，中国唯一与世界竞争的产品简介
节约你的设备成本，提高你的设备质量――请选用中国五工变频器！ ■五工变频器――中国唯一与世界竞争的产品！ ――德国技术合作！ ――国际认可的中国品牌！ ――节约成本，提高质量，取代进口变频，一年为你节约几十万至几百万，甚至几千万资金！ ――2010年取代进口变频快速上升！ （因是产品简介，内容简短，以免占用你的邮箱空间） ■五工变频器优势简介 详细产品请查看 ――五工变频网站：http://wugon.letgo.com.cn（无病毒，请放心查看） 注意：咨询、合作、代理请按以下正确的联系方式： 联系方式： 单位：五工能源系统制造(惠州)有限公司 (变频器产品商务部） 地址：中国电子生产基地――广东省惠州市三新工业区 电 话：0752-2350566 传真：0752-2352166 手 机：15917753055（沈先生） 商务QQ：906270997 E-mail：wugong...@163.com 网站：http://wugon.letgo.com.cn （友情告知：因你的邮址在各网站是公开的，如有打扰或重复，敬请谅解）
Re: NANOG List Update - Moving Forward
On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: If you have any questions or concerns please let me know. The new posts do not have list (un)subscribe information in the headers. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: NANOG List Update - Moving Forward
Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Regards, Tim.
Re: NANOG List Update - Moving Forward
On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Ditto. Getting lots of crap here. William
Re: NANOG List Update - Moving Forward
If you have any questions or concerns please let me know. we haz spam! randy
Re: NANOG List Update - Moving Forward
+1 On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock neno...@systeminplace.net wrote: On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Ditto. Getting lots of crap here. William
RE: NANOG List Update - Moving Forward
And adding to it as well +7 Kind Regards Chris Barlow BSc. MBCS Information Technology Manager TICS (Global) Ltd, Oxford House Sixth Avenue, Robin Hood Airport Doncaster DN9 3GG Tel +44 (0)1302 623074 Fax +44 (0)1302 623075 Mob +44(0)7909 520445 This message is for the intended recipient only. It may contain confidential or proprietary information. If you receive this message in error, please immediately delete it, destroy all copies of it and notify the sender. You must not use or disclose any part of this message if you are not the intended recipient. If you contact us by email, we may store your name and address to facilitate communication. We take reasonable precautions to ensure our emails are virus free, however we cannot accept responsibility for any virus transmitted by us and recommend that you subject any incoming email to your own virus checking procedures. Head Office: TICS Ltd, Oxford House, Sixth Avenue, Robin Hood Airport, Doncaster DN9 3GG Registered in England and Wales under registration number 7164795 For further information about TICS Ltd, please visit http://www.tics-ltd.co.uk -Original Message- From: jim deleskie [mailto:deles...@gmail.com] Sent: 12 July 2011 13:03 To: neno...@systeminplace.net Cc: t...@pelican.org; NANOG list Subject: Re: NANOG List Update - Moving Forward +1 On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock neno...@systeminplace.net wrote: On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Ditto. Getting lots of crap here. William
Re: NANOG List Update - Moving Forward
On Tue, Jul 12, 2011 at 4:50 AM, Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Regards, Tim. Same here. Previously I have maybe received maybe one or two spam messages total via NANOG, but this morning I have received seven.
NANOG Move - Moved back
Hello All: We're back on the old configuration for now. I will send an update later this afternoon once I speak with AMS about the issues we experienced over night. Regards, Mike
dammit, please make nanog poster only .. dont let nonmembers post to it
That's the second spam received on nanog so far. First a chinese voip vendor who probably wont gain any customers, the second a nigerian westernunion scam -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: NANOG List Update - Moving Forward
On Tue, 12 Jul 2011, Mikael Abrahamsson wrote: On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: If you have any questions or concerns please let me know. The new posts do not have list (un)subscribe information in the headers. This took a very long time to get delivered (2h20 minutes). Also, the new mail server doesn't seem to support TLS and during this short time it's been active, we've had multiple SPAM get distributed through the list as well. What was the reason for the change, from what it looks like right now there seems to be quite a few downsides and functionality/performance lost. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: NANOG List Update - Moving Forward
Just want to re-confirm. I've got only 4 in my spam. Is it google spam who is not putting it in SPAM folder? Regards, Aftab A. Siddiqui On Tue, Jul 12, 2011 at 4:32 PM, William Pitcock neno...@systeminplace.netwrote: On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Ditto. Getting lots of crap here. William
Re: NANOG List Update - Moving Forward?
Hi Also seeing a gross amount of spam from list and my digest setting has been lost apparently. Sigh C
Re: NANOG List Update - Moving Forward
On Tue, 12 Jul 2011, Mikael Abrahamsson wrote: On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: If you have any questions or concerns please let me know. The new posts do not have list (un)subscribe information in the headers. Also, the headers now no longer include the origin of messages. i.e. the new mailing list manager is throwing away all Received: lines such that if I look at the message headers, all I know is the mail came to me through amsl.com. So with the spam getting through now, there's no way for list members to see where it actually came from. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: NANOG List Update - Moving Forward
On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: If you have any questions or concerns please let me know. The new posts do not have list (un)subscribe information in the headers. I'll offer an evenhanded comment in that it's frustrating that the headers used have changed, since some of us key procmail off of them to split mailing lists into folders, but it *is* nice to see that the current NANOG mailing list team has been supporting List-Id for some time now, and that such was propagated properly between old and new host. Good job. Unfortunately my filter predates NANOG's use of that so now I gotta go fix it here. ... 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.
Re: NANOG List Update - Moving Forward
We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. Thanks, Steve On Jul 12, 2011, at 5:03 AM, jim deleskie wrote: +1 On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock neno...@systeminplace.net wrote: On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Ditto. Getting lots of crap here. William
Can somebody stop nanog@nanog.org from forwarding spam, kthx!
I am fairly sure that the fake Western Union message and various other spams that are dripping through are from real subscribers... Also, as somebody decided to drop mailman and replace it by 'bulk_mailer v1.13' maybe one should start fixing that software also to add the List-* headers aka RF2369 headers before we get a flood of 'I want to unsubscribe!' kind of messages, as currently there are no details in the message... Greets, Jeroen -- Return-Path: h...@nanog.org [..] Received: by c1a.amsl.com (Postfix, from userid 65534) id 8827E1C39C0D; Tue, 12 Jul 2011 01:56:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with SMTP id 859251C39C0C; Tue, 12 Jul 2011 01:56:17 -0700 (PDT) Received: by nanog.org (bulk_mailer v1.13); Tue, 12 Jul 2011 01:56:13 -0700 X-Virus-Scanned: amavisd-new at amsl.com Authentication-Results: c1a.amsl.com (amavisd-new); dkim=pass header.i=@yahoo.com by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57kfPoQcM1II for c5-22-1...@c1a.amsl.com; Tue, 12 Jul 2011 01:55:54 -0700 (PDT) by c1a.amsl.com (Postfix) with ESMTPS id D6F391C39502 for nanog@nanog.org; Tue, 12 Jul 2011 01:55:53 -0700 (PDT) by s0.nanog.org with smtp (Exim 4.72 (FreeBSD)) (envelope-from wu001...@hotmail.com) id 1QgYTR-000O9p-FX for nanog@nanog.org; Tue, 12 Jul 2011 08:37:46 + X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 599896.49560...@omp1019.access.mail.sp2.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310459863; bh=kV1F/5fAMRswMRBHHPz7BAoiVx+V1whaOXmIw6DNpoQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=HaBDhJm8t+WHLeZ9JYMQWuC9hraN+xVQEYPlAaLG5M1vCXflWFCFCt+AWleOQRuc1063jgI5P0CYfpY4XAloY0FTwceXSntuo6fqmUgFQ2v9tCYxkWg0Z5/L5iy9utw73OrZ2FpYmcHB1fjNwLAeM/QiIUSKBQWyaoag5bUPZ6w= X-YMail-OSG: w33eh74VM1mZnVdAav_H6n4sKFUZGa.HTRs7c0RtQrPA6zT b9YAb0Nqk2hDHJXSi9J2XdgJeCrLtDQnz4_JjZLcBN9vSDIynSh.eD8rT_KB sYUe92vhC5f70p25BnhFd9ZsKvZVbSygr991WfCYWWyJKLzWr1d.FJlk2ogS Hz0Sz56HiSGhHBadGZbno1k3XkNSvWg5f5vnX8hgYzVbL4wHxz8mC3KtqQoj L3rC0WGp_k.5dnNQIOWcv56QpJ9qSiA02nP9Ac_DfUJ_VdheCcZjA13Ncr7J wrd73Iqvr1LMQmLuijPB16fgXHlMwaZZMo0xckq0tYzvb8AHHKWaa7YqyrsH VZoGenVnEe530zbxQqpDB7Jg5N4KoFs8K4xQBItr3sZdLHOKX6OndA2jLoeY sgs_p03CutbV_VggXh7KsOPVyWg-- X-RocketYMMF: web...@att.net X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 Message-ID: 1310459863.39197.yahoomai...@web180907.mail.ne1.yahoo.com Date: Tue, 12 Jul 2011 01:37:43 -0700 (PDT) From: Western Union Award wu001...@hotmail.com Subject: THANK YOU FOR USING WESTERN UNION!!!KINDLY OPEN THE ATTACHMENT, To: undisclosed recipients: ; MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=0-2023431952-1310459863=:39197 Reply-to: wu001...@hotmail.com X-C5I-RSN: 22/0/1041/6659/37972 X-C5I-Spamscore: -4.00 List-Id: North American Network Operators Group nanog.nanog.org Precedence: list --0-2023431952-1310459863=:39197 Content-Type: multipart/alternative; boundary=0-1056351656-1310459863=:39197 --0-1056351656-1310459863=:39197 Content-Type: text/plain; charset=us-ascii THANK YOU FOR USING WESTERN UNION!!!KINDLY OPEN THE ATTACHMENT,
Spam?
New location means we now get spam on Nanog? Could we go back to the old place?
Re: NANOG List Update - Moving Forward
On 2011-07-12 07:19, Michael K. Smith - Adhost wrote: If you have any questions or concerns please let me know. I miss proper List-Id headers for identifying and filtering the list easily. I might have missed some discussion; but why are we moving away from mailman, and what software is in the new system? -- /ahnberg.
Re: NANOG List Update - Moving Forward
- Original Message - The new posts do not have list (un)subscribe information in the headers. Also, a statement would be nice as to what header definitely *will* be in place that we can filter on. At the moment, I'm assuming 'List-ID', but I'm not sure if that header or its contents can be relied on. Regards, Tim.
Re: NANOG List Update - Moving Forward
On 07/12/11 03:21, Mikael Abrahamsson wrote: The new posts do not have list (un)subscribe information in the headers. Also, subscriptions that were set to no mail delivery are now delivering mail. Is this expected? Grant. . . .
Myspace contact needed
Sorry about the lack of details. I'm looking for a Myspace contact, We're an ISP (AS20394) and all of our users are getting a 302 redirect to google after contacting a myspace server. If there is an appropriate contact on this list, or someone who can forward this to such a contact, it would be greatly appreciated. I don't have this issue from other ISP connections(such as my home connection), but have not heard back from the website support portal as of yet. wkeen@tnwx-nms-3:~$ traceroute www.myspace.com traceroute to www.myspace.com (216.178.39.11), 30 hops max, 40 byte packets 1 tnwx-core-1.rainierconnect.com (69.10.208.1) 0.409 ms 0.479 ms 0.559 ms 2 74.50.203.97 (74.50.203.97) 1.772 ms 1.769 ms 1.805 ms 3 ge5-0-2d0.cir1.seattle7-wa.us.xo.net (216.156.100.41) 1.703 ms 1.708 ms 1.707 ms 4 4.59.232.53 (4.59.232.53) 2.064 ms 2.067 ms 2.056 ms 5 ae-31-51.ebr1.Seattle1.Level3.net (4.69.147.150) 11.408 ms 11.374 ms 11.484 ms 6 ae-7-7.ebr2.SanJose1.Level3.net (4.69.132.49) 19.095 ms 18.870 ms 18.997 ms 7 ae-34-34.ebr4.SanJose1.Level3.net (4.69.153.34) 20.638 ms 30.373 ms 30.333 ms 8 ae-5-5.ebr2.SanJose5.Level3.net (4.69.148.141) 19.631 ms 19.813 ms 19.803 ms 9 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 29.283 ms 28.981 ms 29.246 ms 10 ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 29.091 ms ae-72-72.csw2.LosAngeles1.Level3.net (4.69.137.22) 29.461 ms 29.437 ms 11 ae-24-70.car4.LosAngeles1.Level3.net (4.69.144.70) 29.684 ms ae-44-90.car4.LosAngeles1.Level3.net (4.69.144.198) 29.562 ms ae-14-60.car4.LosAngeles1.Level3.net (4.69.144.6) 29.680 ms 12 ve202.lax.myspace.com (4.71.128.10) 29.351 ms 28.998 ms 29.203 ms 13 vl342.cs2.lax1.myspace.com (204.16.35.137) 29.431 ms 29.540 ms 29.638 ms 14 vl3552.cs2.els2.myspace.com (216.178.35.77) 29.970 ms 29.717 ms 29.726 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * wkeen@tnwx-nms-3:~$ wget www.myspace.com --2011-07-12 06:45:32-- http://www.myspace.com/ Resolving www.myspace.com... 63.135.80.46 Connecting to www.myspace.com|63.135.80.46|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.com [following] --2011-07-12 06:45:32-- http://www.google.com/ Resolving www.google.com... 72.14.213.106, 72.14.213.147, 72.14.213.99, ... Connecting to www.google.com|72.14.213.106|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html.5' [ = ] 9,908 --.-K/s in 0.009s 2011-07-12 06:45:32 (1.01 MB/s) - `index.html.5' saved [9908] wkeen@tnwx-nms-3:~$ walter.k...@rainierconnect.net wrote: My apologies all, I meant to say myspace contact You're more likely to get a response if you give some indication of what the issue is; for example, saying I'm looking for a MySpace contact because there is an attack coming from their servers that appears to indicate they may have been compromised will likely get you a faster reaction from the security people. Or, if it's a network issue, saying I'm looking for a MySpace network contact because it appears they are announcing the following blocks which really belong to me, which is causing reachability issues will more likely get you a reaction from an appropriate network person. Without an indication of the nature of the problem, I think you'll find most people on the list tend to ignore generic requests like this. Thanks! Matt
Re: NANOG Move - Moved back
On 2011-07-12 15:59 , Michael K. Smith - Adhost wrote: Hello All: We're back on the old configuration for now. I will send an update later this afternoon once I speak with AMS about the issues we experienced over night. What is the reason for dropping mailman btw? The IETF, which is also taking secretarial services and hosting etc from AMSL still have it... Greets, Jeroen
Re: NANOG Move - Moved back
On 7/12/2011 6:59 AM, Michael K. Smith - Adhost wrote: Hello All: We're back on the old configuration for now. I will send an update later this afternoon once I speak with AMS about the issues we experienced over night. Please explain WHY we can't just stay on Mailman? I know you explained it privately to me already, but none of those reasons are seeming very good right now. Mailman was working, just fine. You are making me very sad, and I haven't had enough coffee to be polite. -- Requiescat in Pacem, Len http://en.wikipedia.org/wiki/Len_Sassaman
Re: NANOG List Update - Moving Forward
Steve, I'm seeing the following issues, also as reported by others: * No RFC 2369 headers means a fun time filtering and no unsubscribe info (maybe that one is on purpose? :) I kid!) * The mailing list is stripping out all Received: headers from prior to the message hitting the listserver * For me at least, messages seem to be delivered out of order - I received this message almost immediately, but messages from 2 hours ago are still making their way into my mailbox. This was not occurring before and it's not a problem with my mail provider. Warm regards, Ben -Original Message- From: Steve Feldman feld...@twincreeks.net Sent: Tuesday, July 12, 2011 10:00am To: deles...@gmail.com Cc: NANOG list nanog@nanog.org Subject: Re: NANOG List Update - Moving Forward We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. Thanks, Steve On Jul 12, 2011, at 5:03 AM, jim deleskie wrote: +1 On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock neno...@systeminplace.net wrote: On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin t...@pelican.org wrote: Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Ditto. Getting lots of crap here. William
Re: NANOG List Update - Moving Forward
On Jul 12, 2011, at 00:19 , Michael K. Smith - Adhost wrote: Mailman is shut down on s0.nanog.org and mail is being routed directly to mail.amsl.com where it is being processed by our new list (etc.) system. Will the list archives migrate? What about future list archives? Thanks G
Re: Can somebody stop nanog@nanog.org from forwarding spam, kthx!
jer...@unfix.org (Jeroen Massar) wrote: I am fairly sure that the fake Western Union message and various other spams that are dripping through are from real subscribers... Err... what I find most interesting is that I have received no spam via this list today. I've checked my spamfilters' garbage heap... Did someone unsubscribe me from the spam part of the list? Thank you :) Elmar.
Re: NANOG List Update - Moving Forward
On Tue, Jul 12, 2011 at 1:19 AM, Michael K. Smith - Adhost mksm...@adhost.com wrote: Thankfully, the current test has been a success. We are going to stay in Hooray for testing in production. -cjp
Re: Spam?
New location means we now get spam on Nanog? no extra charge :) i have lived through maintaing decades of mailing lists and do not envy the nanog mailing list crew and glen over at amsl. thanks for the hard work, folk. randy
Re: Spam?
On Tue, Jul 12, 2011 at 7:45 AM, Randy Bush ra...@psg.com wrote: New location means we now get spam on Nanog? no extra charge :) i have lived through maintaing decades of mailing lists and do not envy the nanog mailing list crew and glen over at amsl. thanks for the hard work, folk. Let's work harder -- seriously, MailMan seemed to be working fine. ~:-/ - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: NANOG List Update - Moving Forward
Thankfully, the current test has been a success. We are going to stay in Hooray for testing in production. we are not dealing with stupid or inexperienced people here. i assume they tested. but, like our beloved vendors, they also have a hard time reproducing the real network in the lab, so we end up debugging it for them. otoh, i am willing to wager that in a few weeks, we will not see bugs in the list. sure can't say the same for the vendors. randy
Re: Spam?
thanks for the hard work, folk. Let's work harder thanks for volunteering. when will you be flying out to the bay? randy
Re: Spam?
On Tue, Jul 12, 2011 at 8:00 AM, Randy Bush ra...@psg.com wrote: thanks for the hard work, folk. Let's work harder thanks for volunteering. when will you be flying out to the bay? I already live in The Bay Area. Is there an 'revert' button? - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Spam?
I received no spam, and had I received 2 pieces, it may have been slightly irritating. What is irritating is the sheer number of people complaining about it. Can we stop please? I think they get it. -=Tom On Tue, 12 Jul 2011 09:58:42 -0500, Paul Ferguson fergdawgs...@gmail.com wrote: On Tue, Jul 12, 2011 at 7:45 AM, Randy Bush ra...@psg.com wrote: New location means we now get spam on Nanog? no extra charge :) i have lived through maintaing decades of mailing lists and do not envy the nanog mailing list crew and glen over at amsl. thanks for the hard work, folk. Let's work harder -- seriously, MailMan seemed to be working fine. ~:-/ - ferg -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: NANOG List Update - Moving Forward
On Tue, Jul 12, 2011 at 7:59 AM, Randy Bush ra...@psg.com wrote: Thankfully, the current test has been a success. We are going to stay in Hooray for testing in production. we are not dealing with stupid or inexperienced people here. i assume they tested. but, like our beloved vendors, they also have a hard time reproducing the real network in the lab, so we end up debugging it for them. otoh, i am willing to wager that in a few weeks, we will not see bugs in the list. sure can't say the same for the vendors. Please -- give it a rest. And let's take this thread to it's ultimate conclusion, please. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: NANOG List Update - Moving Forward
Cc: na...@nanog.org.r-bonomi.com In-Reply-To: 1be304a1-0da0-4558-83ad-0e4f08f81...@twincreeks.net Subject: Re: NANOG List Update - Moving Forward From: Steve Feldman feld...@twincreeks.net Date: Tue, 12 Jul 2011 07:00:51 -0700 We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. You asked for it, you got it: 1) You broke *all* the mailing-list support addresses. 'nanog-owner' ,etc. *BOUNCE* user unknown see mark's inbox for a smoking gun 2) You let non-members post to the list. see mark's inbox for a smoking gun 3) You broke the mailing-list *submission* address itself, for subscribers. Although you let non-member *SPAM* through. 4) You have dropped _all_ the the received lines _before_ the message gets to the list. see mark's inbox for a smoking gun -- one of the spam messages 5) You are *NOT* using 'custom 'From ' lines, meaning you cannot tell who the subscriber is when a forwarded message bounces. see mark's inbox for a smoking gun -- one of the spam messages 6) You dropped *ALL* the list-management info headers. see mark's inbox for a smoking gun -- one of the spam messages 7) You rolled changes out with _NOBODY_AROUND_ to take complaints from users who noticed problems. 8) You are mailing to undisclosed recipients. This indicates less than competent, *lazy*, mailing-list management practices. AND making it impossible for the recipient to determine _what_ e-mail address the message was actually sent to, *if* for instance they need to change their subscription information on a 'forwarded' (or worse, _multiply-forwarded_) subscription address. see mark's inbox for a smoking gun -- one of the spam messages 9) Others report you lost some, if not all, of the established mailing 'preferences' for subscribers. *AND* all this was on the *second* attempt, having already utterly botched the first one. Reports were being sent to Mark's email (he who posted the announcement, the 'test' and the notice saying things were 'apparently working') roughly 2-1/2 hours after the -first- problem surfaced. SIX hours later the problem was still occuring. Asleep at the switch would seem to apply. Considering =ALL= of the above the statement that you have your top people working on the matter is not in the least reasurring. One *also* has to wonder -- considering all the other things that were 'lost', if the existing suppression filters -- specifically those which keep 'banned' traffic off the list -- were *also* 'lost'. One _really_ has to wonder why things are being moved off a tested, reliable, and fully reliable platform, to an obviously flawed implementation. Methinks the decision-makers owe the list subscribers _some_ explanation with regard to the 'advantages' to be gained by this migration, and why it is necessary.
Re: Spam?
On 7/12/2011 10:00 AM, Randy Bush wrote: thanks for the hard work, folk. Let's work harder thanks for volunteering. when will you be flying out to the bay? randy I'm with you Randy, I'm disappointed with the complaints I see here. People don't seem to show much appreciation. Jason
AMSL vs the ex-incument
AMSL has a number of interesting operational choices in its handling of email. Lets see if they are willing to take the email from a NANOG supporter (fiscally). /bill
RE: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? Ron -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a we'll look at that later response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles.
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica wrote: Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. I don't think it's that simple, sadly. I'll no doubt get flamed by the 5 people on NANOG that also participate in the IETF in a regular basis, but the reality is most operators don't want to sit through multi-year protocol devopment work, or have much of anything to do with pie in the sky ideas. The IETF can, should, and does do both of those things today. Where the friction occurs is there is no good place to loop the operators back in, so they are often kicked out, discouraged, or just uninterested on the front end (we're going to go play with new ideas kids!) and then not brought back in (it's ready for deployment, wait, why are no operators interested). So it's not that individual issues are of interest to operators (outside of the IETF OPS area, which is a special case), it's that the process needs work. I'll pick on LISP as an example, since many operators are at least aware of it. Some operators have said we need a locator and identifier split. Interesting feedback. The IETF has gone off and started playing in the sandbox, trying to figure out how to make that go. Several years of coding have occured, a bunch of proof of concept testing is going on. Even many of the operators who wanted such a spit are not really interested in following the details of the work right now. Of course, if you are, you can, I'm not advocating any exclusions. But there is no roadmap in the IETF process now for LISP that says We've got this 90% baked, we need to circulate a draft to the NANOG mailing list, request operator comments, and actively solicit operators to participate in the expanded test network. We need that mechanism to tell folks hey, it's real enough your operational feedback is now useful and come test our new idea. Today the IETF just finishes their work, tosses it over the wall and hopes for the best. Generally it's not 100%, and vendors make propretary changes to the standards slowly over time to meet the needs of operators. It would be far better if there was at least one round of ask the operators and incorproate feedback before it went over the wall, and in paricular before working groups disbanded. In short, make it easy for the operators to participate at the right time in the process. It will be better for everyone! -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote: Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? There may be an OPS area, but it is not listened to. Witness the latest debacle with the attempt at trying to make 6to4 historic. Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have thumb wrestle these people who don't actually have any skin in the game. Cameron Ron -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a we'll look at that later response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles.
Re: Spam?
On Jul 12, 2011, at 11:02 AM, Thomas Donnelly wrote: I received no spam, and had I received 2 pieces, it may have been slightly irritating. What is irritating is the sheer number of people complaining about it. Can we stop please? I think they get it. -=Tom Tom, you are one of the lucky ones -- I have received over two dozen SPAM via NANOG in the last 24 hours. And, yes, it would be gratifying to know why the change - is the new configuration less expensive? (to the list manager, not us, obviously) Also, where is the reply to header? James R. Cutler james.cut...@consultant.com
Re: Can somebody stop nanog@nanog.org from forwarding spam, kthx!
As far as I can tell me neither. I feel so left out :( Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 7/12/2011 10:43 AM, Elmar K. Bins wrote: jer...@unfix.org (Jeroen Massar) wrote: I am fairly sure that the fake Western Union message and various other spams that are dripping through are from real subscribers... Err... what I find most interesting is that I have received no spam via this list today. I've checked my spamfilters' garbage heap... Did someone unsubscribe me from the spam part of the list? Thank you :) Elmar.
Re: Myspace contact needed
I use a VPN from Beijing, where I reside. It's pretty common for myspace to blacklist any IP addresses that they believe belong to crawlers, linkbots, VPN services, etc. This appears to be an automated process. I've never had luck getting any of my VPN IPs unblocked. Good luck getting in touch with anyone there, the company was just sold to a consortium of celebrities after massive News Corp. layoffs and it's left with walking zombies. I'd be surprised if anyone competent is still left... -TProphet On 7/12/2011 9:49 PM, Walter Keen wrote: Sorry about the lack of details. I'm looking for a Myspace contact, We're an ISP (AS20394) and all of our users are getting a 302 redirect to google after contacting a myspace server. If there is an appropriate contact on this list, or someone who can forward this to such a contact, it would be greatly appreciated. I don't have this issue from other ISP connections(such as my home connection), but have not heard back from the website support portal as of yet. wkeen@tnwx-nms-3:~$ traceroute www.myspace.com traceroute to www.myspace.com (216.178.39.11), 30 hops max, 40 byte packets 1 tnwx-core-1.rainierconnect.com (69.10.208.1) 0.409 ms 0.479 ms 0.559 ms 2 74.50.203.97 (74.50.203.97) 1.772 ms 1.769 ms 1.805 ms 3 ge5-0-2d0.cir1.seattle7-wa.us.xo.net (216.156.100.41) 1.703 ms 1.708 ms 1.707 ms 4 4.59.232.53 (4.59.232.53) 2.064 ms 2.067 ms 2.056 ms 5 ae-31-51.ebr1.Seattle1.Level3.net (4.69.147.150) 11.408 ms 11.374 ms 11.484 ms 6 ae-7-7.ebr2.SanJose1.Level3.net (4.69.132.49) 19.095 ms 18.870 ms 18.997 ms 7 ae-34-34.ebr4.SanJose1.Level3.net (4.69.153.34) 20.638 ms 30.373 ms 30.333 ms 8 ae-5-5.ebr2.SanJose5.Level3.net (4.69.148.141) 19.631 ms 19.813 ms 19.803 ms 9 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 29.283 ms 28.981 ms 29.246 ms 10 ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 29.091 ms ae-72-72.csw2.LosAngeles1.Level3.net (4.69.137.22) 29.461 ms 29.437 ms 11 ae-24-70.car4.LosAngeles1.Level3.net (4.69.144.70) 29.684 ms ae-44-90.car4.LosAngeles1.Level3.net (4.69.144.198) 29.562 ms ae-14-60.car4.LosAngeles1.Level3.net (4.69.144.6) 29.680 ms 12 ve202.lax.myspace.com (4.71.128.10) 29.351 ms 28.998 ms 29.203 ms 13 vl342.cs2.lax1.myspace.com (204.16.35.137) 29.431 ms 29.540 ms 29.638 ms 14 vl3552.cs2.els2.myspace.com (216.178.35.77) 29.970 ms 29.717 ms 29.726 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * wkeen@tnwx-nms-3:~$ wget www.myspace.com --2011-07-12 06:45:32-- http://www.myspace.com/ Resolving www.myspace.com... 63.135.80.46 Connecting to www.myspace.com|63.135.80.46|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.com [following] --2011-07-12 06:45:32-- http://www.google.com/ Resolving www.google.com... 72.14.213.106, 72.14.213.147, 72.14.213.99, ... Connecting to www.google.com|72.14.213.106|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html.5' [ = ] 9,908 --.-K/s in 0.009s 2011-07-12 06:45:32 (1.01 MB/s) - `index.html.5' saved [9908] wkeen@tnwx-nms-3:~$ walter.k...@rainierconnect.net wrote: My apologies all, I meant to say myspace contact You're more likely to get a response if you give some indication of what the issue is; for example, saying I'm looking for a MySpace contact because there is an attack coming from their servers that appears to indicate they may have been compromised will likely get you a faster reaction from the security people. Or, if it's a network issue, saying I'm looking for a MySpace network contact because it appears they are announcing the following blocks which really belong to me, which is causing reachability issues will more likely get you a reaction from an appropriate network person. Without an indication of the nature of the problem, I think you'll find most people on the list tend to ignore generic requests like this. Thanks! Matt
Re: Spam?
Also, where is the reply to header? still in the garbage, where it belongs
Re: Can somebody stop nanog@nanog.org from forwarding spam, kthx!
On 7/12/11 9:47 AM, Ryan Pavely wrote: As far as I can tell me neither. I feel so left out :( You probably don't have nanog@nanog.org and its associated mail servers whitelisted in spamassassin/filtering/etc. In an effort to avoid bouncing list mail, I put them in a while back. Unfortunately, side effect is exactly what happened last night. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Tue, Jul 12, 2011 at 8:42 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica wrote: Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. I don't think it's that simple, sadly. I'll no doubt get flamed by the 5 people on NANOG that also participate in the IETF in a regular basis, but the reality is most operators don't want to sit through multi-year protocol devopment work, or have much of anything to do with pie in the sky ideas. The IETF can, should, and does do both of those things today. Where the friction occurs is there is no good place to loop the operators back in, so they are often kicked out, discouraged, or just uninterested on the front end (we're going to go play with new ideas kids!) and then not brought back in (it's ready for deployment, wait, why are no operators interested). So it's not that individual issues are of interest to operators (outside of the IETF OPS area, which is a special case), it's that the process needs work. I'll pick on LISP as an example, since many operators are at least aware of it. Some operators have said we need a locator and identifier split. Interesting feedback. The IETF has gone off and started playing in the sandbox, trying to figure out how to make that go. Several years of coding have occured, a bunch of proof of concept testing is going on. Even many of the operators who wanted such a spit are not really interested in following the details of the work right now. Of course, if you are, you can, I'm not advocating any exclusions. W.R.T. to LISP, in defense of the IETF or the IRTF, i do not believe the IETF has told the world that LISP is the best fit for the Internet or solves any specific problem well. The IETF has never said the Internet Architecture is going to LISP, and it likely will not / cannot. My expectation is that LISP will go away as quickly as it came. Cameron But there is no roadmap in the IETF process now for LISP that says We've got this 90% baked, we need to circulate a draft to the NANOG mailing list, request operator comments, and actively solicit operators to participate in the expanded test network. We need that mechanism to tell folks hey, it's real enough your operational feedback is now useful and come test our new idea. Today the IETF just finishes their work, tosses it over the wall and hopes for the best. Generally it's not 100%, and vendors make propretary changes to the standards slowly over time to meet the needs of operators. It would be far better if there was at least one round of ask the operators and incorproate feedback before it went over the wall, and in paricular before working groups disbanded. In short, make it easy for the operators to participate at the right time in the process. It will be better for everyone! -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Myspace contact needed
I finally made contact using the information at http://whois.arin.net/rest/poc/NOC11562-ARIN.html . We were blocked for spamming (but there seemed to be some confusion, as we have 69.10.192.0/19, and they asked if we had 69.10.0.0/16. Makes me wonder if they lookup the RIR allocated blocks before blocking, or assume a /16 Walter Keen Network Engineer Rainier Connect (P) 360-832-4024 (C) 253-302-0194 On 07/12/2011 08:50 AM, TProphet wrote: I use a VPN from Beijing, where I reside. It's pretty common for myspace to blacklist any IP addresses that they believe belong to crawlers, linkbots, VPN services, etc. This appears to be an automated process. I've never had luck getting any of my VPN IPs unblocked. Good luck getting in touch with anyone there, the company was just sold to a consortium of celebrities after massive News Corp. layoffs and it's left with walking zombies. I'd be surprised if anyone competent is still left... -TProphet On 7/12/2011 9:49 PM, Walter Keen wrote: Sorry about the lack of details. I'm looking for a Myspace contact, We're an ISP (AS20394) and all of our users are getting a 302 redirect to google after contacting a myspace server. If there is an appropriate contact on this list, or someone who can forward this to such a contact, it would be greatly appreciated. I don't have this issue from other ISP connections(such as my home connection), but have not heard back from the website support portal as of yet. wkeen@tnwx-nms-3:~$ traceroute www.myspace.com traceroute to www.myspace.com (216.178.39.11), 30 hops max, 40 byte packets 1 tnwx-core-1.rainierconnect.com (69.10.208.1) 0.409 ms 0.479 ms 0.559 ms 2 74.50.203.97 (74.50.203.97) 1.772 ms 1.769 ms 1.805 ms 3 ge5-0-2d0.cir1.seattle7-wa.us.xo.net (216.156.100.41) 1.703 ms 1.708 ms 1.707 ms 4 4.59.232.53 (4.59.232.53) 2.064 ms 2.067 ms 2.056 ms 5 ae-31-51.ebr1.Seattle1.Level3.net (4.69.147.150) 11.408 ms 11.374 ms 11.484 ms 6 ae-7-7.ebr2.SanJose1.Level3.net (4.69.132.49) 19.095 ms 18.870 ms 18.997 ms 7 ae-34-34.ebr4.SanJose1.Level3.net (4.69.153.34) 20.638 ms 30.373 ms 30.333 ms 8 ae-5-5.ebr2.SanJose5.Level3.net (4.69.148.141) 19.631 ms 19.813 ms 19.803 ms 9 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 29.283 ms 28.981 ms 29.246 ms 10 ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 29.091 ms ae-72-72.csw2.LosAngeles1.Level3.net (4.69.137.22) 29.461 ms 29.437 ms 11 ae-24-70.car4.LosAngeles1.Level3.net (4.69.144.70) 29.684 ms ae-44-90.car4.LosAngeles1.Level3.net (4.69.144.198) 29.562 ms ae-14-60.car4.LosAngeles1.Level3.net (4.69.144.6) 29.680 ms 12 ve202.lax.myspace.com (4.71.128.10) 29.351 ms 28.998 ms 29.203 ms 13 vl342.cs2.lax1.myspace.com (204.16.35.137) 29.431 ms 29.540 ms 29.638 ms 14 vl3552.cs2.els2.myspace.com (216.178.35.77) 29.970 ms 29.717 ms 29.726 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * wkeen@tnwx-nms-3:~$ wget www.myspace.com --2011-07-12 06:45:32-- http://www.myspace.com/ Resolving www.myspace.com... 63.135.80.46 Connecting to www.myspace.com|63.135.80.46|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.com [following] --2011-07-12 06:45:32-- http://www.google.com/ Resolving www.google.com... 72.14.213.106, 72.14.213.147, 72.14.213.99, ... Connecting to www.google.com|72.14.213.106|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html.5' [ = ] 9,908 --.-K/s in 0.009s 2011-07-12 06:45:32 (1.01 MB/s) - `index.html.5' saved [9908] wkeen@tnwx-nms-3:~$ walter.k...@rainierconnect.net wrote: My apologies all, I meant to say myspace contact You're more likely to get a response if you give some indication of what the issue is; for example, saying I'm looking for a MySpace contact because there is an attack coming from their servers that appears to indicate they may have been compromised will likely get you a faster reaction from the security people. Or, if it's a network issue, saying I'm looking for a MySpace network contact because it appears they are announcing the following blocks which really belong to me, which is causing reachability issues will more likely get you a reaction from an appropriate network person. Without an indication of the nature of the problem, I think you'll find most people on the list tend to ignore generic requests like this. Thanks! Matt
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On 10 Jul 2011, at 21:22, Owen DeLong wrote: On Jul 10, 2011, at 12:23 PM, William Herrin wrote: Consider, for example, RFC 3484. That's the one that determines how an IPv6 capable host selects which of a group of candidate IPv4 and IPv6 addresses for a particular host name gets priority. How is a server's address priority NOT an issue that should be managed at an operations level by individual server administrators? Yet the working group which produced it came up with a static prioritization that is the root cause of a significant portion of the IPv6 deployment headaches we face. 3484 specifies a static default. By definition, defaults in absence of operator configuration kind of have to be static. Having a reasonable and expected set of defaults documented in an RFC provides a known quantity for what operators can/should expect from hosts they have not configured. I see nothing wrong with RFC 3484 other than I would agree that the choices made were suboptimal. Mostly that was based on optimism and a lack of experience available at the time of writing. There is another RFC and there are APIs and most operating systems have configuration mechanisms where an operator CAN set that to something other than the 3484 defaults. There is a DHCPv6 option to configure host policy described in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01, which is hopefully approaching a WGLC at IETF81. RFC3484 was originally published in 2003, which is a long time ago. And of course it turned out that, with wider operational experience and feedback from the operator community, there were some issues uncovered and some omissions. Perhaps some of those might have been foreseen, but I highly doubt all of them would have. Many of the issues were captured in RFC5220, which led to the work on RFC3484-bis, which is also close to publication. Now, perhaps the DHCPv6 option and the 3484-bis drafts could be posted to the NANOG list at an appropriate time, for example when the docs hit WGLC. But there are a lot of WGLCs out there and the question is then whether the NANOG list, or some special NANOG list for IETF WGLCs, would want all those notifications. As a co-author of the DHCPv6 and 3484-bis drafts, I am quite happy to post about these to NANOG as they approach last call. There are three open issues on 3484-bis that some feedback would be welcomed on. There should be an operations callout as well -- a section where proposed operations defaults (as well as statics for which a solid case can be made for an operations tunable) are extracted from the thick of it and offered for operator scrutiny prior to publication of the RFC. I think this would be a good idea, actually. It would probably be more effective to propose it to IETF than to NANOG, however. Whether it's a separate section in the draft, or a recommendation to post to operators communities (which is more than just NANOG of course), the question as mentioned above is how that's done in a way to get the attention of appropriate operators without drowning them in notifications. Tim
ep.net contact?
Could someone involved in ep.net contact me off list in regard to a DNS issue. Usual contact methods have failed to date. Thanks Chris --- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611
Re: NANOG List Update - Moving Forward
- Original Message - From: Ben Carleton b...@bencarleton.com * The mailing list is stripping out all Received: headers from prior to the message hitting the listserver You're the third person to report that, but *I* am seeing incoming Received headers in my messages here -- yours, for example, has them all, even prior to the message hitting s0. Great name, there, BTW. s0. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: NANOG List Update - Moving Forward
- Original Message - From: Gerry Boudreaux ge...@tape.net On Jul 12, 2011, at 00:19 , Michael K. Smith - Adhost wrote: Mailman is shut down on s0.nanog.org and mail is being routed directly to mail.amsl.com where it is being processed by our new list (etc.) system. Will the list archives migrate? What about future list archives? And please remember the First Rule Of The Web: *DO NOT Break the URLs*. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
RE: NANOG List Update - Moving Forward
Its great to see how quick a response we are getting, they have their top people working on it??? Perhaps my 14 year old son should apply for a job as one the trainers for the so called experts on this. Ralph -Original Message- From: Robert Bonomi [mailto:bon...@mail.r-bonomi.com] Sent: Tuesday, July 12, 2011 8:14 AM To: nanog@nanog.org Subject: Re: NANOG List Update - Moving Forward Cc: na...@nanog.org.r-bonomi.com In-Reply-To: 1be304a1-0da0-4558-83ad-0e4f08f81...@twincreeks.net Subject: Re: NANOG List Update - Moving Forward From: Steve Feldman feld...@twincreeks.net Date: Tue, 12 Jul 2011 07:00:51 -0700 We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. You asked for it, you got it: 1) You broke *all* the mailing-list support addresses. 'nanog-owner' ,etc. *BOUNCE* user unknown see mark's inbox for a smoking gun 2) You let non-members post to the list. see mark's inbox for a smoking gun 3) You broke the mailing-list *submission* address itself, for subscribers. Although you let non-member *SPAM* through. 4) You have dropped _all_ the the received lines _before_ the message gets to the list. see mark's inbox for a smoking gun -- one of the spam messages 5) You are *NOT* using 'custom 'From ' lines, meaning you cannot tell who the subscriber is when a forwarded message bounces. see mark's inbox for a smoking gun -- one of the spam messages 6) You dropped *ALL* the list-management info headers. see mark's inbox for a smoking gun -- one of the spam messages 7) You rolled changes out with _NOBODY_AROUND_ to take complaints from users who noticed problems. 8) You are mailing to undisclosed recipients. This indicates less than competent, *lazy*, mailing-list management practices. AND making it impossible for the recipient to determine _what_ e-mail address the message was actually sent to, *if* for instance they need to change their subscription information on a 'forwarded' (or worse, _multiply-forwarded_) subscription address. see mark's inbox for a smoking gun -- one of the spam messages 9) Others report you lost some, if not all, of the established mailing 'preferences' for subscribers. *AND* all this was on the *second* attempt, having already utterly botched the first one. Reports were being sent to Mark's email (he who posted the announcement, the 'test' and the notice saying things were 'apparently working') roughly 2-1/2 hours after the -first- problem surfaced. SIX hours later the problem was still occuring. Asleep at the switch would seem to apply. Considering =ALL= of the above the statement that you have your top people working on the matter is not in the least reasurring. One *also* has to wonder -- considering all the other things that were 'lost', if the existing suppression filters -- specifically those which keep 'banned' traffic off the list -- were *also* 'lost'. One _really_ has to wonder why things are being moved off a tested, reliable, and fully reliable platform, to an obviously flawed implementation. Methinks the decision-makers owe the list subscribers _some_ explanation with regard to the 'advantages' to be gained by this migration, and why it is necessary.
Re: Spam?
- Original Message - From: Randy Bush ra...@psg.com thanks for the hard work, folk. Let's work harder thanks for volunteering. when will you be flying out to the bay? I suspect, Randy, that Ferg *knows* how to use ssh. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Spam?
- Original Message - From: Randy Bush ra...@psg.com Also, where is the reply to header? still in the garbage, where it belongs NANOG, being a traditional, (semi-)public, technical mailing list, has never had a Reply-to header, and never should. I concur with the people who assert that adding the Reply-to header formally violates the relevant RFCs, quite aside from the Real World problems it can (and *has*) caused. http://woozle.org/~neale/papers/reply-to-still-harmful.html Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: NANOG List Update - Moving Forward
On 7/12/11 10:13 AM, Jay Ashworth wrote: - Original Message - From: Ben Carletonb...@bencarleton.com * The mailing list is stripping out all Received: headers from prior to the message hitting the listserver You're the third person to report that, but *I* am seeing incoming Received headers in my messages here -- yours, for example, has them all, even prior to the message hitting s0. Great name, there, BTW. s0. Looks like parts of the received like are still there, though butchered and mashed in (most likely in a non-RFC compliant manner) with the one added by 'bulk_maler v1.13' (great name for the mailer, btw, sets off my spammy sense something fierce). Received: from mail.amsl.com ([2001:1890:1112:1::14]) by mail.sosdg.org with esmtp (Exim 4.72-SOSDG) id 1QgVBE-0001sm-Oh; Mon, 11 Jul 2011 23:06:46 -0600 Received: by c1a.amsl.com (Postfix, from userid 65534) id 005B01C39169; Mon, 11 Jul 2011 22:01:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with SMTP id F26731C39160; Mon, 11 Jul 2011 22:01:16 -0700 (PDT) Received: by nanog.org (bulk_mailer v1.13); Mon, 11 Jul 2011 22:01:01 -0700 X-Virus-Scanned: amavisd-new at amsl.com by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrl8e1RiNVz9 for c5-22-1...@c1a.amsl.com; Mon, 11 Jul 2011 22:01:00 -0700 (PDT) by c1a.amsl.com (Postfix) with ESMTPS id E2ED01C38FB6 for nanog@nanog.org; Mon, 11 Jul 2011 22:00:59 -0700 (PDT) by s0.nanog.org with esmtp (Exim 4.72 (FreeBSD)) (envelope-from xxx) id 1QgV5e-000MmM-OE for nanog@nanog.org; Tue, 12 Jul 2011 05:00:58 + (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail-in02.adhost.com (Postfix) with ESMTPS id 0691FCBCD35 for nanog@nanog.org; Mon, 11 Jul 2011 22:00:58 -0700 (PDT) (envelope-from xxx) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: NANOG List Update - Moving Forward
Right, you should, because we are back on s0 (server zero?) and mailman. The headers were being suppressed by the AMSL servers, which are running that strange bulk_mailer 1.13 software. If you inspect the headers for any of the messages that were forwarded to us from that server (the one that started the thread called NANOG List Update - Moving Forward from Michael K Smith, for example), you will see that the headers are being stripped... --bc -Original Message- From: Jay Ashworth j...@baylink.com Sent: Tuesday, July 12, 2011 12:13pm To: NANOG nanog@nanog.org Subject: Re: NANOG List Update - Moving Forward - Original Message - From: Ben Carleton b...@bencarleton.com * The mailing list is stripping out all Received: headers from prior to the message hitting the listserver You're the third person to report that, but *I* am seeing incoming Received headers in my messages here -- yours, for example, has them all, even prior to the message hitting s0. Great name, there, BTW. s0. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: NANOG List Update - Moving Forward
The tolerance of some of you out there is amazing. You must be PS3 users crying because your free game network is down. Maybe we can get a subscription service set up for you so you have something else to complain about. Be patient people. Maybe a little appreciation to these experts wouldn't hurt you either. -Hammer- I was a normal American nerd -Jack Herer On 07/12/2011 11:16 AM, Ralph E. Whitmore, III wrote: Its great to see how quick a response we are getting, they have their top people working on it??? Perhaps my 14 year old son should apply for a job as one the trainers for the so called experts on this. Ralph -Original Message- From: Robert Bonomi [mailto:bon...@mail.r-bonomi.com] Sent: Tuesday, July 12, 2011 8:14 AM To: nanog@nanog.org Subject: Re: NANOG List Update - Moving Forward Cc: na...@nanog.org.r-bonomi.com In-Reply-To:1be304a1-0da0-4558-83ad-0e4f08f81...@twincreeks.net Subject: Re: NANOG List Update - Moving Forward From: Steve Feldmanfeld...@twincreeks.net Date: Tue, 12 Jul 2011 07:00:51 -0700 We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. You asked for it, you got it: 1) You broke *all* the mailing-list support addresses. 'nanog-owner' ,etc. *BOUNCE* user unknown see mark's inbox for a smoking gun 2) You let non-members post to the list. see mark's inbox for a smoking gun 3) You broke the mailing-list *submission* address itself, for subscribers. Although you let non-member *SPAM* through. 4) You have dropped _all_ the the received lines _before_ the message gets to the list. see mark's inbox for a smoking gun -- one of the spam messages 5) You are *NOT* using 'custom 'From ' lines, meaning you cannot tell who the subscriber is when a forwarded message bounces. see mark's inbox for a smoking gun -- one of the spam messages 6) You dropped *ALL* the list-management info headers. see mark's inbox for a smoking gun -- one of the spam messages 7) You rolled changes out with _NOBODY_AROUND_ to take complaints from users who noticed problems. 8) You are mailing to undisclosed recipients. This indicates less than competent, *lazy*, mailing-list management practices. AND making it impossible for the recipient to determine _what_ e-mail address the message was actually sent to, *if* for instance they need to change their subscription information on a 'forwarded' (or worse, _multiply-forwarded_) subscription address. see mark's inbox for a smoking gun -- one of the spam messages 9) Others report you lost some, if not all, of the established mailing 'preferences' for subscribers. *AND* all this was on the *second* attempt, having already utterly botched the first one. Reports were being sent to Mark's email (he who posted the announcement, the 'test' and the notice saying things were 'apparently working') roughly 2-1/2 hours after the -first- problem surfaced. SIX hours later the problem was still occuring. Asleep at the switch would seem to apply. Considering =ALL= of the above the statement that you have your top people working on the matter is not in the least reasurring. One *also* has to wonder -- considering all the other things that were 'lost', if the existing suppression filters -- specifically those which keep 'banned' traffic off the list -- were *also* 'lost'. One _really_ has to wonder why things are being moved off a tested, reliable, and fully reliable platform, to an obviously flawed implementation. Methinks the decision-makers owe the list subscribers _some_ explanation with regard to the 'advantages' to be gained by this migration, and why it is necessary.
Re: NANOG List Update - Moving Forward
On Jul 12, 2011, at 12:23 PM, Brielle Bruns wrote: Looks like parts of the received like are still there, though butchered and mashed in (most likely in a non-RFC compliant manner) with the one added by 'bulk_maler v1.13' (great name for the mailer, btw, sets off my spammy sense something fierce). You seem to be new here. bulk_mailer was something used back in the day to workaround limitations in sendmail for those people operating majordomo (and those using smail etc). it broke the chunks into something that sendmail would then allocate multiple processes to. most other mail subsystems can handle the multiple-rcpts in different manners. while it may 'feel' spammy to you, it's certainly not. a simple google of majordomo and bulk_mailer should give you a good idea of what's going on. there were a lot of other mail systems that served to help integrate and interoperate back in the day, including qmailer, smail, etc that all attempted to replace sendmail, including providing the uucp interaction necessary for those behind dialup. either way, please try to keep the feedback off-list for now as we undergo this transition. It's hard to move a large list like this without trouble. I've been party to many such list moves in the past and they usually have all sorts of trouble. adm...@nanog.org is the right place for your feedback right now. - Jared
Re: NANOG List Update - Moving Forward
On 7/12/11 10:37 AM, Jared Mauch wrote: You seem to be new here. Since you asked, no, been around alot longer then I care to remember. bulk_mailer was something used back in the day to workaround limitations in sendmail for those people operating majordomo (and those using smail etc). it broke the chunks into something that sendmail would then allocate multiple processes to. most other mail subsystems can handle the multiple-rcpts in different manners. I actually was writing sendmail mc/cf files back in the 90s, and used to have a reasonably high traffic majordomo setup. Don't remember anything about bulk_mailer, but then again I stopped using majordomo around 10 years ago, so my memory may be going on stuff like that. while it may 'feel' spammy to you, it's certainly not. Hey, I call it as I see it. When you get to pour through spamtraps all day and evening looking at headers for common traits, yeah, things like 'bulk_mailer' stand out. a simple google of majordomo and bulk_mailer should give you a good idea of what's going on. Googling generic terms is quite fruitless these days, esp when all the spammers like to call their products bulk mailers. But, thank you for pointing out the context it is used in. I'm not the only one who expressed curiosity over this 'bulk_mailer' program, so please don't shoot me just cause I mentioned something about a pretty generic program name that throws up red flags whenever I see it. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Spam?
From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Tue Jul 12 11:29:29 2011 Date: Tue, 12 Jul 2011 12:22:09 -0400 (EDT) From: Jay Ashworth j...@baylink.com To: NANOG nanog@nanog.org Subject: Re: Spam? - Original Message - From: Randy Bush ra...@psg.com Also, where is the reply to header? still in the garbage, where it belongs NANOG, being a traditional, (semi-)public, technical mailing list, has never had a Reply-to header, and never should. I concur with the people who assert that adding the Reply-to header formally violates the relevant RFCs, quite aside from the Real World problems it can (and *has*) caused. *SIGH* One more problem with the 'new system', Messages through it _have_ a Reply-to: header. Set to the putative email of the sender, no less.
Re: NANOG List Update - Moving Forward
On 2011/07/12 16:20, Grant Taylor wrote: Also, subscriptions that were set to no mail delivery are now delivering mail. Is this expected? I saw duplicate messages from an account that I had disabled (while testing NANOG volumes to a portable messaging device and forwarding to this account) and assumed the list was duplicating responses. Took me a while to realise it was the vacation-suppression being b0rk. :/
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell bickn...@ufp.org wrote: I'll pick on LISP as an example, since many operators are at least aware of it. Some operators have said we need a locator and identifier split. Interesting feedback. The IETF has gone off and started playing in the sandbox, trying to figure out how to make that go. As an operator (who understands how most things work in very great detail), I found the LISP folks very much uninterested in my concerns about if LISP can ever be made to scale up to Internet-scale, with respect to a specific DDoS vector. I also think that an explosion of small, multi-homed SOHO networks would be a disaster, because we might have 3 million FIB instead of 360k FIB after a few years. These things are directly related to each-other, too. So I emailed some LISP gurus off-list and discussed my concern. I was encouraged to post to the LISP IETF list, which I did. To my great surprise, not one single person was interested in my problem. If you think it is a small problem, well, you should try going back to late-1990s flow-cache routing in your data-center networks and see what happens when you get DDoS. I am sure most of us remember some of those painful experiences. Now there is a LISP threats draft which the working group mandates they produce, discussing various security problems. The current paper is a laundry list of what if scenarios, like, what if a malicious person could fill the LISP control-plane with garbage. BGP has the same issue, if some bad guy had enable on a big enough network that their peers/transits don't filter their routes, they could do a lot of damage before they were stopped. This sometimes happens even by accident, for example, some poor guy accidentally announcing 12/9 and giving ATT a really bad day. What it doesn't contain is anything relevant to the special-case DDoS that all LISP sites would be vulnerable to, due to the IMO bad flow-cache management system that is specified. I am having a very great deal of trouble getting the authors of the threats document to even understand what the problem is, because as one of them put it, he is just a researcher. I am sure he and his colleagues are very smart guys, but they clearly do not remember our 1990s pains. That is the not an operator problem. It is understandable. Others who have been around long enough simply dismiss this problem, because they believe the unparalleled benefits of LISP for mobility and multi-homing SOHO sites must greatly out-weigh the fact that, well, if you are a content provider and you receive a DDoS, your site will be down and there isn't a damn thing you can do about it, other than spec routers that have way, way more FIB than the number of possible routes, again due to the bad caching scheme. The above is what I think is the ego-invested problem, where certain pretty smart, well-intentioned people have a lot of time, and professional credibility, invested in making LISP work. I'm sure it isn't pleasing for these guys to defend their project against my argument that it may never be able to reach Internet-scale, and that they have missed what I claim is a show-stopping problem with an easy way to improve it through several years of development. Especially since I am a guy who did not ever participate in the IETF before, someone they don't know from a random guy on the street. I am glad that this NANOG discussion has got some of these LISP folks to pay more attention to my argument, and my suggested improvement (I am not only bashing their project; I have positive input, too.) Simply posting to their mailing list once and emailing a few draft authors did not cause any movement at all. Evidently it does get attention, though, to jump up and down on a different list. Go figure! If operators don't provide input and *perspective* to things like LISP, we will end up with bad results. How many of us are amazed that we still do not have 32:32 bits BGP communities to go along with 32 bit ASNs, for signalling requests to transit providers without collision with other networks' community schemes? It is a pretty stupid situation, and yet here we are, with 32 bit ASN for years, and if you want to do advertisement control with 32 bit ASNs used, you are either mapping your 32 bit neighbors to special numbers, or your community scheme can overlap with others. That BGP community problem is pretty tiny compared to, what if people really started rolling out something new and clever like LISP, but in a half-baked, broken way that takes us back to 1990s era of small DDoS taking out whole data-center aggregation router. A lot of us think IPv6 is over-baked and broken, and probably this is why it has taken such a very long time to get anywhere with it. But ultimately, it is our fault for not participating. I am reversing my own behavior and providing input to some WGs I care about, in what time I have to do so. More operators should do the same.
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On 07/12/2011 08:43, Cameron Byrne wrote: Witness the latest debacle with the attempt at trying to make 6to4 historic. Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) FYI, my understanding (and I'm sure Ron will correct me if I'm wrong) is that what's actually happening is that the IESG is pushing that draft forward knowing that it's going to be appealed. The appeal process will then sort itself out, and we'll have a result. The fact that one person can stall the end result through the appeals process is both a strength and occasionally a burden of the way the IETF does its work. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
RE: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
-Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Tuesday, July 12, 2011 11:42 AM To: Ronald Bonica Cc: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) [snip] But there is no roadmap in the IETF process now for LISP that says We've got this 90% baked, we need to circulate a draft to the NANOG mailing list, request operator comments, and actively solicit operators to participate in the expanded test network. We need that mechanism to tell folks hey, it's real enough your operational feedback is now useful and come test our new idea. Leo, We need to fix this problem. Without the feedback loop that you describe, the IETF will never know whether they are producing useful stuff or nonsense. How does the following sound as a solution: Let's say we set up an new IETF mailing list, primarily for the use of operators. When an operator sees a draft that might be of interest to the operational community, he creates a new thread on the list, copying the draft authors and WG chairs. (The authors and chairs can decide whether to add the WG to the thread). The OPS AD will consider thread contents when evaluating the draft. Ron
RE: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
Cameron, Please stay tuned. While 6-to-4-historic is on hold, it is far from being dead. Expect more discussion in Quebec and on the mailing list. I doubt if there will be any final decision before Quebec. Ron -Original Message- From: Cameron Byrne [mailto:cb.li...@gmail.com] Sent: Tuesday, July 12, 2011 11:44 AM To: Ronald Bonica Cc: Leo Bicknell; nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote: Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? There may be an OPS area, but it is not listened to. Witness the latest debacle with the attempt at trying to make 6to4 historic. Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have thumb wrestle these people who don't actually have any skin in the game. Cameron Ron -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a we'll look at that later response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles.
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
Leo Bicknell wrote: In short, make it easy for the operators to participate at the right time in the process. It will be better for everyone! Unfortunately, where you want to be inserted into the process is when everybody has said their piece 80-dozen times and are tired and just want to get on with life. So it doesn't matter whether you're an operator or the IESG -- you're not going to make many friends at that point telling them they got it wrong. On the other hand, is it really too much to ask operators -- especially big ones with a vested interest in not having the IETF throw crap over the wall for them to debug -- to *hire* a liaison whose job is to monitor a swath of working groups, bofs, etc, and participate the entire way through? I imagine they'd be pretty popular amongst clueful vendors, and would give you a leg up knowing what's good and what's just sales-drek. Mike
Re: ep.net contact?
Got in touch with them. Thanks to all those who replied. tnx Chris Sent from my iPad On Jul 12, 2011, at 9:13 AM, Chris Griffin cgrif...@ufl.edu wrote: Could someone involved in ep.net contact me off list in regard to a DNS issue. Usual contact methods have failed to date. Thanks Chris --- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611
using NESSUS to prepare for PenTest Sec. Audit
Has anyone used Nessus PF (www.nessus.org) as a tool to run a self audit preparing for a PenTest Audit? I wanted to get your opinion on the tool and if it was useful preparing for a PenTest Audit? Thanks, -- Michael Gatti cell.949.735.5612 ekim.it...@gmail.com (UTC-8)
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 12, 2011, at 12:40 PM, Michael Thomas wrote: Leo Bicknell wrote: In short, make it easy for the operators to participate at the right time in the process. It will be better for everyone! Unfortunately, where you want to be inserted into the process is when everybody has said their piece 80-dozen times and are tired and just want to get on with life. So it doesn't matter whether you're an operator or the IESG -- you're not going to make many friends at that point telling them they got it wrong. On the other hand, is it really too much to ask operators -- especially big ones with a vested interest in not having the IETF throw crap over the wall for them to debug -- to *hire* a liaison whose job is to monitor a swath of working groups, bofs, etc, and participate the entire way through? I imagine they'd be pretty popular amongst clueful vendors, and would give you a leg up knowing what's good and what's just sales-drek. By definition if crap has been thrown of the wall and you're trying to deploy it, that means: * you have a commercial or other compelling reason to run it. * someone has implemented it. the bar to make something relevant on those two points is much higher, than the one that involves submitting an internet draft. getting something through draft to publication via a working group is itself a rather involved process. Plenty of crap is thrown over the wall which you will never use, because the marketplace doesn't care, nobody built it, nobody has that problem it turns out, it turned out to be too hard or it was actually a dumb idea. in the market place for idea this seems normal and healthy. Mike
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote: Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? There may be an OPS area, but it is not listened to. Witness the latest debacle with the attempt at trying to make 6to4 historic. Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) Those are all REALLY bad ideas. Speaking as an operator, the best thing you can do to alleviate the problems with 6to4 is operate more, not less 6to4 relays. Unless of course the large providers get their shared transition space in which case all 6to4 behind it will break in a really ugly way, pretty much exactly like in the mobile operator in question. The goal of 6to4 to historic was not to encourage the outcome described, it was to take having 6to4 as a default method of any kind off the table going into the future. If mature adults want to use it great, but conformance tests shouldn't require it, CPE shouldn't it on just because what they think they have a is a public IP with not filtering and hosts shouldn't use it unless told to do so.. Blocking over IPv4 transport is just silly. It's just as likely that your record is destined for an end-host that has native IPv6 connectivity with an intermediate resolver that desn't have IPv6 as it is that you're sending that to a 6to4 host. Further, there's no reason to believe the 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help anyway. Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have thumb wrestle these people who don't actually have any skin in the game. I agree, but, it's not hard to run 6to4 relays and running them does much more to alleviate the problems with 6to4 than anything you proposed above. Indeed, what you proposed above will likely create more customer issues rather than reduce them. Owen Cameron Ron -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a we'll look at that later response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles.
best practices for management nets in IPv6
Hi All, We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? Tom - Tom Ammon Network Engineer M: (801)674-9273 tom.am...@utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -
Re: using NESSUS to prepare for PenTest Sec. Audit
On Tue, Jul 12, 2011 at 2:00 PM, Mike Gatti ekim.it...@gmail.com wrote: Has anyone used Nessus PF (www.nessus.org) as a tool to run a self audit preparing for a PenTest Audit? I wanted to get your opinion on the tool and if it was useful preparing for a PenTest Audit? Nessus is mostly used for information security systems audits (of the vulnerability assessment one-shot type e.g. OCTAVE Allegro ; or possibly the on-going vulnerability management type e.g. NIST SP 800-30). It is not useful for external, unauthenticated scans or black-box pen-tests. Nessus works best when given credentials so that it can authenticate to systems or network devices. Many of the plugins for Nessus are in a specific language (NASL) and have been imported for use in the open-source vulnerability assessment scanner, OpenVAS. If you are going to check out OpenVAS, I suggest you get the guest VM and load it with ESXi, VMware Workstation/Server, VirtualBox, or VirtualPC. It's also mainly used for credentialed scans. If you are looking for external, black-box vulnerability assessments or on-going vulnerability management -- I suggest that you check out Qualys QualysGuard (QG) or Rapid7 NeXpose. An alternative to Nessus for credentialed scans would be nCircle IP360 (just to complete this market space, although certain US-Gov/DoD sites use Lumension/Harris Stat instead). For web applications, you will need to add a specific sort of scanner, such as HP WebInspect, as well as some open-source tools to determine exploitability (e.g. Wapiti, Grabber, OWASP Zed Attack Proxy, XSSer, sqlmap, etc). This web application security scanner would be in addition to Qulays QG and OpenVAS/Nessus. While many network vulnerability scanners claim to find issues such as SQL injection -- in reality they do not actually do so to any degree of completeness (for more information, see the WIVET.googlecode.com and WAVSEP.googlecode.com scanner benchmarks, or run them for yourself). If you are looking for penetration-testing, this cannot be done with a single tool, or even multiple tools. You need strong people with a good track record of experience in penetration-testing. I have seen a few shops run some free tools (e.g. Cain Abel) along with some commercial tools (e.g. Paterva Maltego, Metasploit Pro, Core Impact, and Burp Suite Professional), with some added open-source tools (e.g. BackTrack 5 and the Social Engineering Toolkit). WiFi penetration-testing is often done with two USB Alfa Networks cards and a guest VM, such as Immunity Security's SILICA. However, depending on your industry vertical and/or specific requirements -- you'll want a custom pen-test that will involve strategy consulting and threat-modeling beforehand. I don't recommend trying to do this on your own. If you do want to attempt pen-testing on your own, I recommend the BlackHat conference official training for Maltego and Burp Suite Professional, in addition to deep technical knowledge of all of the modules and features available in BackTrack and the Metasploit Framework (the new NoStach Press book on Metasploit -- and the less useful but handy Packt Publishing book on BackTrack Penetration Testing -- would be a good start). Cheers, Andre
Re: best practices for management nets in IPv6
On Tue, Jul 12, 2011 at 6:31 PM, Tom Ammon tom.am...@utah.edu wrote: Hi All, We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? What if you apply to a /48 block as end-user because the management network is not part of your ISP-related /32 or larger block ? What if you happen to get that /48 and never announce it to the DFZ ? Then your attack surface gets very small (but still exists, you'll need some ACLs here and there, notably your customers having default-routes to your core). Rubens
Re: best practices for management nets in IPv6
On Jul 12, 2011 2:33 PM, Tom Ammon tom.am...@utah.edu wrote: Hi All, We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? ACL are prone to typos and inconsistent deployment. If the security policy is that a give interface must not talk to the internet, ULA is a good choice as part of a multi-layer security strategy Cb Tom - Tom Ammon Network Engineer M: (801)674-9273 tom.am...@utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 11, 2011, at 7:19 PM, Jeff Wheeler wrote: Again, this is only hard to understand (or accept) if you don't know how your routers work. * why do you think there is an ARP and ND table? * why do you think there are policers to protect the CPU from excessive ARP/ND punts or traffic? * do you even know the limit of your boxes' ARP / ND tables? Do you realize that limit is a tiny fraction of one /64? * do you understand what happens when your ARP/ND policers are reached? * did you think about the impact on neighboring routers and protocol next-hops, not just servers? * did you every try to deploy a /16 on a flat LAN with a lot of hosts and see what happens? Doesn't work too well. A v6 /64 is 281 trillion times bigger than a v4 /16. There's no big leap of logic here as to why one rogue machine could break your LAN. FYI, in case you're interested in these topics, the IETF working group ARMD was chartered to explore address resolution scale. I'm one of the co-chairs. It's in the Operations Area, and we'd love to have more operators involved - if you're willing to contribute, your input will help set the direction. (If operators don't contribute, it will be just another vendor-led circle... well, you know the score.) For details please see http://tools.ietf.org/wg/armd/charters. Cheers, -Benson
in defense of lisp (was: Anybody can participate in the IETF)
W.R.T. to LISP, in defense of the IETF or the IRTF, i do not believe the IETF has told the world that LISP is the best fit for the Internet or solves any specific problem well. The IETF has never said the Internet Architecture is going to LISP, and it likely will not / cannot. My expectation is that LISP will go away as quickly as it came. i will not dispute this, not my point. but i have to respect dino and the lisp fanboys (and, yes, they are all boys) for actually *doing* something after 30 years of loc/id blah blah blah (as did hip). putting their, well dino's, code where their mouths were and going way out on a limb. i am *not* saying i would run it in an operational network. but maz-san and i were happy to help the experiment by dropping the first asian node in a test rack on the public net. randy
Re: best practices for management nets in IPv6
Public IPs. At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS.
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel Jaeggli write s: On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: =20 On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: =20 On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net = wrote: Leo, =20 Maybe we can fix this by: =20 a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing = working groups =20 To some degree, we already do this in the IETF OPS area, but judging = by your comments, we don't do it nearly enough. =20 Comments? =20 =20 There may be an OPS area, but it is not listened to. =20 Witness the latest debacle with the attempt at trying to make 6to4 = historic. =20 Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) =20 Those are all REALLY bad ideas. Speaking as an operator, the best = thing you can do to alleviate the problems with 6to4 is operate more, not less = 6to4 relays. Unless of course the large providers get their shared transition space = in which case all 6to4 behind it will break in a really ugly way, pretty = much exactly like in the mobile operator in question.=20 And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or adding router reachability tests have addressed this issue? The goal of 6to4 to historic was not to encourage the outcome described, = it was to take having 6to4 as a default method of any kind off the table = going into the future. If mature adults want to use it great, but = conformance tests shouldn't require it, CPE shouldn't it on just because = what they think they have a is a public IP with not filtering and hosts = shouldn't use it unless told to do so.. But that is *not* what the draft did. Making the protocol historic did LOTS more than that. I think there was universal consensus that 6to4 should be off by default. There was this nuke 6to4 from orbit attitude which did nothing to help with already deployed/shipped boxes. 6to4 historic is actually harmful for dealing with the existing problems as it tells vendors not to include 6to4 support in future products which means operators won't have boxes with fixes to other problems to alleviate the problems cause but the currently deployed customer boxes. What would have been much better would have been to encourage CPE vendors to release images which address some of the known issues. Just adding a check box saying enable 6to4 and for ISP to send out email to say check your router vendor web site for fixed images. The better fix would be to get them to also add support for draft-andrews-v6ops-6to4-router-option-02.txt which greys out the checkbox when 0.0.0.0 is sent as a response to the option. Remember operators are in the position to alleviate lots of the 6to4 issues themselves. Blocking over IPv4 transport is just silly. It's just as likely = that your record is destined for an end-host that has native IPv6 = connectivity with an intermediate resolver that desn't have IPv6 as it is that = you're sending that to a 6to4 host. Further, there's no reason to believe the 6to4 host won't attempt to resolve via IPv6, so, it doesn't really = help anyway. =20 Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have = thumb wrestle these people who don't actually have any skin in the game. =20 I agree, but, it's not hard to run 6to4 relays and running them does = much more to alleviate the problems with 6to4 than anything you proposed above. Indeed, what you proposed above will likely create more = customer issues rather than reduce them. =20 Owen =20 Cameron =20 =20 Ron =20 =20 -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = broken?) =20 In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, = Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing = lists and participate there, just like a couple of folks from NANOG are = already doing. =20 The way the IETF and the operator community interact is badly = broken. =20 The IETF does not want operators in many steps of the process. If = you try to bring up operational concerns in early protocol development = for example you'll often get a we'll look at that later response, = which in many cases is right. Sometimes you just have to play with = something before you worry about the operational details. It also does
Re: NANOG List Update - Moving Forward
On Tue, Jul 12, 2011 at 11:25 AM, -Hammer- bhmc...@gmail.com wrote: The tolerance of some of you out there is amazing. You must be PS3 users crying because your free game network is down. Maybe we can get a PS3net users had a right to cry.. because their 'free' game network is not really free, and they bought a nice console that became a brick for indefinite amounts of time Be patient people. Maybe a little appreciation to these experts wouldn't hurt you either. Patience is gold, but operating or migrating a listserv is not rocket science, and it cuts both ways. Only a certain amount of patience is warranted for any particular situation, and it appears posters have the warranted amount of tolerance. For now I am appreciative of Robert Bonomi and Brielle Bruns for identifying issues. I'll be happy to express appreciation, as soon as the experts get it done and get it right; right now I'm just keeping my fingers crossed and hoping to hear the news that the issues are addressed and everything's perfect. In the mean time; I am glad that the deficiencies witnessed are being reported. And hope the experts are learning, and at least taking the reports seriously, esp. regards to non-member posting, spam, undisclosed-recipients mess, and header issues/ oddball bulk_mailer identification... NANOG as an operators list should not itself become an example of poor operator practice; or poor planning/change management; that would be an embarassment. -Hammer- -- -JH
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote: On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote: Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? There may be an OPS area, but it is not listened to. Witness the latest debacle with the attempt at trying to make 6to4 historic. Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) Those are all REALLY bad ideas. Speaking as an operator, the best thing you can do to alleviate the problems with 6to4 is operate more, not less 6to4 relays. Unless of course the large providers get their shared transition space in which case all 6to4 behind it will break in a really ugly way, pretty much exactly like in the mobile operator in question. Actually, if those same providers run 6to4 gateways/routers on their networks in that shared transition space with public IPv6 addresses on the exterior, it would not break at all. As I said, the resolution to the 6to4 problems described is to run MORE, not less 6to4 gateways. The goal of 6to4 to historic was not to encourage the outcome described, it was to take having 6to4 as a default method of any kind off the table going into the future. If mature adults want to use it great, but conformance tests shouldn't require it, CPE shouldn't it on just because what they think they have a is a public IP with not filtering and hosts shouldn't use it unless told to do so.. I have no problem with saying 6to4 should not be enabled by default. However, that doesn't change the fact that the best way to resolve things given current shipping software and hardware is to deploy 6to4 gateways in the appropriate places. Owen Blocking over IPv4 transport is just silly. It's just as likely that your record is destined for an end-host that has native IPv6 connectivity with an intermediate resolver that desn't have IPv6 as it is that you're sending that to a 6to4 host. Further, there's no reason to believe the 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help anyway. Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have thumb wrestle these people who don't actually have any skin in the game. I agree, but, it's not hard to run 6to4 relays and running them does much more to alleviate the problems with 6to4 than anything you proposed above. Indeed, what you proposed above will likely create more customer issues rather than reduce them. Owen Cameron Ron -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a we'll look at that later response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles.
Re: NANOG List Update - Moving Forward
- Original Message - On Jul 12, 2011, at 12:23 PM, Brielle Bruns wrote: Looks like parts of the received like are still there, though butchered and mashed in (most likely in a non-RFC compliant manner) with the one added by 'bulk_maler v1.13' (great name for the mailer, btw, sets off my spammy sense something fierce). You seem to be new here. bulk_mailer was something used back in the day to workaround limitations in sendmail for those people operating majordomo (and those using smail etc). it broke the chunks into something that sendmail would then allocate multiple processes to. most other mail subsystems can handle the multiple-rcpts in different manners. while it may 'feel' spammy to you, it's certainly not. a simple google of majordomo and bulk_mailer should give you a good idea of what's going on. there were a lot of other mail systems that served to help integrate and interoperate back in the day, including qmailer, smail, etc that all attempted to replace sendmail, including providing the uucp interaction necessary for those behind dialup. either way, please try to keep the feedback off-list for now as we undergo this transition. It's hard to move a large list like this without trouble. I've been party to many such list moves in the past and they usually have all sorts of trouble. adm...@nanog.org is the right place for your feedback right now. - Jared Feeling a bit of Déjà vu as I deployed bulk_mailer for the NANOG list back in November of 1996. It used sendmail+bulk_mailer for delivery until March of 1999 when we transitioned to Postfix. It was transitioned again in April 2008 to Exim and Mailman. Unfortunately, my memory is a bit hazy on whether there were any specific issues with bulk_mailer that caused the switch to Postfix. My main concern with the bulk_mailer code is that it hasn't been touched in over a decade -- ftp://cs.utk.edu/pub/moore/bulk_mailer I've have some concerns with AMS based on my experience with the IETF mailing list. It has had ongoing issues with out-of-sequence delivery. Based on the Received headers, it's seems pretty clear the re-ordering is occurring internal to the AMS servers. It appears they may be trying something different with the NANOG list as the IETF list does not employ bulk_mailer. -Larry
NANOG Updates - Important
Thank you for your patience as we moved forward with our NANOG transition. We are excited to announce the opening of NANOG 53 registration. You will notice a new format and the need to create a user id and password to complete your registration. We are confident you will find the new system very intuitive and helpful as we continue to move forward. As always, there are opportunities to improve. Feel free to send any questions, suggestions, or concerns to nanog-supp...@nanog.org With respect to NANOG list services. The NANOG Board has decided not to move forward with the mail list and archive transition from Mailman to ARO at this time. For the time being we are operating on our existing hardware in Ann Arbor, MI. We will however, be preparing for a move to an alternate site. As we confirm further details we will be sure to send them along to you. Again, if you have any questions, suggestions, or concerns please send them to nanog-supp...@nanog.org. Sincerely, Michael K. Smith NANOG CC Chair
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 12, 2011 6:42 PM, Mark Andrews ma...@isc.org wrote:
In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel Jaeggli
write
s:
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
=20
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
=20
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net
=
wrote:
Leo,
=20
Maybe we can fix this by:
=20
a) bringing together larger groups of clueful operators in the IETF
b) deciding which issues interest them
c) showing up and being vocal as a group in protocol developing =
working groups
=20
To some degree, we already do this in the IETF OPS area, but judging
=
by your comments, we don't do it nearly enough.
=20
Comments?
=20
=20
There may be an OPS area, but it is not listened to.
=20
Witness the latest debacle with the attempt at trying to make 6to4 =
historic.
=20
Various non-practicing entities were able to derail what network
operators largely supported. Since the IETF failed to make progress
operators will do other things to stop 6to4 ( i have heard no
over IPv4 transport, blackhole 6to4 anycast, decom relay routers...)
=20
Those are all REALLY bad ideas. Speaking as an operator, the best =
thing you
can do to alleviate the problems with 6to4 is operate more, not less =
6to4
relays.
Unless of course the large providers get their shared transition space =
in which case all 6to4 behind it will break in a really ugly way, pretty
=
much exactly like in the mobile operator in question.=20
And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or
adding router reachability tests have addressed this issue?
The goal of 6to4 to historic was not to encourage the outcome described,
=
it was to take having 6to4 as a default method of any kind off the table
=
going into the future. If mature adults want to use it great, but =
conformance tests shouldn't require it, CPE shouldn't it on just because
=
what they think they have a is a public IP with not filtering and hosts
=
shouldn't use it unless told to do so..
But that is *not* what the draft did. Making the protocol historic
did LOTS more than that. I think there was universal consensus
that 6to4 should be off by default.
There was this nuke 6to4 from orbit attitude which did nothing to
help with already deployed/shipped boxes. 6to4 historic is actually
harmful for dealing with the existing problems as it tells vendors
not to include 6to4 support in future products which means operators
won't have boxes with fixes to other problems to alleviate the
problems cause but the currently deployed customer boxes.
What would have been much better would have been to encourage CPE
vendors to release images which address some of the known issues.
Just adding a check box saying enable 6to4 and for ISP to send
out email to say check your router vendor web site for fixed
images. The better fix would be to get them to also add support
for draft-andrews-v6ops-6to4-router-option-02.txt which greys out
the checkbox when 0.0.0.0 is sent as a response to the option.
Remember operators are in the position to alleviate lots of the
6to4 issues themselves.
But they will not. If there is not a revenue forecast, there is no project.
That said, CGN is moving forward as a keep the lights on initiative as
is real native v6.
I don't care to rehash this yet again with no progress.
Cb.
Blocking over IPv4 transport is just silly. It's just as likely =
that your
record is destined for an end-host that has native IPv6 =
connectivity
with an intermediate resolver that desn't have IPv6 as it is that =
you're
sending that to a 6to4 host. Further, there's no reason to believe the
6to4 host won't attempt to resolve via IPv6, so, it doesn't really =
help
anyway.
=20
Real network operators have a relatively low BS threshold, they have
customers to support and businesses to run, and they don't have =
thumb
wrestle these people who don't actually have any skin in the game.
=20
I agree, but, it's not hard to run 6to4 relays and running them does =
much
more to alleviate the problems with 6to4 than anything you proposed
above. Indeed, what you proposed above will likely create more =
customer
issues rather than reduce them.
=20
Owen
=20
Cameron
=20
=20
Ron
=20
=20
-Original Message-
From: Leo Bicknell [mailto:bickn...@ufp.org]
Sent: Monday, July 11, 2011 3:35 PM
To: nanog@nanog.org
Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 =
broken?)
=20
In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, =
Jeroen Massar wrote:
Eh ANYBODY, including you, can sign up to the IETF mailing =
lists
and participate there, just like a couple of folks from NANOG are =
already doing.
=20
The way the IETF and the
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 12, 2011, at 7:20 PM, Owen DeLong wrote: On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote: On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote: Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? There may be an OPS area, but it is not listened to. Witness the latest debacle with the attempt at trying to make 6to4 historic. Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) Those are all REALLY bad ideas. Speaking as an operator, the best thing you can do to alleviate the problems with 6to4 is operate more, not less 6to4 relays. Unless of course the large providers get their shared transition space in which case all 6to4 behind it will break in a really ugly way, pretty much exactly like in the mobile operator in question. Actually, if those same providers run 6to4 gateways/routers on their networks in that shared transition space with public IPv6 addresses on the exterior, it would not break at all. arin 2011-5 specfically cites numbering cpe in space as the justification for deployment. the cpe therefore have to be natted and you are implying that you'll be natting the 6to4, overall I'd put that in the less desirable category as far as violating expectations go... As I said, the resolution to the 6to4 problems described is to run MORE, not less 6to4 gateways. Are you advocating draft-kuarsingh-v6ops-6to4-provider-managed-tunnel? http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 The goal of 6to4 to historic was not to encourage the outcome described, it was to take having 6to4 as a default method of any kind off the table going into the future. If mature adults want to use it great, but conformance tests shouldn't require it, CPE shouldn't it on just because what they think they have a is a public IP with not filtering and hosts shouldn't use it unless told to do so.. I have no problem with saying 6to4 should not be enabled by default. However, that doesn't change the fact that the best way to resolve things given current shipping software and hardware is to deploy 6to4 gateways in the appropriate places. and we have http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-02 The fact of the matter is more 6to4 relays is only an anodyne as is rejiggering the address selection priority, the pain may go down it won't go away. Owen Blocking over IPv4 transport is just silly. It's just as likely that your record is destined for an end-host that has native IPv6 connectivity with an intermediate resolver that desn't have IPv6 as it is that you're sending that to a 6to4 host. Further, there's no reason to believe the 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help anyway. Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have thumb wrestle these people who don't actually have any skin in the game. I agree, but, it's not hard to run 6to4 relays and running them does much more to alleviate the problems with 6to4 than anything you proposed above. Indeed, what you proposed above will likely create more customer issues rather than reduce them. Owen Cameron Ron -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog@nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: Eh ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a we'll look at that later response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles.
Re: NANOG List Update - Moving Forward
On Jul 12, 2011, at 8:46 PM, Larry J. Blunk wrote: I've have some concerns with AMS based on my experience with the IETF mailing list. It has had ongoing issues with out-of-sequence delivery. Based on the Received headers, it's seems pretty clear the re-ordering is occurring internal to the AMS servers. It appears they may be trying something different with the NANOG list as the IETF list does not employ bulk_mailer. ietf.org is mailman and postfix. -Larry
Re: NANOG List Update - Moving Forward
- Original Message - On Jul 12, 2011, at 8:46 PM, Larry J. Blunk wrote: I've have some concerns with AMS based on my experience with the IETF mailing list. It has had ongoing issues with out-of-sequence delivery. Based on the Received headers, it's seems pretty clear the re-ordering is occurring internal to the AMS servers. It appears they may be trying something different with the NANOG list as the IETF list does not employ bulk_mailer. ietf.org is mailman and postfix. Right, should have mentioned that. Here's the Received headers from a message yesterday that apparently had a 23 hour delay internal to ietfa.amsl.org. You can also see it is out of sequence in the IETF mailing list archives. There are some other recent emails that were sent on July 8th and did not get delivered until Juth 11th. -Larry Received: from mail.ietf.org ([64.170.98.30]) by sfpop-ironport04.merit.edu with ESMTP; 12 Jul 2011 11:06:29 -0400 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7027F21F8CB4; Tue, 12 Jul 2011 08:06:29 -0700 (PDT) X-Original-To: i...@ietfa.amsl.com Delivered-To: i...@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D7D21F8E58 for i...@ietfa.amsl.com; Mon, 11 Jul 2011 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAHKv2903pQw for i...@ietfa.amsl.com; Mon, 11 Jul 2011 09:01:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E321F8E4F for i...@ietf.org; Mon, 11 Jul 2011 09:01:26 -0700 (PDT) Received: from dn3-227.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6BG1O4H054438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jul 2011 11:01:25 -0500 (CDT) (envelope-from b...@nostrum.com) Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22 Mime-Version: 1.0 (Apple Message framework v1084) From: Ben Campbell b...@nostrum.com In-Reply-To: ae447de4-cd85-4386-9c97-2008524d2...@nist.gov Date: Mon, 11 Jul 2011 11:01:23 -0500 Message-Id: 5bb77043-1674-4fd6-87cb-17ddc1cee...@nostrum.com
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Jul 12, 2011, at 6:41 PM, Mark Andrews wrote: In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel Jaeggli write s: On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: =20 On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: =20 On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net = wrote: Leo, =20 Maybe we can fix this by: =20 a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing = working groups =20 To some degree, we already do this in the IETF OPS area, but judging = by your comments, we don't do it nearly enough. =20 Comments? =20 =20 There may be an OPS area, but it is not listened to. =20 Witness the latest debacle with the attempt at trying to make 6to4 = historic. =20 Various non-practicing entities were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) =20 Those are all REALLY bad ideas. Speaking as an operator, the best = thing you can do to alleviate the problems with 6to4 is operate more, not less = 6to4 relays. Unless of course the large providers get their shared transition space = in which case all 6to4 behind it will break in a really ugly way, pretty = much exactly like in the mobile operator in question.=20 And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or adding router reachability tests have addressed this issue? Neither of these approaches address existing cpe, and shared transtion space is justified on the basis of existing cpe... We go into this with the internet we have not the one that we would like to have the later takes time. The goal of 6to4 to historic was not to encourage the outcome described, = it was to take having 6to4 as a default method of any kind off the table = going into the future. If mature adults want to use it great, but = conformance tests shouldn't require it, CPE shouldn't it on just because = what they think they have a is a public IP with not filtering and hosts = shouldn't use it unless told to do so.. But that is *not* what the draft did. Making the protocol historic did LOTS more than that. I think there was universal consensus that 6to4 should be off by default. And that'll take some time while particularly for the CPE to age out. There was this nuke 6to4 from orbit attitude which did nothing to help with already deployed/shipped boxes. 6to4 historic is actually harmful for dealing with the existing problems as it tells vendors not to include 6to4 support in future products which means operators won't have boxes with fixes to other problems to alleviate the problems cause but the currently deployed customer boxes. The interpretation of attitude is a matter of taste. When that authors of 3056 and 3068 come down in support of or opposed to the same draft there clearly some debate. If we focus on what really would be in the best interests of the end user, it is a decline to zero in the unintentional use of 6to4 in cpe and operating systems. it is the removal of 6to4 from requirements where it presently exists, and it is the continued support of relays to support legacy devices. It is really hard to justify the expansion and deployment of new relays when in fact tunneled traffic can be observed to be on the decline (possibly because devices particularly hosts that do receive regular updates receive tweaks to their address selection algorithm). http://asert.arbornetworks.com/2011/04/six-months-six-providers-and-ipv6/ What would have been much better would have been to encourage CPE vendors to release images which address some of the known issues. Just adding a check box saying enable 6to4 and for ISP to send out email to say check your router vendor web site for fixed images. The better fix would be to get them to also add support for draft-andrews-v6ops-6to4-router-option-02.txt which greys out the checkbox when 0.0.0.0 is sent as a response to the option. Remember operators are in the position to alleviate lots of the 6to4 issues themselves. Blocking over IPv4 transport is just silly. It's just as likely = that your record is destined for an end-host that has native IPv6 = connectivity with an intermediate resolver that desn't have IPv6 as it is that = you're sending that to a 6to4 host. Further, there's no reason to believe the 6to4 host won't attempt to resolve via IPv6, so, it doesn't really = help anyway. =20 Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have = thumb wrestle these people who don't actually have any skin in the game. =20 I agree, but, it's not hard to run 6to4 relays and
