From jjackson at aninetworks.net Tue Dec 1 00:06:45 2009 From: jjackson at aninetworks.net (Joseph Jackson) Date: Mon, 30 Nov 2009 16:06:45 -0800 Subject: DNS query analyzer Message-ID: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Hey List! Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? Thanks! Joseph From nanog at daork.net Tue Dec 1 01:12:13 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 1 Dec 2009 14:12:13 +1300 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: On 1/12/2009, at 1:06 PM, Joseph Jackson wrote: > Hey List! > > Anyone know of a tool that can take a pcap file from wireshark that > was used to collect dns queries and then spit out statistics about > the queries such as RTT and timeouts? Not off the top of my head, but, you could use wireshark's Lua extension system to write a plugin to do this for you right within wireshark. The wireshark/Lua stuff is quite powerful (though not super super fast), it's a really useful tool to have on hand. -- Nathan Ward From sfouant at shortestpathfirst.net Tue Dec 1 02:48:53 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 30 Nov 2009 21:48:53 -0500 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <000701ca7230$d2467530$76d35f90$@net> > -----Original Message----- > From: Joseph Jackson [mailto:jjackson at aninetworks.net] > Sent: Monday, November 30, 2009 7:07 PM > > Anyone know of a tool that can take a pcap file from wireshark that was > used to collect dns queries and then spit out statistics about the > queries such as RTT and timeouts? It just so happens there is a tool aptly named DNS Analyzer by NLnet Labs. I used it a while back but if I recall you could feed it a pcap and it could spit out all kinds of useful statistical data. I don't think it's being actively maintained at the moment but you should be able to find it on the NLnet Labs site - http://www.nlnetlabs.nl/projects/dns-analyzer/ HTHs. Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From raymond at prolocation.net Tue Dec 1 02:54:03 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 1 Dec 2009 03:54:03 +0100 (CET) Subject: DNS query analyzer In-Reply-To: <000701ca7230$d2467530$76d35f90$@net> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> <000701ca7230$d2467530$76d35f90$@net> Message-ID: Hi! >> Anyone know of a tool that can take a pcap file from wireshark that was >> used to collect dns queries and then spit out statistics about the >> queries such as RTT and timeouts? > It just so happens there is a tool aptly named DNS Analyzer by NLnet Labs. > I used it a while back but if I recall you could feed it a pcap and it could > spit out all kinds of useful statistical data. > > I don't think it's being actively maintained at the moment but you should be > able to find it on the NLnet Labs site - > http://www.nlnetlabs.nl/projects/dns-analyzer/ I very recently asked the maintainers of that package if its still under development but i heard if was unfortunately dropped. Bye, Raymond. From luke.marrott at gmail.com Tue Dec 1 02:57:58 2009 From: luke.marrott at gmail.com (Luke Marrott) Date: Mon, 30 Nov 2009 19:57:58 -0700 Subject: FTTH Active vs Passive Message-ID: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> I'm wondering what everyones thoughts are in regards to FTTH using Active Ethernet or Passive. I work for a FTTH Provider that has done Active Ethernet on a few networks so I'm always biased in discussions, but I don't know anyone with experience in PON. I've read before that almost all PON technology is proprietary, locking you into a specific hardware vendor. However I think this is changing or has already changed, opening PON up for interoperability. Can anyone confirm this? Thanks in advance. :Luke Marrott From sfouant at shortestpathfirst.net Tue Dec 1 03:02:01 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 30 Nov 2009 22:02:01 -0500 Subject: DNS query analyzer In-Reply-To: References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> <000701ca7230$d2467530$76d35f90$@net> Message-ID: <000801ca7232$a8ca4540$fa5ecfc0$@net> > -----Original Message----- > From: Raymond Dijkxhoorn [mailto:raymond at prolocation.net] > Sent: Monday, November 30, 2009 9:54 PM > > > I don't think it's being actively maintained at the moment but you > should be > > able to find it on the NLnet Labs site - > > http://www.nlnetlabs.nl/projects/dns-analyzer/ > > I very recently asked the maintainers of that package if its still > under > development but i heard if was unfortunately dropped. It would be nice if we could convince them to release the source code into the public domain. I'm sure there are a few people who would find it highly useful and would work on it to add to its utility. Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From jay at west.net Tue Dec 1 03:19:48 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 30 Nov 2009 19:19:48 -0800 Subject: DNS query analyzer In-Reply-To: <000801ca7232$a8ca4540$fa5ecfc0$@net> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> <000701ca7230$d2467530$76d35f90$@net> <000801ca7232$a8ca4540$fa5ecfc0$@net> Message-ID: <4B148B54.3010309@west.net> Stefan Fouant wrote: >> -----Original Message----- >> From: Raymond Dijkxhoorn [mailto:raymond at prolocation.net] >>> I don't think it's being actively maintained at the moment but you >> should be >>> able to find it on the NLnet Labs site - >>> http://www.nlnetlabs.nl/projects/dns-analyzer/ >> I very recently asked the maintainers of that package if its still >> under >> development but i heard if was unfortunately dropped. > > It would be nice if we could convince them to release the source code into > the public domain. I'm sure there are a few people who would find it highly > useful and would work on it to add to its utility. The source (versions 0.2.0 and 0.3.0) is available at the above URL and there is a GPL license in the tarball. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jtk at cymru.com Tue Dec 1 04:11:05 2009 From: jtk at cymru.com (John Kristoff) Date: Mon, 30 Nov 2009 22:11:05 -0600 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <20091130221105.649dfe53@t61p> On Mon, 30 Nov 2009 16:06:45 -0800 Joseph Jackson wrote: > Anyone know of a tool that can take a pcap file from wireshark that > was used to collect dns queries and then spit out statistics about > the queries such as RTT and timeouts? Nothing with RTT and timeouts in this, but it could probably be adapted with an additional, rudimentary subroutine to try summarizing that too: If you or no one else comes up with something or modifies this to do it, give me a holler and I'll whip something up for you. As is, it'll count DNS messages, header flags and give a top X list of qnames seen. It uses the somewhat limited NetPacket modules, but it would be easy to either switch wholesale to the Net::Packet modules or pull in just those needed (e.g. VLAN and IPv6 support). It is what it is, hopefully its of use. John From meekjt at gmail.com Tue Dec 1 05:05:38 2009 From: meekjt at gmail.com (Jon Meek) Date: Tue, 1 Dec 2009 00:05:38 -0500 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: I have a "DNSaudit" program that takes libpcap (wireshark/tcpdump) files. Originally its purpose was to identify AnswersWithoutQuestions, and QuestionsWithoutAnswers when we were having some routing issues causing answers to return via a different ISP. Later I added statistics for response time by server. I suggest trying the other programs mentioned first, I am the only user of my program... Jon On Mon, Nov 30, 2009 at 7:06 PM, Joseph Jackson wrote: > Hey List! > > Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? > > > Thanks! > > Joseph From regnauld at nsrc.org Tue Dec 1 08:45:44 2009 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 1 Dec 2009 09:45:44 +0100 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <20091201084540.GA49994@macbook.catpipe.net> Joseph Jackson (jjackson) writes: > Hey List! > > Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? I don't know if DSC does this, but check it out: http://dns.measurement-factory.com/tools/dsc/ Cheers, Phil From dot at dotat.at Tue Dec 1 15:58:17 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 1 Dec 2009 15:58:17 +0000 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: On Mon, 30 Nov 2009, Joseph Jackson wrote: > > Anyone know of a tool that can take a pcap file from wireshark that was > used to collect dns queries and then spit out statistics about the > queries such as RTT and timeouts? I don't know if it'll do exactly what you want, but have a look at https://www.dns-oarc.net/tools/dnscap Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From justin at justinshore.com Tue Dec 1 16:43:41 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 01 Dec 2009 10:43:41 -0600 Subject: FTTH Active vs Passive In-Reply-To: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> Message-ID: <4B1547BD.6050004@justinshore.com> Luke Marrott wrote: > I'm wondering what everyones thoughts are in regards to FTTH using Active > Ethernet or Passive. I work for a FTTH Provider that has done Active > Ethernet on a few networks so I'm always biased in discussions, but I don't > know anyone with experience in PON. Active is the way to go. Passive is merely a stepping stone on the way to active. Passive only makes sense (in some cases) if you are 1) fiber poor and 2) not doing a greenfield deployment. If you have the fiber to work with or if you are building a FTTH plant from scratch go with active. The only real proponents of PONs are the RBOCs who are exceedingly cheap, slow to react, and completely unable to think ahead (ie, putting in an abundance of fiber for future use instead of just enough to get by) and some MSOs who don't dread and loathe shared network mediums like CATV and PON (whereas those from a networking background would never ever pick such a technology). > I've read before that almost all PON technology is proprietary, locking you > into a specific hardware vendor. However I think this is changing or has > already changed, opening PON up for interoperability. Can anyone confirm > this? There are several actual PON standards out there: http://en.wikipedia.org/wiki/Passive_optical_network Few vendors will ever admit that they interop with another vendor's gear though. They don't want you to buy their optical switches (which have a small markup) and someone else's ONTs (which typically have a much greater markup). In some cases even though that adhere to the standards to a point they diverge and go proprietary for things like integrating voice or video into the system. That could cause management and/or support issues for you at some point in the life of the product. Personally I'd go with a vendor that offers the complete solution instead of piecing one together. PON has some popularity in MDUs. The splits are easy to manage because they're all in one location. Bandwidth needs are typically on the low end in MDUs due to a lack of businesses (bandwidth being a severe future-proofing problem for PON). PON's biggest limitations for us is the distance limitations. We're deploying FTTH in the rural countryside, not in a dense residential neighborhood. PON has very specific distance limitations for each split and cumulative across all splits that make rural deployments extremely difficult. The price difference between Active and PON is negligible at this point and in many cases cheaper for active. Go with active for FTTH. You won't regret it. Justin From dwhite at olp.net Tue Dec 1 17:14:35 2009 From: dwhite at olp.net (Dan White) Date: Tue, 1 Dec 2009 11:14:35 -0600 Subject: FTTH Active vs Passive In-Reply-To: <4B1547BD.6050004@justinshore.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> Message-ID: <20091201171435.GH4453@dan.olp.net> On 01/12/09?10:43?-0600, Justin Shore wrote: > Active is the way to go. Passive is merely a stepping stone on the way > to active. Passive only makes sense (in some cases) if you are 1) fiber > poor and 2) not doing a greenfield deployment. If you have the fiber to > work with or if you are building a FTTH plant from scratch go with > active. The only real proponents of PONs are the RBOCs who are > exceedingly cheap, slow to react, and completely unable to think ahead > (ie, putting in an abundance of fiber for future use instead of just > enough to get by) and some MSOs who don't dread and loathe shared > network mediums like CATV and PON (whereas those from a networking > background would never ever pick such a technology). > > Few vendors will ever admit that they interop with another vendor's gear > though. They don't want you to buy their optical switches (which have a > small markup) and someone else's ONTs (which typically have a much > greater markup). In some cases even though that adhere to the standards > to a point they diverge and go proprietary for things like integrating > voice or video into the system. That could cause management and/or > support issues for you at some point in the life of the product. > Personally I'd go with a vendor that offers the complete solution > instead of piecing one together. > > PON has some popularity in MDUs. The splits are easy to manage because > they're all in one location. Bandwidth needs are typically on the low > end in MDUs due to a lack of businesses (bandwidth being a severe > future-proofing problem for PON). PON's biggest limitations for us is > the distance limitations. We're deploying FTTH in the rural > countryside, not in a dense residential neighborhood. PON has very > specific distance limitations for each split and cumulative across all > splits that make rural deployments extremely difficult. The price > difference between Active and PON is negligible at this point and in > many cases cheaper for active. Go with active for FTTH. You won't > regret it. All valid points. Deploying a strand to each customer from the CO/Cabinet is a good way to future proof your plant. However, there are some advantages to GPON - particularly if you're deploying high bandwidth video services. PON ONTs share 2.4Gb/s of bandwidth downstream, which means you can support more than a gig of video on each PON, if deploying in dense mode. Another big advantage is in CO equipment. A 4-PON blade in a cabinet is going to support on the order of 256 ONTs. -- Dan White From herrin-nanog at dirtside.com Tue Dec 1 17:33:03 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 1 Dec 2009 12:33:03 -0500 Subject: FTTH Active vs Passive In-Reply-To: <4B1547BD.6050004@justinshore.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> Message-ID: <3c3e3fca0912010933y14aadf06ne9c38f57832987bc@mail.gmail.com> On Tue, Dec 1, 2009 at 11:43 AM, Justin Shore wrote: > Luke Marrott wrote: >> I'm wondering what everyones thoughts are in regards to FTTH using Active >> Ethernet or Passive. I work for a FTTH Provider that has done Active >> Ethernet on a few networks so I'm always biased in discussions, but I >> don't >> know anyone with experience in PON. > > Active is the way to go. ?Passive is merely a stepping stone on the way to > active. ?Passive only makes sense (in some cases) if you are 1) fiber poor > and 2) not doing a greenfield deployment. ?If you have the fiber to work > with or if you are building a FTTH plant from scratch go with active. ?The > only real proponents of PONs are the RBOCs who are exceedingly cheap, slow > to react, and completely unable to think ahead (ie, putting in an abundance > of fiber for future use instead of just enough to get by) and some MSOs who > don't dread and loathe shared network mediums like CATV and PON (whereas > those from a networking background would never ever pick such a technology). Justin, The suburban area where I live, mostly detached homes, has a service density of around 1500 to 2000 residences per square mile. Practically speaking, one or two dedicated fibers per residence at that density means you're not going to get a 5 mile radius from your powered equipment. Pi * 5^2 * 2000 residences * 2 strands per residence = 300,000 strands of fiber. So you're going to deploy powered equipment to one hell of a lot of non-customer field locations. Since most of those locations are not carefully conditioned computer rooms, you're going to pay more for ruggedized equipment too. In that scenario, PON cuts the number of field locations in which you have to maintain non-CPE powered equipment by an order of magnitude or more. Perhaps even to zero. This improves system reliability and yields a rather substantial savings on maintenance cost over time. Pi * 5^2 * 2000 residences * 1 strand / 16 residences per strand = 9,800 strands of fiber, a much more manageable number. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From swmike at swm.pp.se Tue Dec 1 17:59:46 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 1 Dec 2009 18:59:46 +0100 (CET) Subject: FTTH Active vs Passive In-Reply-To: <20091201171435.GH4453@dan.olp.net> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> Message-ID: On Tue, 1 Dec 2009, Dan White wrote: > However, there are some advantages to GPON - particularly if you're > deploying high bandwidth video services. PON ONTs share 2.4Gb/s of > bandwidth downstream, which means you can support more than a gig of video > on each PON, if deploying in dense mode. You don't need to supply more than a gig per household, so active gige (or 100meg) is enough to feed the household with their broadcast video needs. So yes, you will need 10GE to the node and 100/1000 to each household do this this kind of video. PON only makes sense with low take-rates and high per-truckroll costs when I did the business case last time. > Another big advantage is in CO equipment. A 4-PON blade in a cabinet is > going to support on the order of 256 ONTs. But you lose out on the CPEs, at least historically these were much more expensive than the 100FX/TX media converters available in the market. -- Mikael Abrahamsson email: swmike at swm.pp.se From jcdill.lists at gmail.com Tue Dec 1 18:39:20 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 01 Dec 2009 10:39:20 -0800 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> Message-ID: <4B1562D8.1060902@gmail.com> Mikael Abrahamsson wrote: > > You don't need to supply more than a gig per household, "640K ought to be enough for anybody. " (oft mis-attributed to Bill Gates) http://en.wikiquote.org/wiki/Bill_Gates If, 10 years ago (1999) when most internet-connected homes still used dialup, you had suggested that ISPs would be putting in gigabit services to homes, people would have laughed. Yet today, here we are talking about gig feeds. I wonder how much bandwidth homes will be using 10 years from now... jc From bhicks at ots.utsystem.edu Tue Dec 1 18:47:50 2009 From: bhicks at ots.utsystem.edu (Byron Hicks) Date: Tue, 1 Dec 2009 12:47:50 -0600 Subject: FTTH Active vs Passive In-Reply-To: <4B1562D8.1060902@gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> Message-ID: <85c108810912011047x5031e987l353de3f33f672348@mail.gmail.com> 4k video feeds (the new High Def): compressed: 1Gb/s uncompressed: 9Gb/s On Tue, Dec 1, 2009 at 12:39 PM, JC Dill wrote: > Mikael Abrahamsson wrote: >> >> You don't need to supply more than a gig per household, > > "640K ought to be enough for anybody. " ?(oft mis-attributed to Bill Gates) > ?http://en.wikiquote.org/wiki/Bill_Gates > > If, 10 years ago (1999) when most internet-connected homes still used > dialup, you had suggested that ISPs would be putting in gigabit services to > homes, people would have laughed. ?Yet today, here we are talking about gig > feeds. ?I wonder how much bandwidth homes will be using 10 years from now... > > jc > > -- Byron L. Hicks University of Texas System 512-377-9857 AIM: byronhicks From swmike at swm.pp.se Tue Dec 1 18:49:53 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 1 Dec 2009 19:49:53 +0100 (CET) Subject: FTTH Active vs Passive In-Reply-To: <4B1562D8.1060902@gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> Message-ID: On Tue, 1 Dec 2009, JC Dill wrote: > If, 10 years ago (1999) when most internet-connected homes still used > dialup, you had suggested that ISPs would be putting in gigabit services > to homes, people would have laughed. Yet today, here we are talking > about gig feeds. I wonder how much bandwidth homes will be using 10 > years from now... First commercial gige service available to residential here in Sweden was a few years after 2000 (be it only a few houses), I'd say at least 10% of swedish households can buy at least 100/10 service for less than 50USD a month and it's been like that for 5+ years (before that it was 10/10 for the same money). Active ethernet means you upgrade CO and CPE and you can do whatever you need on the fiber strand to that household, whereas PON you need to upgrade everything that shares that passive stretch sharing 64-128 households. Star networks (=active ethernet in the FTTH world) is the way to go, it's superior in the vast majority of use cases. -- Mikael Abrahamsson email: swmike at swm.pp.se From cmadams at hiwaay.net Tue Dec 1 18:58:05 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 1 Dec 2009 12:58:05 -0600 Subject: FTTH Active vs Passive In-Reply-To: <85c108810912011047x5031e987l353de3f33f672348@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> <85c108810912011047x5031e987l353de3f33f672348@mail.gmail.com> Message-ID: <20091201185805.GF1382336@hiwaay.net> Once upon a time, Byron Hicks said: > 4k video feeds (the new High Def): > > compressed: 1Gb/s ?? Current over-the-air HD (at a max of 1080i) is up to 19 megabits per second (and most don't run it that high). Most cable systems compress it more. 4k video is roughly 8 times the pixels than 1080i, but is typically going to be compressed with better algorithms (MPEG4 is roughly half the size of MPEG2), which would mean 4k video (at TV quality) would be around 100 megabits per second. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From michael.holstein at csuohio.edu Tue Dec 1 19:04:42 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 01 Dec 2009 14:04:42 -0500 Subject: FTTH Active vs Passive In-Reply-To: <4B1562D8.1060902@gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> Message-ID: <4B1568CA.10004@csuohio.edu> > I wonder how much bandwidth homes will be using 10 years from now... 100% of it (if you let us). Cheers, Michael Holstein Cleveland State University From bhicks at ots.utsystem.edu Tue Dec 1 19:06:26 2009 From: bhicks at ots.utsystem.edu (Byron Hicks) Date: Tue, 1 Dec 2009 13:06:26 -0600 Subject: FTTH Active vs Passive In-Reply-To: <20091201185805.GF1382336@hiwaay.net> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> <85c108810912011047x5031e987l353de3f33f672348@mail.gmail.com> <20091201185805.GF1382336@hiwaay.net> Message-ID: <85c108810912011106y6a86ac8kfdebd305c773b9c6@mail.gmail.com> These were the numbers presented at an Internet2 meeting about the 4k testing happening between UCSD and UW. I'm not sure what compression algorithm they were using for the test. On Tue, Dec 1, 2009 at 12:58 PM, Chris Adams wrote: > Once upon a time, Byron Hicks said: >> 4k video feeds (the new High Def): >> >> compressed: 1Gb/s > > ?? > > Current over-the-air HD (at a max of 1080i) is up to 19 megabits per > second (and most don't run it that high). ?Most cable systems compress > it more. ?4k video is roughly 8 times the pixels than 1080i, but is > typically going to be compressed with better algorithms (MPEG4 is > roughly half the size of MPEG2), which would mean 4k video (at TV > quality) would be around 100 megabits per second. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > -- Byron L. Hicks University of Texas System 512-377-9857 AIM: byronhicks From deepak at ai.net Tue Dec 1 19:16:52 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 1 Dec 2009 14:16:52 -0500 Subject: FTTH Active vs Passive In-Reply-To: <4B1562D8.1060902@gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> Message-ID: > If, 10 years ago (1999) when most internet-connected homes still used > dialup, you had suggested that ISPs would be putting in gigabit > services > to homes, people would have laughed. Yet today, here we are talking > about gig feeds. I wonder how much bandwidth homes will be using 10 > years from now... > s/be using/have access to/ One could make the argument that when we were doing dial-up over POTS the % utilization vs port speed was higher than today with packet switching to the curb. People have been lamenting the lack of for-profit apps that will actually each up these 100+ mb/s residential pipes (the "killer app"). One could further argue that the talk of gigabit pipes to the home has been ushered in by the cost-effectiveness of gigabit ethernet over SONET or other technologies and this is why we are seeing such a massive increase in the port speeds to customers. As a percentage of pipe available (discounting things like kiddie's using Torrent), I wouldn't be surprised to see that percentage drop. (Residential broadband folks chime in please). Deepak From justin at justinshore.com Tue Dec 1 19:18:01 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 01 Dec 2009 13:18:01 -0600 Subject: FTTH Active vs Passive In-Reply-To: <20091201171435.GH4453@dan.olp.net> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> Message-ID: <4B156BE9.9050803@justinshore.com> Dan White wrote: > All valid points. Deploying a strand to each customer from the CO/Cabinet > is a good way to future proof your plant. > > However, there are some advantages to GPON - particularly if you're > deploying high bandwidth video services. PON ONTs share 2.4Gb/s of > bandwidth downstream, which means you can support more than a gig of video > on each PON, if deploying in dense mode. That's true but I'd hope it wouldn't be needed. A single residence wouldn't get anywhere near needing 1Gbps of video bandwidth. Even with MPEG2 and 50 HD STBs @ 19Mbps that would still leave 50Mbps for Internet. I don't know of anyone needing that much BW for video. PON does present the possibility of doing and RF Overlay though which makes traditional RF possible. That's something our CATV guy talks about often. The RF wavelength gets spun off at the NID and outputted as traditional RF on coax. I've heard of similar things with limited WDM from the egress side of the active Ethernet switch to the NID but I haven't seen any in production. > Another big advantage is in CO equipment. A 4-PON blade in a cabinet is > going to support on the order of 256 ONTs. This is something that I don't think many people have dealt with before. In our rural Active FTTH environment we're not hubbing all the fiber out of COs. Most of it hubs back to cabinets on the side of the road and from there gets put on an Ethernet ring which ultimately terminates in the COs. Because of this while we may have tens of thousands of strands out in the field we don't have anywhere near that amount in a single cabinet or CO. A lot of people think that Active FTTH means home-running ever strand back to a single CO and that's not generally the case. LECs usually deploy a distributed model with aggregation out in the field in cabinets or huts and then backhaul that back to the COs. This also means that fewer individual fiber ports get served out of any one location. So a cabinet might have 3-4 blades in individual chassis or it might have a 13-slot chassis with as many slots populated to meet the demand. It seems to work well. I see what you mean though with the port density and space savings. I think most deployments manage to avoid the hassle but I can see where extremely dense locations could run into trouble. Good points Justin From pauldotwall at gmail.com Tue Dec 1 19:33:20 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 1 Dec 2009 14:33:20 -0500 Subject: FTTH Active vs Passive In-Reply-To: <20091201171435.GH4453@dan.olp.net> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> Message-ID: <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> On Tue, Dec 1, 2009 at 12:14 PM, Dan White wrote: > All valid points. Deploying a strand to each customer from the CO/Cabinet > is a good way to future proof your plant. I would argue that every customer is entitled to duplex fiber. Drive Slow, Paul Wall From jwbensley at gmail.com Tue Dec 1 20:07:42 2009 From: jwbensley at gmail.com (James Bensley) Date: Tue, 1 Dec 2009 20:07:42 +0000 Subject: FTTH Active vs Passive In-Reply-To: <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> Message-ID: <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> I'm wondering why despite all this comparatively magical speed increase we have seen over the last decade, with 10 times better on the horizon, we the customer ever get a 1:1 speed ratio? -- Regards, James ;) Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." - http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html From dwhite at olp.net Tue Dec 1 20:13:53 2009 From: dwhite at olp.net (Dan White) Date: Tue, 1 Dec 2009 14:13:53 -0600 Subject: FTTH Active vs Passive In-Reply-To: <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> Message-ID: <20091201201352.GK4453@dan.olp.net> On 01/12/09?14:33?-0500, Paul Wall wrote: >On Tue, Dec 1, 2009 at 12:14 PM, Dan White wrote: >> All valid points. Deploying a strand to each customer from the CO/Cabinet >> is a good way to future proof your plant. > >I would argue that every customer is entitled to duplex fiber. In the case of PON, WDM is used to dedicate wavelengths on the strand for different purposes - ingress, egress, RF overlay (as someone else mentioned), TDM voice etc. You could deploy 2 or 3 strands and get more bandwidth to the customer, using perhaps less expensive hardware, or you could maintain fewer strands in the ground and depend on equipment manufactures to maintain an adequate growth in bandwidth capabilities. Neither approach is going to work for everyone. -- Dan White From bmanning at vacation.karoshi.com Tue Dec 1 20:12:29 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Dec 2009 20:12:29 +0000 Subject: FTTH Active vs Passive In-Reply-To: <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> Message-ID: <20091201201229.GB1158@vacation.karoshi.com.> On Tue, Dec 01, 2009 at 02:33:20PM -0500, Paul Wall wrote: > On Tue, Dec 1, 2009 at 12:14 PM, Dan White wrote: > > All valid points. Deploying a strand to each customer from the CO/Cabinet > > is a good way to future proof your plant. > > I would argue that every customer is entitled to duplex fiber. > > Drive Slow, > Paul Wall nifty... my own fiber pair - and I'll run 32 lambdas on each... (can I has kewl new rare-earth glass ... so I can run 100G per lambda? - plz?) --bill From bmanning at vacation.karoshi.com Tue Dec 1 20:15:03 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Dec 2009 20:15:03 +0000 Subject: FTTH Active vs Passive In-Reply-To: <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> Message-ID: <20091201201503.GC1158@vacation.karoshi.com.> On Tue, Dec 01, 2009 at 08:07:42PM +0000, James Bensley wrote: > I'm wondering why despite all this comparatively magical speed > increase we have seen over the last decade, with 10 times better on > the horizon, we the customer ever get a 1:1 speed ratio? speed kills... actually, the killer here is PMTU... there is almost no way to effectively utilize the BW when the MTU is locked to 1500 bytes. --bill > > -- > Regards, > James ;) > > Charles de Gaulle - "The better I get to know men, the more I find > myself loving dogs." - > http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html From SBrown at clackesd.k12.or.us Tue Dec 1 20:28:14 2009 From: SBrown at clackesd.k12.or.us (Scott Brown/Clack/ESD) Date: Tue, 1 Dec 2009 12:28:14 -0800 Subject: FTTH Active vs Passive In-Reply-To: <20091201201352.GK4453@dan.olp.net> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <20091201201352.GK4453@dan.olp.net> Message-ID: > You could deploy 2 or 3 strands and get more bandwidth to the customer, > using perhaps less expensive hardware, or you could maintain fewer strands > in the ground and depend on equipment manufactures to maintain an adequate > growth in bandwidth capabilities. > > Neither approach is going to work for everyone. > > -- > Dan White > At my previous job we were deploying a hybrid system - a mix of active and PON depending on the requirements of the customer. For the active systems it wasn't homerun fiber back to the main CO - we had a nice ring of fiber to key locations in the City and then we would place a ped where the spurs would connect to. Top that off with a CISCO Wireless Mesh overlay and no matter what speed and mobility you needed you could get it somehow... Our only limit (at the time I left) was upstream to the Internet. --Scott From chaz at chaz6.com Tue Dec 1 21:57:40 2009 From: chaz at chaz6.com (Chris Hills) Date: Tue, 01 Dec 2009 22:57:40 +0100 Subject: FTTH Active vs Passive In-Reply-To: <85c108810912011106y6a86ac8kfdebd305c773b9c6@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <4B1562D8.1060902@gmail.com> <85c108810912011047x5031e987l353de3f33f672348@mail.gmail.com> <20091201185805.GF1382336@hiwaay.net> <85c108810912011106y6a86ac8kfdebd305c773b9c6@mail.gmail.com> Message-ID: On 01/12/09 20:06, Byron Hicks wrote: > These were the numbers presented at an Internet2 meeting about the 4k > testing happening between UCSD and UW. I'm not sure what compression > algorithm they were using for the test. http://www.bbc.co.uk/blogs/bbcinternet/2008/09/super_hi_vision.html "The Italian broadcaster, RAI, demonstrated satellite broadcasting of SHV at 140 Mbit/s from Turin to IBC." Super Hi-Vision has a resolution of 4320x7860 (and also carries 22.2 channel sound). IIRC the video codec used was Dirac. >From the Dirac website:- "In our first experiments, we managed to get excellent picture quality at 128Mb/s, which sounds huge but is equivalent to just 4Mb/s for HDTV." From jared at puck.nether.net Tue Dec 1 22:36:51 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Dec 2009 17:36:51 -0500 Subject: FTTH Active vs Passive In-Reply-To: <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> Message-ID: <2BBC3FD8-9C30-4DC2-8389-2C11041E0D1A@puck.nether.net> On Dec 1, 2009, at 2:33 PM, Paul Wall wrote: > On Tue, Dec 1, 2009 at 12:14 PM, Dan White wrote: >> All valid points. Deploying a strand to each customer from the CO/Cabinet >> is a good way to future proof your plant. > > I would argue that every customer is entitled to duplex fiber. I'll settle with fiber within 2km of my home right now. If people have recommendations for FTTH/GPON/Whatnot let me know. Right now, I'm thinking stuff like this is cool: http://www.provantage.com/zyxel-mc1000sfp~7ZYXS00C.htm I suspect one could do interesting things with BX10/LX10 SFPs. (Likely not with cisco though). - Jared From randy at psg.com Tue Dec 1 23:11:23 2009 From: randy at psg.com (Randy Bush) Date: Wed, 02 Dec 2009 08:11:23 +0900 Subject: FTTH Active vs Passive In-Reply-To: <20091201201503.GC1158@vacation.karoshi.com.> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> Message-ID: > actually, the killer here is PMTU... there is almost no way to > effectively utilize the BW when the MTU is locked to 1500 bytes. and the reality, e.g. ntt b-flets, is often pppoe v4-only, which is lower. randy From aaron.glenn at gmail.com Wed Dec 2 00:34:08 2009 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Wed, 2 Dec 2009 00:34:08 +0000 Subject: DNS query analyzer In-Reply-To: References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <18f601940912011634m4102d96cj92dc7d152d059ef2@mail.gmail.com> On Tue, Dec 1, 2009 at 3:58 PM, Tony Finch wrote: > On Mon, 30 Nov 2009, Joseph Jackson wrote: >> >> Anyone know of a tool that can take a pcap file from wireshark that was >> used to collect dns queries and then spit out statistics about the >> queries such as RTT and timeouts? > > I don't know if it'll do exactly what you want, but have a look at > https://www.dns-oarc.net/tools/dnscap dnscap paired with dpkt can quickly and elegantly accomplish what you desire; if you know python (: From jul_bsd at yahoo.fr Wed Dec 2 05:47:11 2009 From: jul_bsd at yahoo.fr (jul) Date: Wed, 02 Dec 2009 06:47:11 +0100 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <4B15FF5F.90205@yahoo.fr> Joseph Jackson wrote on 01/12/09 01:06: > Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? You also have DNSTop http://dns.measurement-factory.com/tools/dnstop/ Best regards, Julien From sfouant at shortestpathfirst.net Wed Dec 2 05:57:48 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 2 Dec 2009 05:57:48 +0000 Subject: DNS query analyzer Message-ID: <1407469523-1259733434-cardhu_decombobulator_blackberry.rim.net-1862031090-@bda772.bisx.prod.on.blackberry> DNStop is a real good tool for what it does. It's an exceptionally useful tool and probably at the top of my list for deciphering DoS attacks targetting or amplifying against DNS resolvers. But for RTT and timeouts, errr not so good. Sorry for the top post. Stupid Blackberry... Regards, Stefan Fouant www.shortestpathfirst.com ------Original Message------ From: jul To: Joseph Jackson To: nanog at nanog.org Subject: Re: DNS query analyzer Sent: Dec 2, 2009 12:47 AM Joseph Jackson wrote on 01/12/09 01:06: > Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? You also have DNSTop http://dns.measurement-factory.com/tools/dnstop/ Best regards, Julien Sent from my Verizon Wireless BlackBerry From w.d.clayton at gmail.com Wed Dec 2 06:58:48 2009 From: w.d.clayton at gmail.com (Will Clayton) Date: Wed, 2 Dec 2009 00:58:48 -0600 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <20091201201503.GC1158@vacation.karoshi.com.> Message-ID: <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Now just imagine that people inside the big firewall could tell you how they engineered multi-gig FTTTVs. At the risk of sounding like a politician I will actually state that the physical/private interest topology of the fiber network in the United States is incredibly prohibitive of the advances that you guys are talking about. The big picture here is table scraps to equipment manufacturers no matter how crowded the vendor meet is. There are pockets of isolated/niche success and its great to see technology implemented in such ways, RFCs being drafted, etc., but jeez guys, the real issue at stake here is how in the hell we are all going to work past the bureaucratic constraints of our arguably humble positions to transparently superimpose something that will enable the masses to communicate and, at the same time, appease, for lack of a better word, those who would capitalize on the sheer lack of unified infrastructure. This post in itself obviates our incapacity to handle our own infrastructure, and while I believe discussing this is of the utmost importance I have to point out, first and foremost, that the highest priority is a level playing field. I know at least some of you can really understand that and I hope it drive some of your sleeping points home a bit so you can wake up in the morning and get something right. -Will Ok I will never post here again. Gnight... On Tue, Dec 1, 2009 at 5:11 PM, Randy Bush wrote: > > actually, the killer here is PMTU... there is almost no way to > > effectively utilize the BW when the MTU is locked to 1500 bytes. > > and the reality, e.g. ntt b-flets, is often pppoe v4-only, which is > lower. > > randy > > From randy at psg.com Wed Dec 2 07:32:11 2009 From: randy at psg.com (Randy Bush) Date: Wed, 02 Dec 2009 16:32:11 +0900 Subject: FTTH Active vs Passive In-Reply-To: <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> Message-ID: > At the risk of sounding like a politician I will actually state that the > physical/private interest topology of the fiber network in the United States > is incredibly prohibitive of the advances that you guys are talking about. > The big picture here is table scraps to equipment manufacturers no matter > how crowded the vendor meet is. There are pockets of isolated/niche success > and its great to see technology implemented in such ways, RFCs being > drafted, etc., but jeez guys, the real issue at stake here is how in the > hell we are all going to work past the bureaucratic constraints of our > arguably humble positions to transparently superimpose something that will > enable the masses to communicate and, at the same time, appease, for lack of > a better word, those who would capitalize on the sheer lack of unified > infrastructure. This post in itself obviates our incapacity to handle our > own infrastructure, and while I believe discussing this is of the utmost > importance I have to point out, first and foremost, that the highest > priority is a level playing field. I know at least some of you can really > understand that and I hope it drive some of your sleeping points home a bit > so you can wake up in the morning and get something right. life can be simple. i moved to a first world country, japan. $35/mo for real 100/100, and i could get faster, just don't need it for a couple of laptops. hope y'all are having fun in duopoly jail. randy From fkittred at staff.gwi.net Wed Dec 2 13:00:36 2009 From: fkittred at staff.gwi.net (Fletcher Kittredge) Date: Wed, 2 Dec 2009 08:00:36 -0500 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: Randy; Pricing aside, do you feel the Japanese have a good architecture for the last mile? Would it adapt well from an environment that is mostly multi-dwelling units (MDU) to one which is mostly single-dwelling units? Any thoughts on good places to start for an english language speaker to learn about the Japanese broadband experience? thanks! Fletcher On Wed, Dec 2, 2009 at 2:32 AM, Randy Bush wrote: > > At the risk of sounding like a politician I will actually state that the > > physical/private interest topology of the fiber network in the United > States > > is incredibly prohibitive of the advances that you guys are talking > about. > > The big picture here is table scraps to equipment manufacturers no matter > > how crowded the vendor meet is. There are pockets of isolated/niche > success > > and its great to see technology implemented in such ways, RFCs being > > drafted, etc., but jeez guys, the real issue at stake here is how in the > > hell we are all going to work past the bureaucratic constraints of our > > arguably humble positions to transparently superimpose something that > will > > enable the masses to communicate and, at the same time, appease, for lack > of > > a better word, those who would capitalize on the sheer lack of unified > > infrastructure. This post in itself obviates our incapacity to handle our > > own infrastructure, and while I believe discussing this is of the utmost > > importance I have to point out, first and foremost, that the highest > > priority is a level playing field. I know at least some of you can really > > understand that and I hope it drive some of your sleeping points home a > bit > > so you can wake up in the morning and get something right. > > life can be simple. i moved to a first world country, japan. $35/mo > for real 100/100, and i could get faster, just don't need it for a > couple of laptops. > > hope y'all are having fun in duopoly jail. > > randy > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From swmike at swm.pp.se Wed Dec 2 13:35:08 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 14:35:08 +0100 (CET) Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: On Wed, 2 Dec 2009, Fletcher Kittredge wrote: > Pricing aside, do you feel the Japanese have a good architecture for the > last mile? Would it adapt well from an environment that is mostly > multi-dwelling units (MDU) to one which is mostly single-dwelling units? > Any thoughts on good places to start for an english language speaker to > learn about the Japanese broadband experience? You might look into what's being done in Sweden then, here there are municipality networks who dig up the streets and does fiber to the individual house in "suburbia" (you have to trench your own land though, 4dm deep, 1-2dm wide, they only dig in the street put down the pipe in your trench). Common cost for the house owner to get this done is in the 2-4kUSD range per house, then you can choose between multiple ISPs to purchase your bw from. 100/100 (symmetric speed) seems to cost 40 USD per month, 10/10 is 5-10 USD/month cheaper. I've been trying to run the text thru google translate, but the web magic seems to prohibit this from working. If someone can figure it out better than me, the URL is here (in swedish): -- Mikael Abrahamsson email: swmike at swm.pp.se From Valdis.Kletnieks at vt.edu Wed Dec 2 14:14:16 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Dec 2009 09:14:16 -0500 Subject: FTTH Active vs Passive In-Reply-To: Your message of "Wed, 02 Dec 2009 00:58:48 CST." <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <20091201201503.GC1158@vacation.karoshi.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: <40832.1259763256@turing-police.cc.vt.edu> On Wed, 02 Dec 2009 00:58:48 CST, Will Clayton said: > enable the masses to communicate and, at the same time, appease, for lack of > a better word, those who would capitalize on the sheer lack of unified > infrastructure. The same way we appeased them the *last* time we gave them incentives to deploy true high-capacity broadband, of course... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Rod.Beck at hiberniaatlantic.com Wed Dec 2 14:14:17 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 2 Dec 2009 14:14:17 -0000 Subject: FTTH Active vs Passive References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com><4B1547BD.6050004@justinshore.com><20091201171435.GH4453@dan.olp.net><620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com><3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com><69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local> Given the start up costs, it is not clear what is compelling. Here in Budapest I get Internet access for less than Euros. Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris http://www.hiberniaatlantic.com -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Wed 12/2/2009 1:35 PM To: Fletcher Kittredge Cc: NANOG list Subject: Re: FTTH Active vs Passive On Wed, 2 Dec 2009, Fletcher Kittredge wrote: > Pricing aside, do you feel the Japanese have a good architecture for the > last mile? Would it adapt well from an environment that is mostly > multi-dwelling units (MDU) to one which is mostly single-dwelling units? > Any thoughts on good places to start for an english language speaker to > learn about the Japanese broadband experience? You might look into what's being done in Sweden then, here there are municipality networks who dig up the streets and does fiber to the individual house in "suburbia" (you have to trench your own land though, 4dm deep, 1-2dm wide, they only dig in the street put down the pipe in your trench). Common cost for the house owner to get this done is in the 2-4kUSD range per house, then you can choose between multiple ISPs to purchase your bw from. 100/100 (symmetric speed) seems to cost 40 USD per month, 10/10 is 5-10 USD/month cheaper. I've been trying to run the text thru google translate, but the web magic seems to prohibit this from working. If someone can figure it out better than me, the URL is here (in swedish): -- Mikael Abrahamsson email: swmike at swm.pp.se From jbates at brightok.net Wed Dec 2 14:24:21 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Dec 2009 08:24:21 -0600 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: <4B167895.80702@brightok.net> Mikael Abrahamsson wrote: > You might look into what's being done in Sweden then, here there are > municipality networks who dig up the streets and does fiber to the > individual house in "suburbia" (you have to trench your own land though, > 4dm deep, 1-2dm wide, they only dig in the street put down the pipe in > your trench). Sounds good, though I don't see a majority of US consumers paying for the trench, nor do I see a lot of home builders paying for it either (around here they often skimp on putting in a real road, so the city forces the road to be private which leaves it a wonderful unmaintained gravel speed bump, much less wiring housing for data). In addition, I don't see the municipalities paying for plant like they do roads. Then again, I'm glad the city/county doesn't pay for our plant. They can barely maintain their roads. Politics, education, and how money flows in our economy are all probably show stoppers for widespread success. Jack From cmaurand at xyonet.com Wed Dec 2 15:27:32 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 02 Dec 2009 10:27:32 -0500 Subject: FTTH Active vs Passive In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com><4B1547BD.6050004@justinshore.com><20091201171435.GH4453@dan.olp.net><620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com><3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com><69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local> Message-ID: <4B168764.9000700@xyonet.com> > > You might look into what's being done in Sweden then, here there are > municipality networks who dig up the streets and does fiber to the > individual house in "suburbia" (you have to trench your own land though, > 4dm deep, 1-2dm wide, they only dig in the street put down the pipe in > your trench). > > Common cost for the house owner to get this done is in the 2-4kUSD range > per house, then you can choose between multiple ISPs to purchase your bw > from. 100/100 (symmetric speed) seems to cost 40 USD per month, 10/10 is > 5-10 USD/month cheaper. > > I've been trying to run the text thru google translate, but the web magic > seems to prohibit this from working. > > If someone can figure it out better than me, the URL is here (in swedish): > > > > I'd look more to what they're doing in Rochester, NY: http://rocwiki.org/Sewer_Fiber_Optic_Network Run it in the sewers. The sewer system runs to every building and household in the municipality. No need to re-trench anything. --Curtis From Ian.Mackinnon at atosorigin.com Wed Dec 2 15:27:55 2009 From: Ian.Mackinnon at atosorigin.com (Mackinnon, Ian) Date: Wed, 2 Dec 2009 15:27:55 +0000 Subject: FTTH Active vs Passive In-Reply-To: <4B168764.9000700@xyonet.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com><4B1547BD.6050004@justinshore.com><20091201171435.GH4453@dan.olp.net><620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com><3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com><69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local> <4B168764.9000700@xyonet.com> Message-ID: <61D4116B957C2843AACB49664C8AB2230382D650@UKCWRX004.uk.int.atosorigin.com> > -----Original Message----- > From: Curtis Maurand [mailto:cmaurand at xyonet.com] > > > I'd look more to what they're doing in Rochester, NY: > http://rocwiki.org/Sewer_Fiber_Optic_Network > > Run it in the sewers. The sewer system runs to every building and > household in the municipality. No need to re-trench anything. > > --Curtis > In the UK more homes have fixed wire telephony than mains sewers or water. Not sure what that means to this discussion :-) _______________________________________________________ Atos Origin and Atos Consulting are trading names used by the Atos Origin group. The following trading entities are registered in England and Wales: Atos Origin IT Services UK Limited (registered number 01245534) and Atos Consulting Limited (registered number 04312380). The registered office for each is at 4 Triton Square, Regents Place, London, NW1 3HG.The VAT No. for each is: GB232327983 This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos Origin therefore can accept no liability for any errors or their content. Although Atos Origin endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos Origin by email. _______________________________________________________ From fkittred at staff.gwi.net Wed Dec 2 16:24:41 2009 From: fkittred at staff.gwi.net (Fletcher Kittredge) Date: Wed, 2 Dec 2009 11:24:41 -0500 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: Thanks for the pointers, Mikael. unfortunately, my Swedish is not much better than my Japanese... But it is a good start and I am sure I will find some sort of English description somewhere. I should have been a bit more explicit in my question: I am not concerned on the routing of the last mile, sewer, trenching, etc. That is a solved problem for these projects. The big questions for me is PON vs active and, if PON, what are the details: prisms in the CO vs prisms in the field, which xPON to use, etc. How is splicing and interconnection done, etc. thanks! Fletcher On Wed, Dec 2, 2009 at 8:35 AM, Mikael Abrahamsson wrote: > On Wed, 2 Dec 2009, Fletcher Kittredge wrote: > > Pricing aside, do you feel the Japanese have a good architecture for the >> last mile? Would it adapt well from an environment that is mostly >> multi-dwelling units (MDU) to one which is mostly single-dwelling units? Any >> thoughts on good places to start for an english language speaker to learn >> about the Japanese broadband experience? >> > > You might look into what's being done in Sweden then, here there are > municipality networks who dig up the streets and does fiber to the > individual house in "suburbia" (you have to trench your own land though, 4dm > deep, 1-2dm wide, they only dig in the street put down the pipe in your > trench). > > Common cost for the house owner to get this done is in the 2-4kUSD range > per house, then you can choose between multiple ISPs to purchase your bw > from. 100/100 (symmetric speed) seems to cost 40 USD per month, 10/10 is > 5-10 USD/month cheaper. > > I've been trying to run the text thru google translate, but the web magic > seems to prohibit this from working. > > If someone can figure it out better than me, the URL is here (in swedish): > > > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From michael.holstein at csuohio.edu Wed Dec 2 16:33:47 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 02 Dec 2009 11:33:47 -0500 Subject: FTTH Active vs Passive In-Reply-To: <4B168764.9000700@xyonet.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com><4B1547BD.6050004@justinshore.com><20091201171435.GH4453@dan.olp.net><620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com><3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com><69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local> <4B168764.9000700@xyonet.com> Message-ID: <4B1696EB.3070905@csuohio.edu> > I'd look more to what they're doing in Rochester, NY: > http://rocwiki.org/Sewer_Fiber_Optic_Network > Run it in the sewers. The sewer system runs to every building and > household in the municipality. No need to re-trench anything. > Ahh .. the TISP : http://www.google.com/tisp/install.html Regards, Michael Holstein Cleveland State University From cmaurand at xyonet.com Wed Dec 2 16:37:26 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 02 Dec 2009 11:37:26 -0500 Subject: FTTH Active vs Passive In-Reply-To: <61D4116B957C2843AACB49664C8AB2230382D650@UKCWRX004.uk.int.atosorigin.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com><4B1547BD.6050004@justinshore.com><20091201171435.GH4453@dan.olp.net><620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com><3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com><69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local> <4B168764.9000700@xyonet.com> <61D4116B957C2843AACB49664C8AB2230382D650@UKCWRX004.uk.int.atosorigin.com> Message-ID: <4B1697C6.5020901@xyonet.com> Mackinnon, Ian wrote: > > > In the UK more homes have fixed wire telephony than mains sewers or > water. > Not sure what that means to this discussion :-) > > In the US as well, but if you're trying to run a new fiber network and you want it uderground, the sewers in metro areas are a good place to start. In the rural areas, however, everything is on poles except for new construction where trenching and conduit are required. I worked briefly for a small ILEC/CLEC here in Maine that does not replace copper trunks with copper any longer. If the copper goes bad, they're running FTTH. From swmike at swm.pp.se Wed Dec 2 17:16:38 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 18:16:38 +0100 (CET) Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: On Wed, 2 Dec 2009, Fletcher Kittredge wrote: > Thanks for the pointers, Mikael. unfortunately, my Swedish is not much > better than my Japanese... But it is a good start and I am sure I will find > some sort of English description somewhere. Here is a cut/paste of the thing run thru google translate. I believe you'll get the meaning. This actually works, people do pay this amount of money to get connected. I believe they would in the US too, given the chance. ----------------- Connection villas Can I connect my house? For an answer ang your villa, please complete and submit an Expression of interest. It then goes into an order, provided that the fiber tableware can be connected! Here's how it works! During the period tj?lfria is our excavation works in roads and public land for the siting of the optical fiber. Today we have a well-developed fiber network allowing for the vast majority living in Sollentuna to quickly connect their property, and thus have access to a wide range of services. We will contact you Once you have ordered the connection of broadband we will contact you to show where you are digging at the site, from our access point in the street to your house. Excavation of land >From a designated point at land border, undermining you to the agreed point at the house's outer wall. Shafts shall be 4 dm deep and 1-2 dm wide along the entire route, and ends with a hole in the foundation. The shaft adds a conduit, as optical fiber to serve in. tube free download at our stores at Knistad farm road 12, Monday-Thursday at 07.30-10.45 and 12.00-15.00 Note: Digging shafts before conduit retrieved, so you know exactly the number of meter tubes you need. Do you want help with digging at the site and the siting of the pipes, you can contact our land contractor for cost data: Ponds Mountain Construction AB, tel. 08-92 02 40th Before you dig If you are going to dig into the ground, you must make sure that you do not dig any cables or pipes for electricity, broadband and heating. We will send you a fitter who find out where the pipes are. That way you can avoid digging of a pipe by mistake. Release are made on weekdays between 08.00 - 15.30 and must be notified at least three days in advance. Cabling is free. Remember that you may be held liable if you have not asked for cabling and undermining of any cables or pipes for electricity, broadband or remote heat! Backhoe course and put tubes in good time before we come to your area. Connecting in the house At the outlet in the house Drill a 12mm hole in the wall / foundation. The hole is drilled obliquely downward (about 45 degrees) from the inside out. This angle is important for optical fiber bend radius should not be too sharp. Need help with piercing, notify our supervisor when he visits you to discuss the excavation work. Connection of optical fiber When the plumbing and piercing are done, please let us know. We then pull up the fiber, and our engineers put a note in your mailbox to make an appointment for a connection. Inside the wall mounted switch to which you connect. This is also our transfer point for all services. Switch must be plugged into an electrical outlet nearby. Inside the house >From the switch ensures you install the network cable to the rooms PC or TV to be connected in. You must use the cable type of Category 5 unshielded twisted pair network cable with 4 pairs of conductors and RJ45 connectors, EIA / TIA 568B. Ready for delivery Now you can order any of the services offered in Sollentuna Energi's broadband network. You can choose from several different ISPs, some of which also offer VoIP. When your supplier has informed us about your order, switched services normally within 10 working days. Information on service providers and prices can be found under the Internet link. ---- -- Mikael Abrahamsson email: swmike at swm.pp.se From mathews at hawaii.edu Wed Dec 2 17:32:09 2009 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Wed, 02 Dec 2009 12:32:09 -0500 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: <4B16A499.9060508@hawaii.edu> Mikael Abrahamsson wrote: > On Wed, 2 Dec 2009, Fletcher Kittredge wrote: >> Thanks for the pointers, Mikael. unfortunately, my Swedish is not much >> better than my Japanese... But it is a good start and I am sure I >> will find >> some sort of English description somewhere. > Here is a cut/paste of the thing run thru google translate. I believe > you'll get the meaning. > > This actually works, people do pay this amount of money to get > connected. I believe they would in the US too, given the chance. Ay, there's the rub! The question is not if this can be done here in the US but, will it be done? Like many things, whether it is in 'Public Works' or 'Public Policy,' in the US, parties generally choose the easy/cheapest way out. There's no need to do too much. Planning/preparing/accounting for things ahead? What's that? Do not want to take this discussion (more than it already has) to the non-operational front. From a.harrowell at gmail.com Wed Dec 2 17:45:13 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 2 Dec 2009 17:45:13 +0000 Subject: FTTH Active vs Passive In-Reply-To: <4B167895.80702@brightok.net> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B167895.80702@brightok.net> Message-ID: <200912021745.24429.a.harrowell@gmail.com> Another issue - how far does the technology support open access/infrastructure sharing/wholesaling? Not only are networks that get public funding likely to be expected to provide these, but there is evidence that they are important financially. Benoit Felten's presentation at eComm Europe suggested that the takerate and the presence of wholesale were the biggest sensitivities bearing on the pay off period for a FTTH deployment. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From delian at promela.com Wed Dec 2 18:03:45 2009 From: delian at promela.com (Delian Delchev) Date: Wed, 2 Dec 2009 20:03:45 +0200 Subject: FTTH Active vs Passive In-Reply-To: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> Message-ID: <2242924f0912021003w26d40e68ne4ffd15085751e67@mail.gmail.com> Very much it depends on the case. In price perspective Active Ethernet is cheaper (for the active equipment) for both CAPEX and OPEX. Also it is reacher in features. Just for comparison 2.5Gbit G-PON solution cost about the same as reasonable 10Gig FTTH active ethernet solution. If you do extremely cheap Active Ethernet with Ethernet BRAS you can go even 5-10 times cheaper than passive, and much more reacher on features. The fiber for Active Ethernet actually costs the same as the fiber for Passive Ethernet. You have the same amount of work to install it the fiber price difference is very small if you have 48 fibers than 12 for example. The number of splices you need to do in fiber for Active Ethernet is slightly higher but it is absolutely and fully compensated by the price of the PON splitter. So if you are looking for any of the "price", "stability", "standartization" (both G-PON and GEPON have many issues with the compatibility between the vendors), "speed", "feature richness", Active Ethernet always win. The best thing for Passive FTTH is written in its name. It is "Passive", which means, you don't need to power it except in the subscriber's home. So if you have any issues with the power (or requirements for availability, that can not be reached cheaply because of reasons related to the power), then passive FTTH is your choice. In any other case Active is better. Delian On Tue, Dec 1, 2009 at 4:57 AM, Luke Marrott wrote: > I'm wondering what everyones thoughts are in regards to FTTH using Active > Ethernet or Passive. I work for a FTTH Provider that has done Active > Ethernet on a few networks so I'm always biased in discussions, but I don't > know anyone with experience in PON. > > I've read before that almost all PON technology is proprietary, locking you > into a specific hardware vendor. However I think this is changing or has > already changed, opening PON up for interoperability. Can anyone confirm > this? > > Thanks in advance. > > :Luke Marrott > From todd at velocitytelephone.com Wed Dec 2 18:12:04 2009 From: todd at velocitytelephone.com (Todd Mueller) Date: Wed, 02 Dec 2009 12:12:04 -0600 (CST) Subject: Edge-Core (Accton) switches Message-ID: <47B0A0C1ADE1ED4BA114480988FE878F1D1864@dc1.gv-office.local> Anyone have any experience using Edge-Core switches (or Accton, Edge-Core is a subsidiary)? Good/bad? Pricing/features seem good, but you often get what you pay for . . . Thanks, Todd From delian at promela.com Wed Dec 2 18:17:06 2009 From: delian at promela.com (Delian Delchev) Date: Wed, 2 Dec 2009 20:17:06 +0200 Subject: FTTH Active vs Passive In-Reply-To: <200912021745.24429.a.harrowell@gmail.com> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B167895.80702@brightok.net> <200912021745.24429.a.harrowell@gmail.com> Message-ID: <2242924f0912021017x3c361f6fgc6a9837beba189a7@mail.gmail.com> Generally "Ethernet" itself support in the last years natively "Openaccess". But first you need to answer to youself what type of Openness you want? Open Access on Layer3 level? As it is made by the ADSL L3 LLU? If so, then both Active and passive FTTH Ethernet are absolutley ready for it. Every Service provider is a single VLAN, DHCP snooping, ARP snooping (to enforce security) are enabled and that is. You can even do the same services as the ADSL providers, you can buy (only for central place, for service control, not for access) BRAS solution as Juniper MX or Ericsson SE1200 (or Alcatel or even the currently slow performing Cisco) and to have radius authentication per session and per vlan. You can even give to your service provides Virtual Logical Router (with its own administrative control) in MX or Logical Context (which is the same, but implemented in more scalable way) into the Ericsson SE1200. You can have integrated L3 Open Access solution from a vendors like Packet Front, but their solution is expensive per subscriber (in large scale) and performs well only on L3. Open Access on Layer2 level? This is the absolutely pure Open Access you can have. Pure Layer2 tunnels from the Service Provider to the subscriber's port. Then the service provider can do whatever it wants and provide L3 and L2 services in absolutely independent and transparent way. Active Ethernet is ready for this today. You can do 802.1ac/ad (Double VLAN Tagging) per port and have 16m combinations (ports) that you can transport transparently to your service providers. You can do it with very expensive equipment (as Cisco, Juniper, etc) or with even really cheap equipment (for about 5$ per port) as well. Ethernet today have many interesting carrier features supported as standards directly by IEEE. You can have security, encryption, control, bandwidh control (even on HQ), filtering, pure transparent transportation. The mac addresses and the VLAN IDs are not limitation anymore for years. You have even Ethernet SNMP, PING, Traceroute, service control. If you need some guides on this, I can tell you, but I don't think is necessary to get deeper on that right now. PON is relatively close to L2 open access. Most of the vendors are "almost there" where 802.1ac/ad standard is. So here the situation is relativley the same as in the active ethernet. Delian On Wed, Dec 2, 2009 at 7:45 PM, Alexander Harrowell wrote: > Another issue - how far does the technology support open > access/infrastructure > sharing/wholesaling? Not only are networks that get public funding likely > to > be expected to provide these, but there is evidence that they are important > financially. > > Benoit Felten's presentation at eComm Europe suggested that the takerate > and > the presence of wholesale were the biggest sensitivities bearing on the pay > off > period for a FTTH deployment. > From rsk at gsp.org Wed Dec 2 18:31:24 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 2 Dec 2009 13:31:24 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: <4B0C0EEE.50302@brad-x.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> Message-ID: <20091202183124.GA25056@gsp.org> On Tue, Nov 24, 2009 at 11:50:54AM -0500, Brad Laue wrote: > Exclusionary blocklists are a great idea if they're constantly > maintained. I'm unclear as to why mail administrators don't work more > proactively with things like SenderID and SPF, as these seem to be far > more maintainable in the long-run than an ever-growing list of IP > address ranges. Because SenderID and SPF have no anti-spam value, and almost no anti-forgery value. Not that this stops a *lot* of people who've drunk the kool-aid from trying to use them anyway, but blacklists are still -- by a huge margin -- the most effective anti-abuse tool available. That said, blacklists (like all such resources) should be maintained, and those using them should provide working contact methods that enable resolution of the inevitable mistakes. The problem thus isn't so much the choice of/use of blacklist(s), it's incompetent mail system administration. ---Rsk From owenc at hubris.net Wed Dec 2 18:38:54 2009 From: owenc at hubris.net (Chris Owen) Date: Wed, 2 Dec 2009 12:38:54 -0600 Subject: AT&T SMTP Admin contact? In-Reply-To: <20091202183124.GA25056@gsp.org> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <20091202183124.GA25056@gsp.org> Message-ID: <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> On Dec 2, 2009, at 12:31 PM, Rich Kulawiec wrote: > Because SenderID and SPF have no anti-spam value, and almost no > anti-forgery value. Not that this stops a *lot* of people who've drunk > the kool-aid from trying to use them anyway, OK, I'll bite--How exactly do you go about forging email from my domain name if the host receiving it is checking SPF? Chris ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From dholmes at mwdh2o.com Wed Dec 2 19:29:45 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 2 Dec 2009 11:29:45 -0800 Subject: FTTH Active vs Passive In-Reply-To: <4B1696EB.3070905@csuohio.edu> References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com><4B1547BD.6050004@justinshore.com><20091201171435.GH4453@dan.olp.net><620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com><3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com><69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB039576AF@bert.HiberniaAtlantic.local><4B168764.9000700@xyonet.com> <4B1696EB.3070905@csuohio.edu> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0A1F430A@usmsxt104.mwd.h2o> Running fiber in the sewers can lead to many very expensive problems for homeowners. This is so because some municipalities consider the lateral sewer line running from the main sewer line in the street to the homeowners' house the responsibility of the homeowner. If the lateral should get blocked in any way, it is the homeowners' responsibility to fix and/or replace it. Assuming the costs associated with digging a 30 foot long, 15 foot deep trench from the homeowner's property line to tie into the city sewer system can easily cost US $10,000.00 - $15,000.00. This is not usually covered by homeowners' insurance. -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Wednesday, December 02, 2009 8:34 AM To: Curtis Maurand Cc: NANOG list Subject: Re: FTTH Active vs Passive > I'd look more to what they're doing in Rochester, NY: > http://rocwiki.org/Sewer_Fiber_Optic_Network > Run it in the sewers. The sewer system runs to every building and > household in the municipality. No need to re-trench anything. > Ahh .. the TISP : http://www.google.com/tisp/install.html Regards, Michael Holstein Cleveland State University From DLasher at newedgenetworks.com Wed Dec 2 20:46:46 2009 From: DLasher at newedgenetworks.com (Lasher, Donn) Date: Wed, 2 Dec 2009 12:46:46 -0800 Subject: Leaving public peering? Message-ID: This year I've been seeing what appears to be an increasing trend among service providers.. making the decision to leave public peering. I'm sure others on this list as seeing that trend as well. I have a couple of guesses, but I'm curious , and I wanted to get some other thoughts as to the "why". I don't have exact numbers, but off the top of my head, I'd guess somewhere around two dozen of our peers have left various peering exchanges. Quick couple I checked still appear to be operational as a company, so I'm willing to remove "death" as a valid reason. I realized that paid transit is down at almost obscene levels, but is that enough of a reason to increase hop-count, latencies, etc? Why disconnect from public mostly-free peering? -donn From bicknell at ufp.org Wed Dec 2 21:20:20 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 2 Dec 2009 13:20:20 -0800 Subject: Leaving public peering? In-Reply-To: References: Message-ID: <20091202212020.GA48616@ussenterprise.ufp.org> In a message written on Wed, Dec 02, 2009 at 12:46:46PM -0800, Lasher, Donn wrote: > I realized that paid transit is down at almost obscene levels, but is > that enough of a reason to increase hop-count, latencies, etc? > > Why disconnect from public mostly-free peering? Let's look at some economics. I'm going to pick on some folks here, solely because they have prices online and because they are, I feel, representative prices. http://www.cogentco.com/us/ "Home of the $4 Megabit!" So we have transit prices at $4 per megabit. http://www.de-cix.net/content/services/public-peering.html A 1GE link to the exchange is 1000 euro per month, which is $1505 USD at the moment, let's call it $1500 for round numbers. Now, your 1GE exchange port really shouldn't be run past 60% or so, if you want to provide good service. So it's really $1500 for 600Mbits, or $2.50 per Megabit. If you're an ISP you look at this and go, humm, I take in $4 from my customer, and hand $2.50 of it right back out to an exchange operator if I use public peering, making the exchange 62% of my costs right up front. On the other hand, if I choose wisely where I private peer I can do it at places with a one-time fee for the cable, so there is $0 in MRC. I have to buy a router port, sure, but it's also $0 MRC, just a capital asset that can get written off over many years. This is the math with the $4 megabit advertised price. The halls at Nanog are awash in $2 a megabit rumors if you have large enough commits (say, a few 10GE's). Taking in $2 and paying the exchange operator $2.50 of it....well, that's not so good. :) Transit prices have fallen enough that MRC's for switch ports, and even MRC's for fiber runs (are any of you still in a colo that wants $500 a month for a fiber run, I didn't think so) are eating up huge chunks of the inbound revenue, and thus just don't make sense. Now, before someone points it out, yes, DECIX's rate per megabit is lower on a 10GE and a second port, so if you can move 2 ports of 10GE of traffic you can make it a lot cheaper. Also, Cogents $4 a megabit is probably predicated on you being in the right location and having the right commit, if you need a DS-3 in West Nowhere you'll pay a higher rate, and that helps offset some of the costs. I've oversimplified, and it's a very complex problem for most providers; however I know many are looking at the fees for peering ports go from being in the noise to a huge part of their cost structure and that doesn't work. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From swmike at swm.pp.se Wed Dec 2 21:21:03 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 22:21:03 +0100 (CET) Subject: Leaving public peering? In-Reply-To: References: Message-ID: On Wed, 2 Dec 2009, Lasher, Donn wrote: > that enough of a reason to increase hop-count, latencies, etc? In what way is hop-count a valid measurement of network preformance/quality? Today with gigabit links serialisation-delay is a non-issue so hop-count is not important anymore. Regarding your question there, I don't know what size of players you're talking about, but I'd imagine that having 3-4 engineers who knows BGP that can be on-call is actually more expensive compared to less people who needs to know about this and you just buy cheap transit... At least this is true for some small and mid-sized players. -- Mikael Abrahamsson email: swmike at swm.pp.se From jf at probe-networks.de Wed Dec 2 21:48:29 2009 From: jf at probe-networks.de (Jonas Frey) Date: Wed, 02 Dec 2009 22:48:29 +0100 Subject: Leaving public peering? In-Reply-To: <20091202212020.GA48616@ussenterprise.ufp.org> References: <20091202212020.GA48616@ussenterprise.ufp.org> Message-ID: <1259790509.31045.144.camel@wks02.probe-networks.de> Leo, the DE-CIX pricing is now 500 Euro/month...since 1st october...see end of that page. Both DE-CIX and AMS-IX have decreased their pricing this year..almost at the same time. I guess this is a move to stop company leaving public exchanges...i have seen this trend, too. Regards, Jonas On Wed, 2009-12-02 at 22:20, Leo Bicknell wrote: > In a message written on Wed, Dec 02, 2009 at 12:46:46PM -0800, Lasher, Donn wrote: > > I realized that paid transit is down at almost obscene levels, but is > > that enough of a reason to increase hop-count, latencies, etc? > > > > Why disconnect from public mostly-free peering? > > Let's look at some economics. I'm going to pick on some folks here, > solely because they have prices online and because they are, I feel, > representative prices. > > http://www.cogentco.com/us/ > > "Home of the $4 Megabit!" So we have transit prices at $4 per megabit. > > http://www.de-cix.net/content/services/public-peering.html > > A 1GE link to the exchange is 1000 euro per month, which is $1505 USD at > the moment, let's call it $1500 for round numbers. > > Now, your 1GE exchange port really shouldn't be run past 60% or so, if > you want to provide good service. So it's really $1500 for 600Mbits, > or $2.50 per Megabit. > > If you're an ISP you look at this and go, humm, I take in $4 from my > customer, and hand $2.50 of it right back out to an exchange operator > if I use public peering, making the exchange 62% of my costs right up > front. On the other hand, if I choose wisely where I private peer I > can do it at places with a one-time fee for the cable, so there is > $0 in MRC. I have to buy a router port, sure, but it's also $0 MRC, > just a capital asset that can get written off over many years. > > This is the math with the $4 megabit advertised price. The halls at > Nanog are awash in $2 a megabit rumors if you have large enough commits > (say, a few 10GE's). Taking in $2 and paying the exchange operator > $2.50 of it....well, that's not so good. :) > > Transit prices have fallen enough that MRC's for switch ports, and > even MRC's for fiber runs (are any of you still in a colo that wants > $500 a month for a fiber run, I didn't think so) are eating up huge > chunks of the inbound revenue, and thus just don't make sense. > > Now, before someone points it out, yes, DECIX's rate per megabit is > lower on a 10GE and a second port, so if you can move 2 ports of 10GE of > traffic you can make it a lot cheaper. Also, Cogents $4 a megabit is > probably predicated on you being in the right location and having the > right commit, if you need a DS-3 in West Nowhere you'll pay a higher > rate, and that helps offset some of the costs. I've oversimplified, and > it's a very complex problem for most providers; however I know many are > looking at the fees for peering ports go from being in the noise to a > huge part of their cost structure and that doesn't work. From patrick at ianai.net Wed Dec 2 21:52:10 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 2 Dec 2009 16:52:10 -0500 Subject: Leaving public peering? In-Reply-To: References: Message-ID: <5C4E2FF2-E911-4226-A54E-EC1B3B7EB3D5@ianai.net> On Dec 2, 2009, at 3:46 PM, Lasher, Donn wrote: > This year I've been seeing what appears to be an increasing trend among > service providers.. making the decision to leave public peering. I'm > sure others on this list as seeing that trend as well. I have a couple > of guesses, but I'm curious , and I wanted to get some other thoughts as > to the "why". > > > > I don't have exact numbers, but off the top of my head, I'd guess > somewhere around two dozen of our peers have left various peering > exchanges. Quick couple I checked still appear to be operational as a > company, so I'm willing to remove "death" as a valid reason. I have some "hard numbers" from LINX. LINX receives 1 new member request per week. There were a handful of cancelations in the last year. Doesn't seem to me like a lot of people are leaving public peering. It is not surprising that some networks turn down their peering - just the opposite. Business models change, special offers pop up, etc. Someone is going to turn down their peering. Instead of looking at the outliers, look at the fact more ASes are peering in more places than ever before. Peering on the Internet is robust, growing, and happy. -- TTFN, patrick > I realized that paid transit is down at almost obscene levels, but is > that enough of a reason to increase hop-count, latencies, etc? > > > > Why disconnect from public mostly-free peering? > > > > -donn > > > From jbates at brightok.net Wed Dec 2 22:26:22 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Dec 2009 16:26:22 -0600 Subject: Leaving public peering? In-Reply-To: <20091202212020.GA48616@ussenterprise.ufp.org> References: <20091202212020.GA48616@ussenterprise.ufp.org> Message-ID: <4B16E98E.80204@brightok.net> Leo Bicknell wrote: > rate, and that helps offset some of the costs. I've oversimplified, and > it's a very complex problem for most providers; however I know many are > looking at the fees for peering ports go from being in the noise to a > huge part of their cost structure and that doesn't work. > Let's also not forget those who aren't sitting right next to the exchange. I'd love to have better peering, private and public, but there's the additional 300 miles of long haul to consider as well. Then there's the consideration of redundancy. Do I want redundant feeds to the exchange or do I want to consider my local transits to be the redundancy. Will I be purchasing transit via the exchange link to perform redundant functions for my local transits? It's always a difficult financial decision, and I've been battling it for years. I want the option for more direct connectivity and more peering options, but there's additional costs which are hard to justify to the bean counters. Jack (still no dual stacked IPv6 transit due to same issues as above) From shon at unwiredbb.com Wed Dec 2 22:40:30 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Wed, 2 Dec 2009 14:40:30 -0800 Subject: Leaving public peering? In-Reply-To: <20091202212020.GA48616@ussenterprise.ufp.org> References: <20091202212020.GA48616@ussenterprise.ufp.org> Message-ID: <43BAB891D6D01742AFDEA3D62DCE9E5D54421B@uwbb-cat2.unwiredbb.local> Just to chime in on this subject. We're at Equinix in San Jose. For access to the peering at their facility, they charge a $1000 MRC Fee, plus another $250 MRC for a cross-connect for GE port. I believe they also charge a $1000 NRC fee as well. Private peering would be an option if they didn't charge for every cross-connect a monthly fee. That fee is pretty high to small people like us, which really prevents us from entering the peering stages we'd love to have at this point. If we had private peering, we'd have to pay the fee regardless. $250/mo is quite a lot. Especially if you're talking at dollars per meg. It doesn't make sense. -S -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, December 02, 2009 1:20 PM To: nanog at nanog.org Subject: Re: Leaving public peering? In a message written on Wed, Dec 02, 2009 at 12:46:46PM -0800, Lasher, Donn wrote: > I realized that paid transit is down at almost obscene levels, but is > that enough of a reason to increase hop-count, latencies, etc? > > Why disconnect from public mostly-free peering? Let's look at some economics. I'm going to pick on some folks here, solely because they have prices online and because they are, I feel, representative prices. http://www.cogentco.com/us/ "Home of the $4 Megabit!" So we have transit prices at $4 per megabit. http://www.de-cix.net/content/services/public-peering.html A 1GE link to the exchange is 1000 euro per month, which is $1505 USD at the moment, let's call it $1500 for round numbers. Now, your 1GE exchange port really shouldn't be run past 60% or so, if you want to provide good service. So it's really $1500 for 600Mbits, or $2.50 per Megabit. If you're an ISP you look at this and go, humm, I take in $4 from my customer, and hand $2.50 of it right back out to an exchange operator if I use public peering, making the exchange 62% of my costs right up front. On the other hand, if I choose wisely where I private peer I can do it at places with a one-time fee for the cable, so there is $0 in MRC. I have to buy a router port, sure, but it's also $0 MRC, just a capital asset that can get written off over many years. This is the math with the $4 megabit advertised price. The halls at Nanog are awash in $2 a megabit rumors if you have large enough commits (say, a few 10GE's). Taking in $2 and paying the exchange operator $2.50 of it....well, that's not so good. :) Transit prices have fallen enough that MRC's for switch ports, and even MRC's for fiber runs (are any of you still in a colo that wants $500 a month for a fiber run, I didn't think so) are eating up huge chunks of the inbound revenue, and thus just don't make sense. Now, before someone points it out, yes, DECIX's rate per megabit is lower on a 10GE and a second port, so if you can move 2 ports of 10GE of traffic you can make it a lot cheaper. Also, Cogents $4 a megabit is probably predicated on you being in the right location and having the right commit, if you need a DS-3 in West Nowhere you'll pay a higher rate, and that helps offset some of the costs. I've oversimplified, and it's a very complex problem for most providers; however I know many are looking at the fees for peering ports go from being in the noise to a huge part of their cost structure and that doesn't work. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From wade.peacock at sunwave.net Wed Dec 2 23:16:05 2009 From: wade.peacock at sunwave.net (Wade Peacock) Date: Wed, 02 Dec 2009 15:16:05 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. Message-ID: <4B16F535.70306@sunwave.net> We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts? -- Wade Peacock Sun Country Cablevision Ltd -------------- next part -------------- A non-text attachment was scrubbed... Name: wade_peacock.vcf Type: text/x-vcard Size: 369 bytes Desc: not available URL: From davet1 at gmail.com Wed Dec 2 23:21:18 2009 From: davet1 at gmail.com (Dave Temkin) Date: Wed, 02 Dec 2009 15:21:18 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <4B16F66E.70602@gmail.com> Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking > the topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable > internet gateways (routers/firewalls), a kin to the ever popular > Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa > home user are screaming for them. > > Thoughts? > > You're correct, out of the box there aren't many. The first couple that come to mind are the Apple Airport Express and Airport Extreme, but I don't believe Linksys/Netgear/etc. have support out of the box. From pstewart at nexicomgroup.net Wed Dec 2 23:22:31 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 2 Dec 2009 18:22:31 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: Biased opinion because we distribute/sell Tilgin related products, but they are supposed to do IPv6.... Having said that, we have not lab tested them ourselves and plan to early next year.... Paul -----Original Message----- From: Wade Peacock [mailto:wade.peacock at sunwave.net] Sent: December-02-09 6:16 PM To: nanog at nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts? -- Wade Peacock Sun Country Cablevision Ltd ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From mdodd at doddserver.com Wed Dec 2 23:23:52 2009 From: mdodd at doddserver.com (Matthew Dodd) Date: Wed, 2 Dec 2009 18:23:52 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <03D7926F-D158-43C1-A1C4-E308A418B244@doddserver.com> Apple has been shipping the Airport Extreme and Express (consumer router) with v6 support since 2007, if I recall correctly. They can also create a 4to6 tunnel automatically. -Matt Dodd On Dec 2, 2009, at 6:16 PM, Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking > the topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 > enable internet gateways (routers/firewalls), a kin to the ever > popular Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa > home user are screaming for them. > > Thoughts? > > > -- > Wade Peacock > Sun Country Cablevision Ltd > From wade.peacock at sunwave.net Wed Dec 2 23:44:15 2009 From: wade.peacock at sunwave.net (Wade Peacock) Date: Wed, 02 Dec 2009 15:44:15 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <03D7926F-D158-43C1-A1C4-E308A418B244@doddserver.com> References: <4B16F535.70306@sunwave.net> <03D7926F-D158-43C1-A1C4-E308A418B244@doddserver.com> Message-ID: <4B16FBCF.2060801@sunwave.net> Matthew Dodd wrote: > Apple has been shipping the Airport Extreme and Express (consumer > router) with v6 support since 2007, if I recall correctly. They can also > create a 4to6 tunnel automatically. > By 4to6 to you mean IPv4 on the inside and IPv6 on the outside? Wade Peacock Sun Country Cablevision Ltd -------------- next part -------------- A non-text attachment was scrubbed... Name: wade_peacock.vcf Type: text/x-vcard Size: 369 bytes Desc: not available URL: From nanog at daork.net Wed Dec 2 23:48:17 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 3 Dec 2009 12:48:17 +1300 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16FBCF.2060801@sunwave.net> References: <4B16F535.70306@sunwave.net> <03D7926F-D158-43C1-A1C4-E308A418B244@doddserver.com> <4B16FBCF.2060801@sunwave.net> Message-ID: <780AE0D5-9C2F-4A1F-AB6D-14907689C2A0@daork.net> On 3/12/2009, at 12:44 PM, Wade Peacock wrote: > Matthew Dodd wrote: >> Apple has been shipping the Airport Extreme and Express (consumer >> router) with v6 support since 2007, if I recall correctly. They can >> also create a 4to6 tunnel automatically. > > By 4to6 to you mean IPv4 on the inside and IPv6 on the outside? He is confused, and means 6to4. Also the airport extreme does not do DHCPv6-PD or anything (as far as I know, they certainly did not last time I tried), so I don't know that we'd really call them an IPv6 CPE in the way that I suspect Wade means. -- Nathan Ward From mdodd at doddserver.com Wed Dec 2 23:52:02 2009 From: mdodd at doddserver.com (Matthew Dodd) Date: Wed, 2 Dec 2009 18:52:02 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16FBCF.2060801@sunwave.net> References: <4B16F535.70306@sunwave.net> <03D7926F-D158-43C1-A1C4-E308A418B244@doddserver.com> <4B16FBCF.2060801@sunwave.net> Message-ID: I meant to say 6to4, sorry about that. Nothing special there. -Matt On Dec 2, 2009, at 6:44 PM, Wade Peacock wrote: > Matthew Dodd wrote: >> Apple has been shipping the Airport Extreme and Express (consumer >> router) with v6 support since 2007, if I recall correctly. They can >> also create a 4to6 tunnel automatically. > > By 4to6 to you mean IPv4 on the inside and IPv6 on the outside? > > > Wade Peacock > Sun Country Cablevision Ltd > > From patrick at ianai.net Thu Dec 3 00:00:51 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 2 Dec 2009 19:00:51 -0500 Subject: Leaving public peering? In-Reply-To: <1259790509.31045.144.camel@wks02.probe-networks.de> References: <20091202212020.GA48616@ussenterprise.ufp.org> <1259790509.31045.144.camel@wks02.probe-networks.de> Message-ID: <2CCD1680-B5AE-4777-902F-CCA19BBAF782@ianai.net> On Dec 2, 2009, at 4:48 PM, Jonas Frey wrote: > the DE-CIX pricing is now 500 Euro/month...since 1st october...see end > of that page. > Both DE-CIX and AMS-IX have decreased their pricing this year..almost at > the same time. I guess this is a move to stop company leaving public > exchanges...i have seen this trend, too. That is not why LINX lowers its prices. (I cannot say why AMS-IX lowers its prices.) LINX is a member-based organization. The member _own_ the exchange. They are paying themselves, and they only pay themselves as much as it costs to run the exchange. With more members, more scale, and advances in equipment, unit (i.e. port) costs go down. In a cost-recovery model, that means prices drop. LINX dropped prices mid-year 2009, and are dropping prices again in January 2009. AMS-IX dropped prices once in that time. DE-CIX actually raised its prices for many members, so they could lower their prices for others. Interesting strategy.... -- TTFN, patrick > On Wed, 2009-12-02 at 22:20, Leo Bicknell wrote: >> In a message written on Wed, Dec 02, 2009 at 12:46:46PM -0800, Lasher, Donn wrote: >>> I realized that paid transit is down at almost obscene levels, but is >>> that enough of a reason to increase hop-count, latencies, etc? >>> >>> Why disconnect from public mostly-free peering? >> >> Let's look at some economics. I'm going to pick on some folks here, >> solely because they have prices online and because they are, I feel, >> representative prices. >> >> http://www.cogentco.com/us/ >> >> "Home of the $4 Megabit!" So we have transit prices at $4 per megabit. >> >> http://www.de-cix.net/content/services/public-peering.html >> >> A 1GE link to the exchange is 1000 euro per month, which is $1505 USD at >> the moment, let's call it $1500 for round numbers. >> >> Now, your 1GE exchange port really shouldn't be run past 60% or so, if >> you want to provide good service. So it's really $1500 for 600Mbits, >> or $2.50 per Megabit. >> >> If you're an ISP you look at this and go, humm, I take in $4 from my >> customer, and hand $2.50 of it right back out to an exchange operator >> if I use public peering, making the exchange 62% of my costs right up >> front. On the other hand, if I choose wisely where I private peer I >> can do it at places with a one-time fee for the cable, so there is >> $0 in MRC. I have to buy a router port, sure, but it's also $0 MRC, >> just a capital asset that can get written off over many years. >> >> This is the math with the $4 megabit advertised price. The halls at >> Nanog are awash in $2 a megabit rumors if you have large enough commits >> (say, a few 10GE's). Taking in $2 and paying the exchange operator >> $2.50 of it....well, that's not so good. :) >> >> Transit prices have fallen enough that MRC's for switch ports, and >> even MRC's for fiber runs (are any of you still in a colo that wants >> $500 a month for a fiber run, I didn't think so) are eating up huge >> chunks of the inbound revenue, and thus just don't make sense. >> >> Now, before someone points it out, yes, DECIX's rate per megabit is >> lower on a 10GE and a second port, so if you can move 2 ports of 10GE of >> traffic you can make it a lot cheaper. Also, Cogents $4 a megabit is >> probably predicated on you being in the right location and having the >> right commit, if you need a DS-3 in West Nowhere you'll pay a higher >> rate, and that helps offset some of the costs. I've oversimplified, and >> it's a very complex problem for most providers; however I know many are >> looking at the fees for peering ports go from being in the noise to a >> huge part of their cost structure and that doesn't work. > > > From brandon.galbraith at gmail.com Thu Dec 3 00:24:09 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 2 Dec 2009 18:24:09 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <03D7926F-D158-43C1-A1C4-E308A418B244@doddserver.com> <4B16FBCF.2060801@sunwave.net> Message-ID: <366100670912021624p55d344d2ga6b7c438a4b632e2@mail.gmail.com> On Wed, Dec 2, 2009 at 5:52 PM, Matthew Dodd wrote: > I meant to say 6to4, sorry about that. Nothing special there. > > -Matt > > 4to6 would be a mighty nice feature on a CPE =) -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From alain_durand at cable.comcast.com Thu Dec 3 00:27:28 2009 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Wed, 02 Dec 2009 19:27:28 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <366100670912021624p55d344d2ga6b7c438a4b632e2@mail.gmail.com> Message-ID: On 12/2/09 7:24 PM, "Brandon Galbraith" wrote: > On Wed, Dec 2, 2009 at 5:52 PM, Matthew Dodd wrote: > >> > I meant to say 6to4, sorry about that. Nothing special there. >> > >> > -Matt >> > >> > > 4to6 would be a mighty nice feature on a CPE =) ===> If you are thinking about only giving a v6 address to a CPE and still offering a v4 service, there is a technology for that, it is called dual-stack lite. See http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-02.txt - Alain. From berni at birkenwald.de Thu Dec 3 00:51:53 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 3 Dec 2009 00:51:53 +0000 (UTC) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. References: <4B16F535.70306@sunwave.net> Message-ID: Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking > the topic of client equipment came up. We all commented that we have > not seen any consumer grade IPv6 enable internet gateways > (routers/firewalls), a kin to the ever popular Linksys 54G series, > DLinks , SMCs or Netgears. The AVM FRITZ!Box series that is very popular in Germany has gained initial IPv6 support on their largest box (7270) in a lab firmware some time ago http://www.avm.de/en/news/artikel/IPv6_Lab.html Regards, Bernhard From fred at cisco.com Thu Dec 3 00:54:54 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 2 Dec 2009 16:54:54 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> There are specifications for them being developed in the IETF, BBF, and Cable Labs. Basically, all of the usual suspects are interested in having product that meets needs. On Dec 2, 2009, at 3:16 PM, Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking > the topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 > enable internet gateways (routers/firewalls), a kin to the ever > popular Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa > home user are screaming for them. > > Thoughts? > > > -- > Wade Peacock > Sun Country Cablevision Ltd > From mmc at internode.com.au Thu Dec 3 02:15:17 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 3 Dec 2009 12:45:17 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> Message-ID: On 03/12/2009, at 11:24 AM, Fred Baker wrote: > There are specifications for them being developed in the IETF, BBF, and Cable Labs. Basically, all of the usual suspects are interested in having product that meets needs. I challenge the usual suspects to deliver actual working dual stack IPv6 ADSL CPE rather than feigning interest. None of the major CPE vendors appear to have a v6 plan despite your claims. We have an IPv6 dual stack trial for ADSL going on and not a single CPE from the _major consumer CPE vendors_. Come on CPE vendors - most of your run Linux in your CPEs these days. How hard is it to make it work? Someone got an image working for us with OpenWRT in his spare time in a week, surely you CPE vendors can cobble something together for people to try out in a real piece of ADSL CPE I can buy at a shop? I don't mean 6to4 or pseudo dual stack stuff. I mean real ADSL CPE with dual stack PPP and DHCPv6 in one box. MMC From randy at psg.com Thu Dec 3 02:22:38 2009 From: randy at psg.com (Randy Bush) Date: Wed, 02 Dec 2009 18:22:38 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> Message-ID: > There are specifications for them being developed in the IETF, BBF, > and Cable Labs. Basically, all of the usual suspects are interested in > having product that meets needs. > >> We had a discussion today about IPv6 today. During our open thinking >> the topic of client equipment came up. >> We all commented that we have not seen any consumer grade IPv6 >> enable internet gateways (routers/firewalls), a kin to the ever >> popular Linksys 54G series, DLinks , SMCs or Netgears. >> >> Does anyone have any leads to information about such products (In >> production or planned production)? >> >> We are thinking that most vendors are going to wait until Ma and Pa >> home user are screaming for them. fred. check your mail system. it is regurgitating email from 2001, except it is modifying the headers to have current dates. randy From mehmet at akcin.net Thu Dec 3 02:23:45 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 2 Dec 2009 18:23:45 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> Would you consider Juniper SSG5 as a Consumer Grade router? They do IPv6 and they are pretty good in general, and cheap as well. Mehmet On Dec 2, 2009, at 3:16 PM, Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a > kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. > > Thoughts? > > > -- > Wade Peacock > Sun Country Cablevision Ltd > From steve at ibctech.ca Thu Dec 3 02:25:42 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 02 Dec 2009 21:25:42 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <4B1721A6.6040306@ibctech.ca> Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking the > topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable > internet gateways (routers/firewalls), a kin to the ever popular Linksys > 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa home > user are screaming for them. For ADSL, we've been punting Ovislink gear for a few years. In the past, I've had very good results with having feature requests implemented by the firmware developers (sometimes while I'm on the phone with them, literally). I haven't pushed the v6 thing too hard yet, as our DSL is wholesale'd out, and the wholesaler(s), unlike myself, don't do IPv6. I will gladly rekindle the relationship with the Ovislink dev contacts regarding IPv6, as I'm sure they will respond if there is a show of potential hardware sales to a few ISPs larger than I am. Steve From newton at internode.com.au Thu Dec 3 02:28:38 2009 From: newton at internode.com.au (Mark Newton) Date: Thu, 3 Dec 2009 12:58:38 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> Message-ID: On 03/12/2009, at 12:45 PM, Matthew Moyle-Croft wrote: > Come on CPE vendors - most of your run Linux in your CPEs these days. How hard is it to make it work? Someone got an image working for us with OpenWRT in his spare time in a week, surely you CPE vendors can cobble something together for people to try out in a real piece of ADSL CPE I can buy at a shop? The fact that someone got OpenWRT working in less than a week of spare time makes it totally clear why the commercial vendors haven't done anything: They're just simply not interested, nothing more, nothing less. There's obviously no technical barrier whatsoever (otherwise, again, OpenWRT wouldn't work). If it can be done in a week of developer time there's barely even an economic barrier. It's just disinterest. Linksys, being owned by the world's largest router vendor and being confronted with actual independently-developed working code for their hardware platforms, have the least excuse out of any of them. Years and years of talk, and no customer-visible action whatsoever. What an exceptionally ordinary performance. See you in Melbourne next week, Fred :) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From newton at internode.com.au Thu Dec 3 02:30:24 2009 From: newton at internode.com.au (Mark Newton) Date: Thu, 3 Dec 2009 13:00:24 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> Message-ID: <3F8522A0-F5C7-4BB3-B32D-F830FD5A4715@internode.com.au> On 03/12/2009, at 12:53 PM, Mehmet Akcin wrote: > Would you consider Juniper SSG5 as a Consumer Grade router? Depends. Can I get one at Frys for $69.95 and set it up with a web browser? - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From lists at billfehring.com Thu Dec 3 02:35:43 2009 From: lists at billfehring.com (Bill Fehring) Date: Wed, 2 Dec 2009 18:35:43 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> Message-ID: On Wed, Dec 2, 2009 at 18:23, Mehmet Akcin wrote: > Would you consider Juniper SSG5 as a Consumer Grade router? No. Way too expensive and virtually 100% of consumers would not be able to install it on their own. From newton at internode.com.au Thu Dec 3 02:41:05 2009 From: newton at internode.com.au (Mark Newton) Date: Thu, 3 Dec 2009 13:11:05 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F66E.70602@gmail.com> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> Message-ID: <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> On 03/12/2009, at 9:51 AM, Dave Temkin wrote: > You're correct, out of the box there aren't many. The first couple that come to mind are the Apple Airport Express and Airport Extreme, but I don't believe Linksys/Netgear/etc. have support out of the box. The Apple products do 6to4 out of the box, but don't support v6 natively. Apple seems to have ideological objections to DHCPv6, so at the moment there's little hope at all that prefix delegation will work on any of their CPE products. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From mehmet at akcin.net Thu Dec 3 02:49:50 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 2 Dec 2009 18:49:50 -0800 Subject: Leaving public peering? In-Reply-To: <2CCD1680-B5AE-4777-902F-CCA19BBAF782@ianai.net> References: <20091202212020.GA48616@ussenterprise.ufp.org> <1259790509.31045.144.camel@wks02.probe-networks.de> <2CCD1680-B5AE-4777-902F-CCA19BBAF782@ianai.net> Message-ID: <35CCE92D-F238-44BF-8A5C-F1E7B8E672F2@akcin.net> On Dec 2, 2009, at 4:00 PM, Patrick W. Gilmore wrote: > On Dec 2, 2009, at 4:48 PM, Jonas Frey wrote: > >> the DE-CIX pricing is now 500 Euro/month...since 1st october...see end >> of that page. >> Both DE-CIX and AMS-IX have decreased their pricing this year..almost at >> the same time. I guess this is a move to stop company leaving public >> exchanges...i have seen this trend, too. > > That is not why LINX lowers its prices. (I cannot say why AMS-IX lowers its prices.) > > LINX is a member-based organization. The member _own_ the exchange. They are paying themselves, and they only pay themselves as much as it costs to run the exchange. With more members, more scale, and advances in equipment, unit (i.e. port) costs go down. > > In a cost-recovery model, that means prices drop. > > LINX dropped prices mid-year 2009, and are dropping prices again in January 2009. AMS-IX dropped prices once in that time. DE-CIX actually raised its prices for many members, so they could lower their prices for others. Interesting strategy.... Yeah I have had researched multiple exchange points across the world in recent months and i can say, not only AMS-IX / DE-CIX but pretty much everyone out there is lowering the prices, it might be because of few reasons, lifted regulations from governments regarding laying new fiber, and operations.. economic reasons, operational advantages vs cost... I am sure all Exchange management have considered those and started re-pricing their service offerings. The other thing people also notices that, you really never are able to get to a big network if you are a small one via exchange due to peering requirements of these big ISPs, so they rather go and get transit and don't worry about maintaining peering sessions with something+ number of peers, but simply 2-3 transit providers who have decently been chosen. Also with a good homework, you can practically achieve great results that way... still sad to see a lot departing from public exchange points.. Mehmet From jmamodio at gmail.com Thu Dec 3 02:53:25 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 2 Dec 2009 20:53:25 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <3F8522A0-F5C7-4BB3-B32D-F830FD5A4715@internode.com.au> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <3F8522A0-F5C7-4BB3-B32D-F830FD5A4715@internode.com.au> Message-ID: <202705b0912021853o14cfa9bevcbe64ef705979e26@mail.gmail.com> On Wed, Dec 2, 2009 at 8:30 PM, Mark Newton wrote: > > On 03/12/2009, at 12:53 PM, Mehmet Akcin wrote: > >> Would you consider Juniper SSG5 as a Consumer Grade router? > > Depends. ?Can I get one at Frys for $69.95 and set it up with > a web browser? That would be cool, a nice box running JUNOS for seventy bucks, gimme two !! Cheers Jorge From mehmet at akcin.net Thu Dec 3 02:56:37 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 2 Dec 2009 18:56:37 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <202705b0912021853o14cfa9bevcbe64ef705979e26@mail.gmail.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <3F8522A0-F5C7-4BB3-B32D-F830FD5A4715@internode.com.au> <202705b0912021853o14cfa9bevcbe64ef705979e26@mail.gmail.com> Message-ID: <0C78804E-425B-4A33-A882-534C7CA5001E@akcin.net> On Dec 2, 2009, at 6:53 PM, Jorge Amodio wrote: > On Wed, Dec 2, 2009 at 8:30 PM, Mark Newton wrote: >> >> On 03/12/2009, at 12:53 PM, Mehmet Akcin wrote: >> >>> Would you consider Juniper SSG5 as a Consumer Grade router? >> >> Depends. Can I get one at Frys for $69.95 and set it up with >> a web browser? > > That would be cool, a nice box running JUNOS for seventy bucks, gimme two !! Noted on the christmas tree for santa ;) let's see if it will happen.. SSG5s are still on ScreenOS and going to be..., SRX series run JunOS but little too pricey for a home router :) > > Cheers > Jorge From frnkblk at iname.com Thu Dec 3 02:57:19 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Dec 2009 20:57:19 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: I think they're (all) listed here: http://www.getipv6.info/index.php/Broadband_CPE Frank -----Original Message----- From: Wade Peacock [mailto:wade.peacock at sunwave.net] Sent: Wednesday, December 02, 2009 5:16 PM To: nanog at nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts? -- Wade Peacock Sun Country Cablevision Ltd From sethm at rollernet.us Thu Dec 3 03:01:23 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Dec 2009 19:01:23 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> Message-ID: <4B172A03.3090500@rollernet.us> Bill Fehring wrote: > On Wed, Dec 2, 2009 at 18:23, Mehmet Akcin wrote: >> Would you consider Juniper SSG5 as a Consumer Grade router? > > No. Way too expensive and virtually 100% of consumers would not be > able to install it on their own. > If they can't plug it in (that's a huge task on its own for many people) and it "just works", it's not consumer grade. Yes, even if that means a billion "linksys" SSIDs on channel 6. ~Seth From mmc at internode.com.au Thu Dec 3 03:12:49 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 3 Dec 2009 13:42:49 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> Message-ID: <88D60989-9422-4722-B44A-7BECCED77E30@internode.com.au> I note that a lot of those have IPv6 support because of 3rd party DDWRT images :-) A lot of them support 6to4 only - and often quite poorly. MMC On 03/12/2009, at 1:27 PM, Frank Bulk wrote: > I think they're (all) listed here: > http://www.getipv6.info/index.php/Broadband_CPE > > Frank > > -----Original Message----- > From: Wade Peacock [mailto:wade.peacock at sunwave.net] > Sent: Wednesday, December 02, 2009 5:16 PM > To: nanog at nanog.org > Subject: Consumer Grade - IPV6 Enabled Router Firewalls. > > We had a discussion today about IPv6 today. During our open thinking the > topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable > internet gateways (routers/firewalls), a > kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In production > or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa home > user are screaming for them. > > Thoughts? > > > -- > Wade Peacock > Sun Country Cablevision Ltd > > -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From chris at uplogon.com Thu Dec 3 03:14:43 2009 From: chris at uplogon.com (Chris Gotstein) Date: Wed, 02 Dec 2009 21:14:43 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <4B172D23.6020808@uplogon.com> A Mikrotik Routerboard supports IPv6. Fairly cheap, under $100. But not easy enough for a novice home user to configure on their own. Could be a good cpe if it was pre-configured from the service provider though. I use a MT box at home which serves as my router, dual stack, and then set's up an IPv6 tunnel to SIXXS. Very stable platform. Only drawback is the lack of support for IPv6 over PPP. -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP Iron Mountain, MI 49801 Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking the > topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable > internet gateways (routers/firewalls), a kin to the ever popular Linksys > 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa home > user are screaming for them. > > Thoughts? > > From Valdis.Kletnieks at vt.edu Thu Dec 3 03:52:22 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Dec 2009 22:52:22 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: Your message of "Wed, 02 Dec 2009 12:38:54 CST." <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <20091202183124.GA25056@gsp.org> <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> Message-ID: <20145.1259812342@turing-police.cc.vt.edu> On Wed, 02 Dec 2009 12:38:54 CST, Chris Owen said: > On Dec 2, 2009, at 12:31 PM, Rich Kulawiec wrote: > > > Because SenderID and SPF have no anti-spam value, and almost no > > anti-forgery value. Not that this stops a *lot* of people who've drunk > > the kool-aid from trying to use them anyway, > > OK, I'll bite--How exactly do you go about forging email from my domain > name if the host receiving it is checking SPF? It only stops forgery if the SPF record has a -all in it (as hubris.net does). However, a lot of domains (mine included) have a ~all instead. (And before anybody asks, yes ~all is what we want, and no you can't ask us to try -all instead, unless we're allowed to send you all the helpdesk calls about misconfigured migratory laptops".. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cmadams at hiwaay.net Thu Dec 3 03:56:13 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 2 Dec 2009 21:56:13 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <0C78804E-425B-4A33-A882-534C7CA5001E@akcin.net> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <3F8522A0-F5C7-4BB3-B32D-F830FD5A4715@internode.com.au> <202705b0912021853o14cfa9bevcbe64ef705979e26@mail.gmail.com> <0C78804E-425B-4A33-A882-534C7CA5001E@akcin.net> Message-ID: <20091203035613.GC1394240@hiwaay.net> Once upon a time, Mehmet Akcin said: > Noted on the christmas tree for santa ;) let's see if it will happen.. > SSG5s are still on ScreenOS and going to be..., SRX series run JunOS > but little too pricey for a home router :) I think the SRX100 is the intended replacement for the SSG5. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From owen at delong.com Thu Dec 3 04:41:41 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Dec 2009 20:41:41 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: I believe that the Fritz box and the Apple Airport series gateways both qualify, although there is a price difference on the Apple gear. I am not sure about the price of the Fritz. Owen On Dec 2, 2009, at 3:16 PM, Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking > the topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 > enable internet gateways (routers/firewalls), a kin to the ever > popular Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa > home user are screaming for them. > > Thoughts? > > > -- > Wade Peacock > Sun Country Cablevision Ltd > From owen at delong.com Thu Dec 3 04:56:38 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Dec 2009 20:56:38 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: On Dec 2, 2009, at 6:41 PM, Mark Newton wrote: > > On 03/12/2009, at 9:51 AM, Dave Temkin wrote: > >> You're correct, out of the box there aren't many. The first couple >> that come to mind are the Apple Airport Express and Airport >> Extreme, but I don't believe Linksys/Netgear/etc. have support out >> of the box. > > The Apple products do 6to4 out of the box, but don't support v6 > natively. > What do you mean they don't support v6 native? I am running my Time Capsule in v6 native. > Apple seems to have ideological objections to DHCPv6, so at the moment > there's little hope at all that prefix delegation will work on any > of their > CPE products. > True none of the apple products support DHCPv6. I think there is some hope Apple will come around on this issue. Owen From netfortius at gmail.com Thu Dec 3 05:05:40 2009 From: netfortius at gmail.com (Stefan) Date: Wed, 2 Dec 2009 23:05:40 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: Probably the same time they'll figure out the over-3-yrs-old IGMP ver3 support (for a *multimedia-oriented* company, multicast seem to still be foreign ... oh, well...) ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Wed, Dec 2, 2009 at 10:56 PM, Owen DeLong wrote: > > On Dec 2, 2009, at 6:41 PM, Mark Newton wrote: > > >> On 03/12/2009, at 9:51 AM, Dave Temkin wrote: >> >> You're correct, out of the box there aren't many. The first couple that >>> come to mind are the Apple Airport Express and Airport Extreme, but I don't >>> believe Linksys/Netgear/etc. have support out of the box. >>> >> >> The Apple products do 6to4 out of the box, but don't support v6 natively. >> >> What do you mean they don't support v6 native? > > I am running my Time Capsule in v6 native. > > > Apple seems to have ideological objections to DHCPv6, so at the moment >> there's little hope at all that prefix delegation will work on any of >> their >> CPE products. >> >> True none of the apple products support DHCPv6. I think there is some > hope Apple will come around > on this issue. > > Owen > > > From newton at internode.com.au Thu Dec 3 05:25:49 2009 From: newton at internode.com.au (Mark Newton) Date: Thu, 3 Dec 2009 15:55:49 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: On 03/12/2009, at 3:26 PM, Owen DeLong wrote: >>> You're correct, out of the box there aren't many. The first couple that come to mind are the Apple Airport Express and Airport Extreme, but I don't believe Linksys/Netgear/etc. have support out of the box. >> >> The Apple products do 6to4 out of the box, but don't support v6 natively. >> > What do you mean they don't support v6 native? > I am running my Time Capsule in v6 native. Okay, let me rephrase that. I can't run a PPPoE client on an Airport Express which will give me native dual-stack Internet access. Yes, I can talk to the Airport Express with v6, no debate there. And yes, if it sees an RA message it'll configure itself with the appropriate prefix EUI64 itself an address. But unless there's some configuration knob I haven't found, off-LAN v6 access requires either some other v6-capable CPE to act as the interface to the service provider, or it runs over 6to4. > True none of the apple products support DHCPv6. I think there is some hope Apple will come around on this issue. Currently the Snow Leopard kernel panics if you turn on the net.inet6.ip6.accept_rtadv sysctl and start a PPPoE session which negotiates IP6CP. (I have a bug open with them, and I'm confident that it'll be fixed... but c'mon...!) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From randy at psg.com Thu Dec 3 05:50:07 2009 From: randy at psg.com (Randy Bush) Date: Wed, 02 Dec 2009 21:50:07 -0800 Subject: FTTH Active vs Passive In-Reply-To: References: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> <4B1547BD.6050004@justinshore.com> <20091201171435.GH4453@dan.olp.net> <620fd17c0912011133r13a993eer72e3da41e8e529f9@mail.gmail.com> <3c857e1c0912011207g1bf7957ar1bc8f920ce89ab44@mail.gmail.com> <69069bc20912012258q77a6c144g92fedd4e2ce00570@mail.gmail.com> Message-ID: > Pricing aside, do you feel the Japanese have a good architecture for the > last mile? Would it adapt well from an environment that is mostly > multi-dwelling units (MDU) to one which is mostly single-dwelling units? > Any thoughts on good places to start for an english language speaker to > learn about the Japanese broadband experience? not much help here. what ntt says is mostly gloss and some (miyakawa) runs on the ppt platform, not reality. randy From owenc at hubris.net Thu Dec 3 06:25:23 2009 From: owenc at hubris.net (Chris Owen) Date: Thu, 3 Dec 2009 00:25:23 -0600 Subject: AT&T SMTP Admin contact? In-Reply-To: <20145.1259812342@turing-police.cc.vt.edu> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <20091202183124.GA25056@gsp.org> <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> <20145.1259812342@turing-police.cc.vt.edu> Message-ID: <073D5290-1115-4AA5-8B7D-E4D8695BB833@hubris.net> On Dec 2, 2009, at 9:52 PM, Valdis.Kletnieks at vt.edu wrote: > It only stops forgery if the SPF record has a -all in it (as hubris.net does). > However, a lot of domains (mine included) have a ~all instead. I guess I've never really seen the point of publishing a SPF record if it ends in ~all. What are people supposed to do with that info? Spamassassin assigns it a score of 0.6 but that is low enough it really doesn't have much since it doesn't assign any negative points for SPF_PASS. > (And before anybody asks, yes ~all is what we want, and no you can't ask us > to try -all instead, unless we're allowed to send you all the helpdesk calls > about misconfigured migratory laptops".. ;) I certainly understand that you may not be able to lock down your domain. We don't even try for customers for instance. However, if you can't, I guess I don't really see what good publishing a SPF record is if you tell people not to enforce it. Chris ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From ops.lists at gmail.com Thu Dec 3 06:41:49 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 3 Dec 2009 12:11:49 +0530 Subject: AT&T SMTP Admin contact? In-Reply-To: <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <20091202183124.GA25056@gsp.org> <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> Message-ID: On Thu, Dec 3, 2009 at 12:08 AM, Chris Owen wrote: > On Dec 2, 2009, at 12:31 PM, Rich Kulawiec wrote: > >> Because SenderID and SPF have no anti-spam value, and almost no >> anti-forgery value. ?Not that this stops a *lot* of people who've drunk >> the kool-aid from trying to use them anyway, > > OK, I'll bite--How exactly do you go about forging email from my domain name if the host receiving it is checking SPF? Dont let me stop you playing russian roulette with your users' email. From johnl at iecc.com Thu Dec 3 06:42:58 2009 From: johnl at iecc.com (John Levine) Date: 3 Dec 2009 06:42:58 -0000 Subject: AT&T SMTP Admin contact? In-Reply-To: <073D5290-1115-4AA5-8B7D-E4D8695BB833@hubris.net> Message-ID: <20091203064258.22870.qmail@simone.iecc.com> >I guess I've never really seen the point of publishing a SPF record if >it ends in ~all. What are people supposed to do with that info? Get your mail delivered to Hotmail, the last significant outpost of SPF/Sender-ID. Other than that, I agree it's useless. I also agree that any domain with live users (as opposed to mail cannons sending ads or transaction confirmations) is likely to experience pain with -all from all the overenthusiastic little MTAs whose managers imagine that "stopping forgery" will lessen their spam load rather than losing mail from roaming users. R's, John From sethm at rollernet.us Thu Dec 3 06:51:38 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Dec 2009 22:51:38 -0800 Subject: AT&T SMTP Admin contact? In-Reply-To: <20091203064258.22870.qmail@simone.iecc.com> References: <20091203064258.22870.qmail@simone.iecc.com> Message-ID: <4B175FFA.5040103@rollernet.us> John Levine wrote: >> I guess I've never really seen the point of publishing a SPF record if >> it ends in ~all. What are people supposed to do with that info? > > Get your mail delivered to Hotmail, the last significant outpost of > SPF/Sender-ID. Other than that, I agree it's useless. > > I also agree that any domain with live users (as opposed to mail > cannons sending ads or transaction confirmations) is likely to > experience pain with -all from all the overenthusiastic little MTAs > whose managers imagine that "stopping forgery" will lessen their spam > load rather than losing mail from roaming users. > In all fairness, the roaming users problem isn't a problem when one uses smtp auth and a constant submission point. ~Seth From owenc at hubris.net Thu Dec 3 06:53:26 2009 From: owenc at hubris.net (Chris Owen) Date: Thu, 3 Dec 2009 00:53:26 -0600 Subject: AT&T SMTP Admin contact? In-Reply-To: <20091203064258.22870.qmail@simone.iecc.com> References: <20091203064258.22870.qmail@simone.iecc.com> Message-ID: <90ED1F8E-0673-404E-8A26-9405AFD64393@hubris.net> On Dec 3, 2009, at 12:42 AM, John Levine wrote: > I also agree that any domain with live users (as opposed to mail > cannons sending ads or transaction confirmations) is likely to > experience pain with -all from all the overenthusiastic little MTAs > whose managers imagine that "stopping forgery" will lessen their spam > load rather than losing mail from roaming users. Again I guess I don't understand. How are these MTA managers being "overenthusiastic"? Publishing a SPF (with -all) is essentially me requesting that they reject any mail from my domain not coming from one of the approved hosts. I'm the one making the decision to ask them to bounce such mail. Seems to me they are only being responsible in actually enforcing a policy that I set for the domain. Chris ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From mohacsi at niif.hu Thu Dec 3 08:00:00 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 3 Dec 2009 09:00:00 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: On Thu, 3 Dec 2009, Mark Newton wrote: > > On 03/12/2009, at 9:51 AM, Dave Temkin wrote: > >> You're correct, out of the box there aren't many. The first couple that come to mind are the Apple Airport Express and Airport Extreme, but I don't believe Linksys/Netgear/etc. have support out of the box. > > The Apple products do 6to4 out of the box, but don't support v6 natively. > > Apple seems to have ideological objections to DHCPv6, so at the moment > there's little hope at all that prefix delegation will work on any of their > CPE products. According to Apple the latest Apple Airport Extreme does support DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. Best Regards, Janos Mohacsi From joelja at bogus.com Thu Dec 3 08:26:00 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 03 Dec 2009 00:26:00 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <4B177618.90308@bogus.com> Wade Peacock wrote: > We had a discussion today about IPv6 today. During our open thinking the > topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable > internet gateways (routers/firewalls), a kin to the ever popular Linksys > 54G series, DLinks , SMCs or Netgears. Do you have an apple airport extreme or a linksys wrt610n? the WRTs of the world all 40 or so of the variants of that thing that have ever existed are rather old and in many cases bizarrely resource limited. > Does anyone have any leads to information about such products (In > production or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa home > user are screaming for them. Vendors are in business of stimulating the replacement cycle by adding features... right now the magic words are gigabit ethernet and 802.11n. Chances are ma and pa won't even know they device they has ipv6 (do they know it has ipv4?) unless it has a big-ass sticker on the outside of the box. like this i/o data ap from 2006... http://akiba-pc.watch.impress.co.jp/hotline/20060923/image/m060920r34.html > Thoughts? you next wirelss ap has 2-6 radio phys an 800mhz mips processor and 64MB of ram, there's a lot of thing it can do that your old one can't > From mmc at internode.com.au Thu Dec 3 08:45:46 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 03 Dec 2009 19:15:46 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: <4B177ABA.70203@internode.com.au> Mohacsi Janos wrote: > > > According to Apple the latest Apple Airport Extreme does support > DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. Airports don't support DHCPv6 PD yet. I'm led to believe that they may in the future from my Apple friends but not yet. MMC From cesar.olvera at consulintel.es Thu Dec 3 09:09:51 2009 From: cesar.olvera at consulintel.es (Cesar Olvera) Date: Thu, 3 Dec 2009 10:09:51 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. Message-ID: <005901ca73f8$5ff02de0$1fd089a0$@olvera@consulintel.es> A list of CPEs, routers, firewalls and other hardware and software are at http://www.ipv6-to-standard.org/ C?sar Olvera -----Original Message----- From: Wade Peacock [mailto:wade.peacock at sunwave.net] Sent: Wednesday, December 02, 2009 5:16 PM To: nanog at nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts? -- Wade Peacock Sun Country Cablevision Ltd ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From sean at donelan.com Thu Dec 3 10:11:46 2009 From: sean at donelan.com (Sean Donelan) Date: Thu, 3 Dec 2009 05:11:46 -0500 (EST) Subject: AT&T SMTP Admin contact? In-Reply-To: <20145.1259812342@turing-police.cc.vt.edu> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <20091202183124.GA25056@gsp.org> <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> <20145.1259812342@turing-police.cc.vt.edu> Message-ID: <200912030353010.6B95064B.29293@clifden.donelan.com> On Wed, 2 Dec 2009, Valdis.Kletnieks at vt.edu wrote: > (And before anybody asks, yes ~all is what we want, and no you can't ask us > to try -all instead, unless we're allowed to send you all the helpdesk calls > about misconfigured migratory laptops".. ;) While I'll remain neutral about the specifics of SPF (and all the other solutions), the legacy problem comes up trying to secure any thing. If it (and I deliberately leave "it" undefined) had never worked, no one would complain. Of course, there will always be someone who goes too one extreme or the other extreme. People were dropping heavily spoofed domains before SPF anyway. At what point do we consider legacy support not worth it? It took 10+ years, but now almost no SMTP servers allow open relay by default. Will it take another 10+ years to stop supporting misconfigured migratory laptops by default? From mohacsi at niif.hu Thu Dec 3 11:53:23 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 3 Dec 2009 12:53:23 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B177ABA.70203@internode.com.au> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <4B177ABA.70203@internode.com.au> Message-ID: On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: > > > Mohacsi Janos wrote: >> >> >> According to Apple the latest Apple Airport Extreme does support DHCPv6 >> prefix delegation and native IPv6 uplink not only 6to4. > Airports don't support DHCPv6 PD yet. I'm led to believe that they may in > the future from my Apple friends but not yet. It does in a limited extent: http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html I will check soon the hardware. Best Regards, Janos Mohacsi From trejrco at gmail.com Thu Dec 3 12:16:24 2009 From: trejrco at gmail.com (TJ) Date: Thu, 3 Dec 2009 07:16:24 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: <01f001ca7412$6f53d9c0$4dfb8d40$@com> > From: Mark Newton [mailto:newton at internode.com.au] > On 03/12/2009, at 9:51 AM, Dave Temkin wrote: > > > You're correct, out of the box there aren't many. The first couple that > > come to mind are the Apple Airport Express and Airport Extreme, but I don't > > believe Linksys/Netgear/etc. have support out of the box. > > The Apple products do 6to4 out of the box, but don't support v6 natively. FWIW - The (Cisco) Linksys 610N does (and perhaps others do?) the same amount of IPv6 the Airport Extreme does - 6to4, SLAAC - out of the box, by default. In fact, I am not sure you can turn it off ... /TJ From jnegro at billtrust.com Thu Dec 3 13:04:04 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Thu, 3 Dec 2009 08:04:04 -0500 Subject: Comcast outage in central NJ Message-ID: <3C5B084431653D4A9C469A22AFCDB5B9042926E8@LOGAN.billtrust.local> There appears to be a Comcast outage in central NJ, more specifically in the South Brunswick area. Comcast appears to be aware of the outage as per the message I got when I called them. Anyone hear any details on the issue, or an ETA for repair yet? Jeffrey From newton at internode.com.au Thu Dec 3 13:08:56 2009 From: newton at internode.com.au (Mark Newton) Date: Thu, 3 Dec 2009 23:38:56 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <01f001ca7412$6f53d9c0$4dfb8d40$@com> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <01f001ca7412$6f53d9c0$4dfb8d40$@com> Message-ID: <1C9EF593-91C4-445C-8EE7-7671509E51FF@internode.com.au> On 03/12/2009, at 22:46, "TJ" wrote: >> From: Mark Newton [mailto:newton at internode.com.au] >> On 03/12/2009, at 9:51 AM, Dave Temkin wrote: >> >>> You're correct, out of the box there aren't many. The first >>> couple that >>> come to mind are the Apple Airport Express and Airport Extreme, >>> but I > don't >>> believe Linksys/Netgear/etc. have support out of the box. >> >> The Apple products do 6to4 out of the box, but don't support v6 >> natively. > > FWIW - The (Cisco) Linksys 610N does (and perhaps others do?) the same > amount of IPv6 the Airport Extreme does - 6to4, SLAAC - out of the > box, by > default. In fact, I am not sure you can turn it off .. Yep -- which is worse than useless in the presence of a service provider that's already offering dual-stack service. "Here! Have a v6 address. We'll even give you a moderately large prefix if you run a DHCPv6-PD client... Oh, what? You're going to ignore all that and use a 6to4 gateway and pessimize the v6 routing decisions we've made? And live in one /64 even though every man and his dog reckons service providers ought to be handing out /56's or / 48's? Gee, glad we went to the effort..." Sadly the easiest way for residential subscribers to get IPv6 on PPPoE in 2009 is to put their CPE into "bridge" mode and run the PPPoE client on a PC. The vendors have really dropped the ball on this. (glares at Cisco/Linksys) - mark From jnegro at billtrust.com Thu Dec 3 14:27:15 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Thu, 3 Dec 2009 09:27:15 -0500 Subject: Comcast outage in central NJ In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B9042926E8@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B9042926E8@LOGAN.billtrust.local> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B90429271B@LOGAN.billtrust.local> Update - Comcast repaired the problem. Not sure if there are other areas still with problems though. Jeffrey -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Thursday, December 03, 2009 8:04 AM To: NANOG Subject: Comcast outage in central NJ There appears to be a Comcast outage in central NJ, more specifically in the South Brunswick area. Comcast appears to be aware of the outage as per the message I got when I called them. Anyone hear any details on the issue, or an ETA for repair yet? Jeffrey From andy at nosignal.org Thu Dec 3 15:20:49 2009 From: andy at nosignal.org (Andy Davidson) Date: Thu, 3 Dec 2009 15:20:49 +0000 Subject: Leaving public peering? In-Reply-To: References: Message-ID: <3730EC8D-229B-4336-9F63-7221074AB3DA@nosignal.org> On 2 Dec 2009, at 20:46, Lasher, Donn wrote: > This year I've been seeing what appears to be an increasing trend > among > service providers.. making the decision to leave public peering. Peering is often sold as 'cheaper than transit' - for everyone that is a gross generalisation, for many networks it is not true, but for some networks it is true. But when managed properly peering should always lead to improved customer experience (speed of access, latency, availability) and access to a community of like minded operators with a common interest. Therefore, certainly in Europe, we are seeing a growth in the number of networks peering - and from an ever increasingly wide section of the community (service providers, content, e-commerce, enterprise, gaming, education/research networks...). And with a falling cost in long haul transmission we are seeing networks in Europe peer mode in the US, and networks from all over the world peering in Europe. Check out this report on the success of peering : https://www.euro-ix.net/member/m/document/showDocument/id/158 .... and then talk to exchange operators in the community about how you too can get involved. :-) -- Regards, Andy Davidson Director, LONAP Ltd http://www.lonap.net/ From tvest at eyeconomics.com Thu Dec 3 15:51:07 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 3 Dec 2009 10:51:07 -0500 Subject: Comcast outage in central NJ In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B90429271B@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B9042926E8@LOGAN.billtrust.local> <3C5B084431653D4A9C469A22AFCDB5B90429271B@LOGAN.billtrust.local> Message-ID: <1936F4F9-E1E8-4B2E-852F-500EC3F19F00@eyeconomics.com> There was a total outage for 6+ hours in at least one Richmond VA neighborhood yesterday, ending around 6:00PM. Cable STB software had clearly been updated when everything came back up, but I have no idea whether the two events were related. TV On Dec 3, 2009, at 9:27 AM, Jeffrey Negro wrote: > Update - Comcast repaired the problem. Not sure if there are other > areas still with problems though. > > Jeffrey > > -----Original Message----- > From: Jeffrey Negro [mailto:jnegro at billtrust.com] > Sent: Thursday, December 03, 2009 8:04 AM > To: NANOG > Subject: Comcast outage in central NJ > > There appears to be a Comcast outage in central NJ, more > specifically in > the South Brunswick area. Comcast appears to be aware of the outage > as > per the message I got when I called them. Anyone hear any details on > the issue, or an ETA for repair yet? > > > > Jeffrey > From math at sizone.org Thu Dec 3 15:53:46 2009 From: math at sizone.org (Ken Chase) Date: Thu, 3 Dec 2009 10:53:46 -0500 Subject: Leaving public peering? In-Reply-To: <3730EC8D-229B-4336-9F63-7221074AB3DA@nosignal.org> References: <3730EC8D-229B-4336-9F63-7221074AB3DA@nosignal.org> Message-ID: <20091203155346.GJ8192@sizone.org> >Check out this report on the success of peering : >https://www.euro-ix.net/member/m/document/showDocument/id/158 This seems to be a protected document behind login-only section of the site. Can anyone comment on wether the document should be publically accessible? Would love to spread it around. Thank you. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From mhuff at ox.com Thu Dec 3 17:05:09 2009 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Dec 2009 12:05:09 -0500 Subject: port scanning from spoofed addresses Message-ID: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> We are seeing a large number of tcp connection attempts to ports known to have security issues. The source addresses are spoofed from our address range. They are easy to block at our border router obviously, but the number and volume is a bit worrisome. Our upstream providers appear to be uninterested in tracing or blocking them. Is this the new normal? One of my concerns is that if others are seeing probe attempts, they will see them from these addresses and of course, contact us. Any suggestions on what to do next? Or just ignore. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From chris.stebner at gmail.com Thu Dec 3 17:10:57 2009 From: chris.stebner at gmail.com (Chris Stebner) Date: Thu, 3 Dec 2009 10:10:57 -0700 Subject: Calling Comcast Postmaster or whomever actually is responsible for Comcast RBL maintenance Message-ID: <941190370912030910v71b3f0c6p33e44488cc4a2370@mail.gmail.com> For over a month now I've been fighting with Comcast Customer Security Assurance regarding a simple BlackList issue. Apparently there is some disconnect between internal applications and their ability to report BlackList status accurately and the 'actual' BlackList rule-set. Supposedly the ticket has been escalated to 'admin' and 'engineering' multiple times to no avail. Currently we are waiting for engineering again to examine the issue. The block is owned by us, a facilities based CLEC in business for over 10 years. The /24 in question is used for business T1's. If anyone has any contacts, ideas or the power to resolve the issue I'd be elated to hear from you. Thank you all for your time, Chris Stebner 970-403-0102 From fweimer at bfk.de Thu Dec 3 17:35:14 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Dec 2009 17:35:14 +0000 Subject: port scanning from spoofed addresses In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> (Matthew Huff's message of "Thu\, 3 Dec 2009 12\:05\:09 -0500") References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> Message-ID: <823a3sarl9.fsf@mid.bfk.de> * Matthew Huff: > We are seeing a large number of tcp connection attempts to ports > known to have security issues. The source addresses are spoofed from > our address range. They are easy to block at our border router > obviously, but the number and volume is a bit worrisome. Our > upstream providers appear to be uninterested in tracing or blocking > them. Is this the new normal? One of my concerns is that if others > are seeing probe attempts, they will see them from these addresses > and of course, contact us. What's the distribution of the source addresses and source ports? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From sfouant at shortestpathfirst.net Thu Dec 3 17:39:25 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 3 Dec 2009 12:39:25 -0500 Subject: port scanning from spoofed addresses In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> Message-ID: <00b301ca743f$8ed250b0$ac76f210$@net> > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Thursday, December 03, 2009 12:05 PM > > but the number and volume is a bit worrisome. Our upstream providers > appear to be uninterested in tracing or blocking them. Is this the new > normal? Yes, it's the new norm... same as the old norm... I'm surprised they didn't try to upsell you on some type of managed DDoS solution... Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From tme at americafree.tv Thu Dec 3 17:45:54 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 3 Dec 2009 12:45:54 -0500 Subject: Flash Media Servers as Open Proxies Message-ID: I recently found out that the Adobe Flash Media Server (FMS) can operate "out of the box" as an open proxy, enabling other people to steal server resources and bandwidth. Furthermore, I also found that there is an ecosystem of pirates taking advantage of this "feature" to illegally stream sports events (and maybe other stuff as well). Each event uses multiple (stolen) servers and can amount to thousands of streams and Gbps of consumed bandwidth. I believe but am not 100% sure that there are similar problems with Window Media Servers. I would like to hear (off-list) from people who have experience fighting this so that we could maybe pool techniques. I will try to write this up further later. Regards Marshall Eubanks From mhuff at ox.com Thu Dec 3 17:53:04 2009 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Dec 2009 12:53:04 -0500 Subject: port scanning from spoofed addresses In-Reply-To: <823a3sarl9.fsf@mid.bfk.de> References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> <823a3sarl9.fsf@mid.bfk.de> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D775E7EE2C@PUR-EXCH07.ox.com> The source address appears to be fixed as well as the source port (6666), scanning different destinations and ports. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -----Original Message----- From: Florian Weimer [mailto:fweimer at bfk.de] Sent: Thursday, December 03, 2009 12:35 PM To: Matthew Huff Cc: (nanog at nanog.org) Subject: Re: port scanning from spoofed addresses * Matthew Huff: > We are seeing a large number of tcp connection attempts to ports > known to have security issues. The source addresses are spoofed from > our address range. They are easy to block at our border router > obviously, but the number and volume is a bit worrisome. Our > upstream providers appear to be uninterested in tracing or blocking > them. Is this the new normal? One of my concerns is that if others > are seeing probe attempts, they will see them from these addresses > and of course, contact us. What's the distribution of the source addresses and source ports? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From charles at thewybles.com Thu Dec 3 17:59:20 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 3 Dec 2009 09:59:20 -0800 Subject: Flash Media Servers as Open Proxies In-Reply-To: References: Message-ID: Hmmmm.. This is most interesting. Have you spoken with Adobe about the issue? I don't have an immediate handle on how they have reacted to security issues in the past. Sane defaults would be nice. :( You might want to ping Akami as they have substantial operational experience with flash media server. I look forward to a writeup on the topic. On Dec 3, 2009, at 9:45 AM, Marshall Eubanks wrote: > I recently found out that the Adobe Flash Media Server (FMS) can operate "out of the box" > as an open proxy, enabling other people to steal server resources and bandwidth. Furthermore, > I also found that there is an ecosystem of pirates taking advantage of this "feature" to > illegally stream sports events (and maybe other stuff as well). Each event uses multiple (stolen) > servers and can amount to thousands of streams and Gbps of consumed bandwidth. > > I believe but am not 100% sure that there are similar problems with Window Media Servers. > > I would like to hear (off-list) from people who have experience fighting this so that we could > maybe pool techniques. I will try to write this up further later. > > Regards > Marshall Eubanks > From charles at thewybles.com Thu Dec 3 18:00:32 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 3 Dec 2009 10:00:32 -0800 Subject: port scanning from spoofed addresses In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D775E7EE2C@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> <823a3sarl9.fsf@mid.bfk.de> <483E6B0272B0284BA86D7596C40D29F9D775E7EE2C@PUR-EXCH07.ox.com> Message-ID: <68F8A2BA-0B32-440C-8E1F-296135860B70@thewybles.com> On Dec 3, 2009, at 9:53 AM, Matthew Huff wrote: > The source address appears to be fixed as well as the source port (6666), scanning different destinations and ports. > > Some script kiddies found nmap and decided to target you for some reason. It happens. It's annoying. From mhuff at ox.com Thu Dec 3 18:03:20 2009 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Dec 2009 13:03:20 -0500 Subject: port scanning from spoofed addresses In-Reply-To: <68F8A2BA-0B32-440C-8E1F-296135860B70@thewybles.com> References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> <823a3sarl9.fsf@mid.bfk.de> <483E6B0272B0284BA86D7596C40D29F9D775E7EE2C@PUR-EXCH07.ox.com> <68F8A2BA-0B32-440C-8E1F-296135860B70@thewybles.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D775E7EE2D@PUR-EXCH07.ox.com> I'm not at all concerned about door-knob twisting or network scanning. What concerns me is that the source addresses are spoofed from our address range and that our upstream providers aren't willing to even look at the problem. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Thursday, December 03, 2009 1:01 PM To: Matthew Huff Cc: Florian Weimer; (nanog at nanog.org) Subject: Re: port scanning from spoofed addresses On Dec 3, 2009, at 9:53 AM, Matthew Huff wrote: > The source address appears to be fixed as well as the source port (6666), scanning different destinations and ports. > > Some script kiddies found nmap and decided to target you for some reason. It happens. It's annoying. From jmamodio at gmail.com Thu Dec 3 18:12:40 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 3 Dec 2009 12:12:40 -0600 Subject: What DNS Is Not In-Reply-To: <20091120144040.GQ25450@hezmatt.org> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> <4B020B0D.401@gdt.id.au> <4B02225D.9040904@brightok.net> <4B05D272.9020900@accessplus.com.au> <20091120144040.GQ25450@hezmatt.org> Message-ID: <202705b0912031012w4bb5b414tbfe875ea51546151@mail.gmail.com> Preemptive action or smart move ? http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html Cool IP address to remember though (8.8.8.8) Cheers Jorge From ray.sanders at villagevoicemedia.com Thu Dec 3 18:09:30 2009 From: ray.sanders at villagevoicemedia.com (Ray Sanders) Date: Thu, 03 Dec 2009 11:09:30 -0700 Subject: Flash Media Servers as Open Proxies In-Reply-To: References: Message-ID: <4B17FEDA.9000307@villagevoicemedia.com> Marshall, Did you find out via published article, or your own research? Either way I'd like (if you don't mind) more information on this so I can investigate what impact there may be on our systems. Thanks! Marshall Eubanks wrote: > I recently found out that the Adobe Flash Media Server (FMS) can > operate "out of the box" > as an open proxy, enabling other people to steal server resources and > bandwidth. Furthermore, > I also found that there is an ecosystem of pirates taking advantage of > this "feature" to > illegally stream sports events (and maybe other stuff as well). Each > event uses multiple (stolen) > servers and can amount to thousands of streams and Gbps of consumed > bandwidth. > > I believe but am not 100% sure that there are similar problems with > Window Media Servers. > > I would like to hear (off-list) from people who have experience > fighting this so that we could > maybe pool techniques. I will try to write this up further later. > > Regards > Marshall Eubanks > > -- -"Prediction is very difficult, especially about the future." -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From esuarez at fcaglp.fcaglp.unlp.edu.ar Thu Dec 3 18:16:30 2009 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Thu, 03 Dec 2009 15:16:30 -0300 Subject: news from Google Message-ID: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> Hi, now Google DNS, anything more? http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronomicas y Geofisicas Universidad Nacional de La Plata ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From jmamodio at gmail.com Thu Dec 3 18:21:08 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 3 Dec 2009 12:21:08 -0600 Subject: news from Google In-Reply-To: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> > now Google DNS, anything more? GoogleNation. Cheers Jorge From tme at americafree.tv Thu Dec 3 18:22:41 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 3 Dec 2009 13:22:41 -0500 Subject: Flash Media Servers as Open Proxies In-Reply-To: <4B17FEDA.9000307@villagevoicemedia.com> References: <4B17FEDA.9000307@villagevoicemedia.com> Message-ID: <3540F6AF-9375-4012-AE8A-EC1E1AD38DA4@americafree.tv> On Dec 3, 2009, at 1:09 PM, Ray Sanders wrote: > Marshall, > > Did you find out via published article, or your own research? > Either way I'd like (if you don't mind) more information on this so > I can investigate what impact there may be on our systems. > Via a DMCA take-down letter for a Cricket match that was sent to AmericaFree.TV, and subsequent research into what was going on. Regards Marshall > > Thanks! > > Marshall Eubanks wrote: >> I recently found out that the Adobe Flash Media Server (FMS) can >> operate "out of the box" >> as an open proxy, enabling other people to steal server resources >> and bandwidth. Furthermore, >> I also found that there is an ecosystem of pirates taking advantage >> of this "feature" to >> illegally stream sports events (and maybe other stuff as well). >> Each event uses multiple (stolen) >> servers and can amount to thousands of streams and Gbps of consumed >> bandwidth. >> >> I believe but am not 100% sure that there are similar problems with >> Window Media Servers. >> >> I would like to hear (off-list) from people who have experience >> fighting this so that we could >> maybe pool techniques. I will try to write this up further later. >> >> Regards >> Marshall Eubanks >> >> > > > -- > -"Prediction is very difficult, especially about the future." > -Niels Bohr > -- > Ray Sanders > Linux Administrator > Village Voice Media > Office: 602-744-6547 > Cell: 602-300-4344 > > From andre.engel at fhe3.com Thu Dec 3 18:32:13 2009 From: andre.engel at fhe3.com (Andre Engel) Date: Thu, 3 Dec 2009 19:32:13 +0100 Subject: AT&T SMTP Admin contact? Message-ID: <008401ca7446$ef3e2300$cdba6900$@engel@fhe3.com> > -----Urspr?ngliche Nachricht----- > Von: Chris Owen [mailto:owenc at hubris.net] > Gesendet: Donnerstag, 3. Dezember 2009 07:25 > An: NANOG list > Betreff: Re: AT&T SMTP Admin contact? > > On Dec 2, 2009, at 9:52 PM, Valdis.Kletnieks at vt.edu wrote: > > > It only stops forgery if the SPF record has a -all in it (as > hubris.net does). > > However, a lot of domains (mine included) have a ~all instead. > > I guess I've never really seen the point of publishing a SPF record if > it ends in ~all. What are people supposed to do with that info? For instance some ISPs or Freemail providers give their customers the possibility to use SPF as a value added service to decide if "senders domain" should be dropped in theirs suspicious-folders or not . I also learned that SPF is qualified for senders reputation : http://www.ceas.cc/2006/19.pdf > Spamassassin assigns it a score of 0.6 but that is low enough it really > doesn't have much since it doesn't assign any negative points for > SPF_PASS. > > (And before anybody asks, yes ~all is what we want, and no you can't > ask us > > to try -all instead, unless we're allowed to send you all the > helpdesk calls > > about misconfigured migratory laptops".. ;) > I certainly understand that you may not be able to lock down your > domain. We don't even try for customers for instance. However, if > you can't, I guess I don't really see what good publishing a SPF record > is if you tell people not to enforce it. MAAWG published a document around : Trust in Email begins with Authentication http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Authentication_Pap er_2008-07.pdf > Chris > > ----------------------------------------------------------------------- > -- > Chris Owen - Garden City (620) 275-1900 - Lottery (noun): > President - Wichita (316) 858-3000 - A stupidity tax > Hubris Communications Inc www.hubris.net > ----------------------------------------------------------------------- > -- > Cheers Andre -- Andre Engel Consulting Program Director, Email and Cyber Intelligence Services "..no ghost just a shell" FHE3 GmbH P: +49 721 869 5907 Scheffelstr. 17a M: +49 160 962 44476 76135 Karlsruhe andre.engel at fhe3.com http://www.fhe3.com/ Amtsgericht Mannheim, HRB 702495 Umsatzsteuer-Ident: DE254677931 Gesch?ftsf?hrer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt This message (including any attachments) is the property of FHE3 and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From charles at thewybles.com Thu Dec 3 18:44:49 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 3 Dec 2009 10:44:49 -0800 Subject: news from Google In-Reply-To: <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> Message-ID: <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> 8.8.8.8 .... 6.6.6.6 would have been really really funny. :) On Dec 3, 2009, at 10:21 AM, Jorge Amodio wrote: >> now Google DNS, anything more? > > GoogleNation. > > Cheers > Jorge > From sethm at rollernet.us Thu Dec 3 18:48:46 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 03 Dec 2009 10:48:46 -0800 Subject: news from Google In-Reply-To: <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> Message-ID: <4B18080E.7090001@rollernet.us> Jorge Amodio wrote: >> now Google DNS, anything more? > > GoogleNation. > No kiddng. I must be the only one who is getting tired of seeing Google take over literally everything. ~Seth From xbanchon at telconet.net Thu Dec 3 18:49:50 2009 From: xbanchon at telconet.net (Xavier Banchon) Date: Thu, 3 Dec 2009 13:49:50 -0500 Subject: news from Google In-Reply-To: <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> Message-ID: <140c01ca7449$6996b700$3cc42500$@net> GoogleWave? Regards, Xavier -----Mensaje original----- De: Jorge Amodio [mailto:jmamodio at gmail.com] Enviado el: Jueves, 03 de Diciembre de 2009 13:21 Para: Eduardo A. Su?rez CC: nanog at nanog.org Asunto: Re: news from Google > now Google DNS, anything more? GoogleNation. Cheers Jorge -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4832 bytes Desc: not available URL: From bkain1 at ford.com Thu Dec 3 18:51:05 2009 From: bkain1 at ford.com (Kain, Becki (B.)) Date: Thu, 3 Dec 2009 13:51:05 -0500 Subject: FW: news from Google Message-ID: when is the European Union going to sue them for anti-trust, ala Microsoft? -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thursday, December 03, 2009 1:49 PM To: nanog at nanog.org Subject: Re: news from Google Jorge Amodio wrote: >> now Google DNS, anything more? > > GoogleNation. > No kiddng. I must be the only one who is getting tired of seeing Google take over literally everything. ~Seth From jof at thejof.com Thu Dec 3 18:51:24 2009 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 03 Dec 2009 10:51:24 -0800 Subject: news from Google In-Reply-To: <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> Message-ID: <1259866224-sup-8275@sfo.thejof.com> Excerpts from Charles Wyble's message of Thu Dec 03 10:44:49 -0800 2009: > 8.8.8.8 .... 6.6.6.6 would have been really really funny. :) Nice IPs from Level 3, huh? 6.6.6.6 belongs to the US Army. --j From andrey.gordon at gmail.com Thu Dec 3 19:08:14 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Thu, 3 Dec 2009 14:08:14 -0500 Subject: news from Google In-Reply-To: <1259866224-sup-8275@sfo.thejof.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> Message-ID: <90ccfc90912031108n66b4e1e8h599ce855f6bc0275@mail.gmail.com> uf, another question I'll have ask my users now: User: I can't get to the intranet.mycompanydomain.local! What did you break!? Me: Hey, you can't to the intranet,domain.local? Did you make your laptop use Google DNS? ----- Andrey Gordon [andrey.gordon at gmail.com] From bclark at spectraaccess.com Thu Dec 3 19:12:58 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 03 Dec 2009 14:12:58 -0500 Subject: news from Google In-Reply-To: <4B18080E.7090001@rollernet.us> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> Message-ID: <1259867578.2213.14.camel@acer> For sure...everyone remembers the Bill Gates Borg picture, but at this rate, Google will soon become the new poster child for that picture (or something comparable). Bret On Thu, 2009-12-03 at 10:48 -0800, Seth Mattinen wrote: > No kiddng. I must be the only one who is getting tired of seeing > Google > take over literally everything. > > ~Seth From brandon.galbraith at gmail.com Thu Dec 3 19:16:14 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 3 Dec 2009 13:16:14 -0600 Subject: news from Google In-Reply-To: <1259867578.2213.14.camel@acer> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: <366100670912031116s286a4732pebb1feac9762b28@mail.gmail.com> On Thu, Dec 3, 2009 at 1:12 PM, Bret Clark wrote: > For sure...everyone remembers the Bill Gates Borg picture, but at this > rate, Google will soon become the new poster child for that picture (or > something comparable). > > Bret > > I try to think of them as a benevolent dictator ;) -brandon > > On Thu, 2009-12-03 at 10:48 -0800, Seth Mattinen wrote: > > > No kiddng. I must be the only one who is getting tired of seeing > > Google > > take over literally everything. > > > > ~Seth > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From patrick at ianai.net Thu Dec 3 19:20:37 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 3 Dec 2009 13:20:37 -0600 Subject: news from Google In-Reply-To: <90ccfc90912031108n66b4e1e8h599ce855f6bc0275@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <90ccfc90912031108n66b4e1e8h599ce855f6bc0275@mail.gmail.com> Message-ID: <582A95C0-3B71-49E1-AFD6-5172415A57AE@ianai.net> Sent from my iPhone, please excuse any errors. On Dec 3, 2009, at 13:08, Andrey Gordon wrote: > uf, another question I'll have ask my users now: > > User: I can't get to the intranet.mycompanydomain.local! What did you > break!? > Me: Hey, you can't to the intranet,domain.local? Did you make your > laptop > use Google DNS? 1) If $COMPANY does not force their VPN client to disallow external DNS, shame on them. 2) You already have this issue. Google is hardly the first, and no where near the biggest (nor will they be in all likelihood, despite their name). 3) I know, none of that matters. You still get phone calls. 4) Welcome to the ISP business. (Another reason I Am Not An Isp. :-) -- TTFN, patrick From beckman at angryox.com Thu Dec 3 19:25:04 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 3 Dec 2009 14:25:04 -0500 Subject: news from Google In-Reply-To: <4B18080E.7090001@rollernet.us> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> Message-ID: On Thu, 3 Dec 2009, Seth Mattinen wrote: > Jorge Amodio wrote: >>> now Google DNS, anything more? I'm surprised that Google's new DNS service does not return better results for google.com than some local DNS resolvers do. My server is in Fairfax, VA. Does Google use Anycast'ed IPs or is it still a hybrid of split-horizon DNS and other things, as discussed previously: http://www.merit.edu/mail.archives/nanog/2009-02/threads.html#00269 Here's the results from some various DNS servers for Google.com. I thought Google had a datacenter in Ashburn, VA, but I'm not getting there. Maybe it's gone. Maybe the shortest route doesn't matter anymore. --> dig +short google.com @208.67.222.222 # OpenDNS 74.125.53.100 74.125.67.100 74.125.45.100 --> dig +short google.com @8.8.8.8 # Google DNS 74.125.67.100 74.125.53.100 74.125.45.100 --> dig +short google.com @8.8.4.4 # Google DNS 2 74.125.67.100 74.125.53.100 74.125.45.100 --> dig +short google.com @198.6.1.1 # UUNET/Verizon Cache server (cache00.ns.uu.net) 74.125.53.100 74.125.67.100 74.125.45.100 --> dig +short google.com @198.6.1.2 74.125.45.100 74.125.53.100 74.125.67.100 --> dig +short google.com @198.6.1.3 74.125.45.100 74.125.67.100 74.125.53.100 --> dig +short google.com @198.6.1.4 74.125.45.100 74.125.53.100 74.125.67.100 --> dig +short google.com @198.6.1.5 74.125.67.100 74.125.45.100 74.125.53.100 * --> dig +short google.com @70.164.18.41 # Nova.org (Small VA ISP) Caching DNS 74.125.45.100 74.125.53.100 74.125.67.100 * --> dig +short google.com @208.94.147.150 # Tiggee DNS (VA company) 74.125.45.100 74.125.67.100 74.125.53.100 --> ping -c 10 74.125.45.100 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 18.079/20.522/25.272/2.200 ms --> ping -c 10 74.125.53.100 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 97.721/101.267/107.770/2.856 ms --> ping -c 10 74.125.67.100 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 97.531/99.238/101.206/1.420 ms Only the last two starred DNS records returned what _seems_ to be the best result for Google.com. Then again, someone from Google might be able to explain the logic behind the results. And to rip off the bandaid on the "What DNS Is Not" discussion, Google's DNS does return the expected NXDOMAIN for the very small test I did. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From nanog-post at rsuc.gweep.net Thu Dec 3 19:25:18 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 3 Dec 2009 14:25:18 -0500 Subject: FW: news from Google In-Reply-To: References: Message-ID: <20091203192518.GA97411@gweep.net> On Thu, Dec 03, 2009 at 01:51:05PM -0500, Kain, Becki (B.) wrote: > > when is the European Union going to sue them for anti-trust, ala > Microsoft? More optional anycasted resolvers are somehow bad? [well, for simpleminded geolocation maybe] Just another pair to slot alongside L3's and OpenDNS. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From netfortius at gmail.com Thu Dec 3 19:26:25 2009 From: netfortius at gmail.com (Stefan) Date: Thu, 3 Dec 2009 13:26:25 -0600 Subject: news from Google In-Reply-To: <1259867578.2213.14.camel@acer> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: On Thu, Dec 3, 2009 at 1:12 PM, Bret Clark wrote: > For sure...everyone remembers the Bill Gates Borg picture, but at this > rate, Google will soon become the new poster child for that picture (or > something comparable). > > Bret > > > On Thu, 2009-12-03 at 10:48 -0800, Seth Mattinen wrote: > > > No kiddng. I must be the only one who is getting tired of seeing > > Google > > take over literally everything. > > > > ~Seth > I think of this as an obvious (not necessarily beneficial for all, of course) step for a company which lives out of advertisement - i.e. what if they could capture your habits for browsing at the FQDN-to-IP time - wouldn't that add more to their knowledge base? ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From bmanning at vacation.karoshi.com Thu Dec 3 19:31:13 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 3 Dec 2009 19:31:13 +0000 Subject: news from Google In-Reply-To: <1259867578.2213.14.camel@acer> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: <20091203193113.GC25468@vacation.karoshi.com.> http://www.collegehumor.com/article:1793643 --bill On Thu, Dec 03, 2009 at 02:12:58PM -0500, Bret Clark wrote: > For sure...everyone remembers the Bill Gates Borg picture, but at this > rate, Google will soon become the new poster child for that picture (or > something comparable). > > Bret > > > On Thu, 2009-12-03 at 10:48 -0800, Seth Mattinen wrote: > > > No kiddng. I must be the only one who is getting tired of seeing > > Google > > take over literally everything. > > > > ~Seth From serge at euro-ix.net Thu Dec 3 19:33:44 2009 From: serge at euro-ix.net (Serge Radovcic) Date: Thu, 03 Dec 2009 20:33:44 +0100 Subject: Leaving public peering? In-Reply-To: Message-ID: On Thu, 3 Dec 2009 10:53:46 -0500 Ken Chase wrote: >> Check out this report on the success of peering : >> https://www.euro-ix.net/member/m/document/showDocument/id/158 > This seems to be a protected document behind login-only section of the > site. Can anyone comment on wether the document should be publically > accessible? Would love to spread it around. This report is available to the public at: http://www.euro-ix.net/resources/reports/ Serge From jmamodio at gmail.com Thu Dec 3 19:34:26 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 3 Dec 2009 13:34:26 -0600 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: <202705b0912031134k10ba2ba9y295a0bb5b64ee99b@mail.gmail.com> > I think of this as an obvious (not necessarily beneficial for all, of > course) step for a company which lives out of advertisement - i.e. what if > they could capture your habits for browsing at the FQDN-to-IP time - > wouldn't that add more to their knowledge base? They have a lot of smart people there trying to provide a good service and do smart things, but as they are smart if a large number of users use their resolvers that's a lot of juicy statistics that can be monetized in some way. They will find the way to do it. IMHO. Jorge From deepak at ai.net Thu Dec 3 19:36:09 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 3 Dec 2009 14:36:09 -0500 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: > I think of this as an obvious (not necessarily beneficial for all, of > course) step for a company which lives out of advertisement - i.e. what > if > they could capture your habits for browsing at the FQDN-to-IP time - > wouldn't that add more to their knowledge base? > I think there are amazing opportunities to data mine and prevent fraud if you can get a percentage of your users using this. I'm really excited about the structured attacks that will be run against this thing (cache poisoning... and nastier)... if (for example) when their (or someone's) toolbar is installed, they ask if you'd like to use their "improved" dns service [perhaps they have the whole universe cached to reduce lookup times]. You'd sign up. And as the wave of software updates proceeds... well, talk about all your eggs in one basket. Smart ISPs will have an ACL ready to hijack external DNS requests for their whole network in the (inevitable) event something *bad* happens one day and you need to restore service to your customers faster than they can figure out how to fix it themselves. Just a thought. Deepak From sethm at rollernet.us Thu Dec 3 19:37:29 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 03 Dec 2009 11:37:29 -0800 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: <4B181379.2060101@rollernet.us> Stefan wrote: > > I think of this as an obvious (not necessarily beneficial for all, of > course) step for a company which lives out of advertisement - i.e. what if > they could capture your habits for browsing at the FQDN-to-IP time - > wouldn't that add more to their knowledge base? > I'm certain they will be gathering statistics. ~Seth From serge at euro-ix.net Thu Dec 3 19:43:36 2009 From: serge at euro-ix.net (Serge Radovcic) Date: Thu, 03 Dec 2009 20:43:36 +0100 Subject: New European IXP customer tool Message-ID: Just wanted to announce that we published a handy little tool for those either already, or interested in, peering at an European IXP(s). The Euro-IX ASN filter allows one to make use of our IXP database that contains more than 4.800 ASNs that peer at IXPs around Europe. You can see which ASNs peer where and what the overlap is between multiple IXPs and, well more....just try it out and see. https://www.euro-ix.net/member/m/asnfilter All feedback is welcome Serge Euro-ix From cmaurand at xyonet.com Thu Dec 3 19:47:40 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 03 Dec 2009 14:47:40 -0500 Subject: news from Google In-Reply-To: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <4B1815DC.2030708@xyonet.com> Eduardo A. Su?rez wrote: > Hi, > > now Google DNS, anything more? > > http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html > > > Eduardo.- > yawn. So not interested. From herrin-nanog at dirtside.com Thu Dec 3 19:58:35 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 3 Dec 2009 14:58:35 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: <073D5290-1115-4AA5-8B7D-E4D8695BB833@hubris.net> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <20091202183124.GA25056@gsp.org> <247D4FDA-3D4D-4A75-96EF-B3D59E63CA2F@hubris.net> <20145.1259812342@turing-police.cc.vt.edu> <073D5290-1115-4AA5-8B7D-E4D8695BB833@hubris.net> Message-ID: <3c3e3fca0912031158y66a6584dr252a09863ae3b65b@mail.gmail.com> On Thu, Dec 3, 2009 at 1:25 AM, Chris Owen wrote: > On Dec 2, 2009, at 9:52 PM, Valdis.Kletnieks at vt.edu wrote: > >> It only stops forgery if the SPF record has a -all in it (as hubris.net does). >> However, a lot of domains (mine included) have a ~all instead. > > I guess I've never really seen the point of publishing a SPF record if it >ends in ~all. ?What are people supposed to do with that info? > > Spamassassin assigns it a score of 0.6 but that is low enough it >really doesn't have much since it doesn't assign any negative >points for SPF_PASS. Chris, In addition to pushing the spam assassin score a little more towards tagging it as a spam, I use SPF to suppress backscatter from my confirmation system. When I receive a message whose spam probability is ambiguous (spamassassin score between 3 and 8), I generate a confirmation request to the sender. This allows the sender to put the message in front of me anyway if it turns out to have been a false positive, as it occasionally does. If you publish SPF records (even with ~all) and the source doesn't match, I won't generate that request. You've given me sufficient forward knowledge to detect the forgery so that I can silently drop the spam and still comply with RFC 2821's "must." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scott at sberkman.net Thu Dec 3 20:09:46 2009 From: scott at sberkman.net (Scott Berkman) Date: Thu, 3 Dec 2009 15:09:46 -0500 Subject: news from Google In-Reply-To: <1259866224-sup-8275@sfo.thejof.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> Message-ID: <00b401ca7454$8fe25490$afa6fdb0$@net> Also reminds me of the Level 3 DNS servers in the 4.2.2.[1-8++] range. -Scott -----Original Message----- From: Jonathan Lassoff [mailto:jof at thejof.com] Sent: Thursday, December 03, 2009 1:51 PM To: nanog Subject: Re: news from Google Excerpts from Charles Wyble's message of Thu Dec 03 10:44:49 -0800 2009: > 8.8.8.8 .... 6.6.6.6 would have been really really funny. :) Nice IPs from Level 3, huh? 6.6.6.6 belongs to the US Army. --j From sil at infiltrated.net Thu Dec 3 20:17:38 2009 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 03 Dec 2009 15:17:38 -0500 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <1259867578.2213.14.camel@acer> Message-ID: <4B181CE2.6070306@infiltrated.net> Deepak Jain wrote: > I think there are amazing opportunities to data mine and prevent fraud if you can get a percentage of your users using this. > > I'm really excited about the structured attacks that will be run against this thing (cache poisoning... and nastier)... if (for example) when their (or someone's) toolbar is installed, they ask if you'd like to use their "improved" dns service [perhaps they have the whole universe cached to reduce lookup times]. You'd sign up. > I agree in a role-reversal method. I think there are amazing methods to study the correlation and statistical rate of criminal groups and how they're amassing so much data making things nTimes easier to steal, spoof and create more frauds. Thanks Google! In fact, because they'd now have one more tool to work against them, its only a matter of time before they become smarter (those tinkerers!) That leaves forensics experts with something to gripe about. Too much of a workload. http://www.youtube.com/watch?v=pq3YdpB6N9M -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Chris_Griffiths at Cable.Comcast.com Thu Dec 3 20:22:44 2009 From: Chris_Griffiths at Cable.Comcast.com (Griffiths, Chris) Date: Thu, 03 Dec 2009 15:22:44 -0500 Subject: Calling Comcast Postmaster or whomever actually is responsible for Comcast RBL maintenance In-Reply-To: <941190370912030910v71b3f0c6p33e44488cc4a2370@mail.gmail.com> Message-ID: On 12/3/09 12:10 PM, "Chris Stebner" wrote: > For over a month now I've been fighting with Comcast Customer Security > Assurance regarding a simple BlackList issue. Apparently there is some > disconnect between internal applications and their ability to report > BlackList status accurately and the 'actual' BlackList rule-set. Supposedly > the ticket has been escalated to 'admin' and 'engineering' multiple times to > no avail. Currently we are waiting for engineering again to examine the > issue. > > The block is owned by us, a facilities based CLEC in business for over 10 > years. The /24 in question is used for business T1's. > > If anyone has any contacts, ideas or the power to resolve the issue I'd be > elated to hear from you. > > > Thank you all for your time, > > Chris Stebner > 970-403-0102 I have send this issue on to the right team and you should hear back from them shortly. Thanks for posting. -- Chris Griffiths Comcast Cable Communications, Inc. National Engineering and Technical Operations From jeroen at unfix.org Thu Dec 3 20:29:25 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 03 Dec 2009 21:29:25 +0100 Subject: news from Google In-Reply-To: <90ccfc90912031108n66b4e1e8h599ce855f6bc0275@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <90ccfc90912031108n66b4e1e8h599ce855f6bc0275@mail.gmail.com> Message-ID: <4B181FA5.5080806@spaghetti.zurich.ibm.com> Andrey Gordon wrote: > uf, another question I'll have ask my users now: > > User: I can't get to the intranet.mycompanydomain.local! What did you > break!? > Me: Hey, you can't to the intranet,domain.local? Did you make your laptop > use Google DNS? But it is soooo easy to just route 8.8.8.8 and 8.8.4.4 to ISP/enterprise internal ISP addresses, no more configuration who would have thought of that... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From mpetach at netflight.com Thu Dec 3 20:36:53 2009 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 3 Dec 2009 12:36:53 -0800 Subject: news from Google In-Reply-To: <00b401ca7454$8fe25490$afa6fdb0$@net> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> Message-ID: <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> On Thu, Dec 3, 2009 at 12:09 PM, Scott Berkman wrote: > Also reminds me of the Level 3 DNS servers in the 4.2.2.[1-8++] range. > > ? ? ? ?-Scott > I suppose I've been too brainwashed by HTTP...I looked at that, and thought that it would amusing to have a DNS server in the 4.0.2 range. ^_^; (for reference... http://en.wikipedia.org/wiki/HTTP_402#4xx_Client_Error 402 Payment Required :D Matt From justin at justinshore.com Thu Dec 3 20:40:30 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 03 Dec 2009 14:40:30 -0600 Subject: Historical traceroute logging Message-ID: <4B18223E.4050805@justinshore.com> Does anyone know of any tools that can do repeated traceroutes over time to a remote IP and log the results for later viewing/comparison? I'd like to do a traceroute several times a day and store the details in CVS or somewhere accessible down the road. Alerting to major path changes would be nice but not critical. The ability to compare traceroute output down the road would also be nice but also not critical. I'm more interested in the path than the individual hops' RTTs. What's prompting this is a major change in RTTs for several hours yesterday to an ITSP with a site in the south. We share a common upstream (L3) and have in the past always transited that provider to get to each other. I showed a route change for the specific /23 in question in my border routers' RIBs. The adjacent /23 originating from the same ITSP but in a different part of the country did not change (and neither did RTTs to the hosts we monitor in that /23). The site claimed nothing changed on their end and that they know of no changes upstream. BGP Play shows a route change from Level3 to Internap during the time in question (thought the times don't line up exactly) which most likely caused the more than double RTTs we were seeing. My Cacti Advanced Ping graphs caught the problem in all its glory. Nagios alerted me to the high RTT times as well. What I didn't get during that period of time was a traceroute to the site in question. I'd like to run a traceroute several times a day and find some way to store the output and work with it later if needed. I'd prefer OSS but commercial apps would be considered too. I'm sure I'm not the first to have a need to check traceroutes like that. How do the rest of you handle it? Thanks Justin From martin at theicelandguy.com Thu Dec 3 20:56:22 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Thu, 3 Dec 2009 15:56:22 -0500 Subject: news from Google In-Reply-To: <4B181FA5.5080806@spaghetti.zurich.ibm.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <90ccfc90912031108n66b4e1e8h599ce855f6bc0275@mail.gmail.com> <4B181FA5.5080806@spaghetti.zurich.ibm.com> Message-ID: On Thu, Dec 3, 2009 at 3:29 PM, Jeroen Massar wrote: > Andrey Gordon wrote: > > uf, another question I'll have ask my users now: > > > > User: I can't get to the intranet.mycompanydomain.local! What did you > > break!? > > Me: Hey, you can't to the intranet,domain.local? Did you make your laptop > > use Google DNS? > > But it is soooo easy to just route 8.8.8.8 and 8.8.4.4 to ISP/enterprise > internal ISP addresses, no more configuration who would have thought of > that... > > Forever? I think we're also seeing the first legacy space holder (that I'm aware of, publicly) foray into commercial LIR services. Putting this service into a legacy block was not a mistake or a stroke of luck. It's being advertised by goog. Could mean nothing, but I think it's interesting amongst the other interesting things. Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From bruns at 2mbit.com Thu Dec 3 21:04:55 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 03 Dec 2009 14:04:55 -0700 Subject: news from Google In-Reply-To: <4B18080E.7090001@rollernet.us> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> Message-ID: <4B1827F7.2040000@2mbit.com> On 12/3/09 11:48 AM, Seth Mattinen wrote: > Jorge Amodio wrote: >>> now Google DNS, anything more? >> >> GoogleNation. >> > > No kiddng. I must be the only one who is getting tired of seeing Google > take over literally everything. > > ~Seth > Why is it that people start cracking out at the thought of Google offering a free service that people might have an actual use for and that is completely optional and used by choice? It's a free service people! No different then Hotmail, or Yahoo Mail, or Gmail, AOL Instant Messenger, MSN Messenger... Use it if you want, but if you don't, so be it. They're not holding a gun to your head. It would be one thing if installing Google Chrome or similar changed your DNS settings without your knowledge. MS in the past forced MSN Messenger onto people by default in most Windows installs, and the world didn't end. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jeroen at unfix.org Thu Dec 3 21:16:20 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 03 Dec 2009 22:16:20 +0100 Subject: Historical traceroute logging In-Reply-To: <4B18223E.4050805@justinshore.com> References: <4B18223E.4050805@justinshore.com> Message-ID: <4B182AA4.50905@spaghetti.zurich.ibm.com> Justin Shore wrote: > Does anyone know of any tools that can do repeated traceroutes over time > to a remote IP and log the results for later viewing/comparison? RIPE TTM @ http://www.ripe.net/ttm/ Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From sethm at rollernet.us Thu Dec 3 21:44:11 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 03 Dec 2009 13:44:11 -0800 Subject: news from Google In-Reply-To: <4B1827F7.2040000@2mbit.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> Message-ID: <4B18312B.8020305@rollernet.us> Brielle Bruns wrote: > > Why is it that people start cracking out at the thought of Google > offering a free service that people might have an actual use for and > that is completely optional and used by choice? > I take it you've never been on the receiving end of a "the whole internet is down it's your fault cuz google never breaks" call when google hiccups? ~Seth From andrey.gordon at gmail.com Thu Dec 3 21:49:39 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Thu, 3 Dec 2009 16:49:39 -0500 Subject: news from Google In-Reply-To: <4B18312B.8020305@rollernet.us> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <4B18312B.8020305@rollernet.us> Message-ID: <90ccfc90912031349y6949d044hfc67369dc1b9df7a@mail.gmail.com> I generally like goog's services and the fact that they are free, but sometimes google makes me think of all those futuristic movies where there is a single corporation running the world, everyone is 'tagged' and tracked 24/7 and everyone who works for that corporation are happy campers and live in clean and modern neighborhoods and the rest of the people are scam of the earth and live in the sewer. IMHO that's where we are heading with google taking over every service imaginable. That's the feeling I get from google. ----- Andrey Gordon [andrey.gordon at gmail.com] On Thu, Dec 3, 2009 at 4:44 PM, Seth Mattinen wrote: > Brielle Bruns wrote: > >> >> Why is it that people start cracking out at the thought of Google offering >> a free service that people might have an actual use for and that is >> completely optional and used by choice? >> >> > I take it you've never been on the receiving end of a "the whole internet > is down it's your fault cuz google never breaks" call when google hiccups? > > ~Seth > > From bruns at 2mbit.com Thu Dec 3 21:50:03 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 03 Dec 2009 14:50:03 -0700 Subject: news from Google In-Reply-To: <4B18312B.8020305@rollernet.us> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <4B18312B.8020305@rollernet.us> Message-ID: <4B18328B.2070002@2mbit.com> On 12/3/09 2:44 PM, Seth Mattinen wrote: > > I take it you've never been on the receiving end of a "the whole > internet is down it's your fault cuz google never breaks" call when > google hiccups? Actually, I have. I used to have to deal with gems like 'Your DNS server is attacking my machine in port 53 UDP!' all the time. End users will always do what they want without needing help from anyone but themselves. My position has, and always will be, you are on your own if you deviate from the standard configuration we provide. My current users understand that, and have gotten to the point where they'll admit up front if they changed something, without me needing to ask. Considering our messing up something costs them $0 vs. a service call from us that starts at $50 and goes up, the economics of playing with settings that work fine gets expensive, and they know this. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From joelja at bogus.com Thu Dec 3 21:35:56 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 03 Dec 2009 13:35:56 -0800 Subject: FW: news from Google In-Reply-To: References: Message-ID: <4B182F3C.6020908@bogus.com> Kain, Becki (B.) wrote: > No kiddng. I must be the only one who is getting tired of seeing Google > take over literally everything. Nobody as far as I can tell has a Monoploy on bad ideas... joel From math at sizone.org Thu Dec 3 22:07:22 2009 From: math at sizone.org (Ken Chase) Date: Thu, 3 Dec 2009 17:07:22 -0500 Subject: news from Google In-Reply-To: <4B1827F7.2040000@2mbit.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> Message-ID: <20091203220722.GP8192@sizone.org> On Thu, Dec 03, 2009 at 02:04:55PM -0700, Brielle Bruns's said: >Why is it that people start cracking out at the thought of Google >offering a free service that people might have an actual use for and >that is completely optional and used by choice? > >It's a free service people! No different then Hotmail, or Yahoo Mail, >or Gmail, AOL Instant Messenger, MSN Messenger... Use it if you want, >but if you don't, so be it. They're not holding a gun to your head. What happened to the free but private fire brigades (as popularized in the movie Gangs of...) - how did they get under the aegis of municipal govts? (Those damn socialist fire depts! :) Things that become essential services need quality management and control to ensure equal access to all and reduce abuses. Just because its free doesnt mean it's being done right or should continue as it is without oversight or regulation. In fact, Canada's privacy commissioner recently ruled on Facebook's policies and asked them to change significant things about the way the handle personal information and allow opt-ins and outs. "It's free, so why should anyone have any say in it, least of all the govt?" is your argument here. Access to internet/Email has been ruled as an essential service in (parts?) of the EU FWIG. The Canadian govt also has programs to help fund access to remote/ rural/isolated communities for eg. We all know that google is leveraging cross-referenceable information from all of its services for its profit/advantage, to the detriment of people's privacy and choice. Concentrating that much of internet services into one organization puts alot of power into one pair of hands. Information is power, and absolute power corrupts... and if it doesnt corrupt you, then at least the NSA would like to have tea and a conversation with you. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From bclark at spectraaccess.com Thu Dec 3 22:18:17 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 03 Dec 2009 17:18:17 -0500 Subject: news from Google In-Reply-To: <4B1827F7.2040000@2mbit.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> Message-ID: <4B183929.4070804@spectraaccess.com> Brielle Bruns wrote: > Why is it that people start cracking out at the thought of Google > offering a free service that people might have an actual use for and > that is completely optional and used by choice? > > It's a free service people! No different then Hotmail, or Yahoo Mail, > or Gmail, AOL Instant Messenger, MSN Messenger... Use it if you want, > but if you don't, so be it. They're not holding a gun to your head. Can you make that same statement when Google Chrome OS is released or future versions of Android are released? It would be naive to think that Google wouldn't try to default the DNS to there services with those OS'...no "for profit" company does something for free without an underlying motive. I don't think people have problems necessarily with Google getting into all this stuff, but at some point, if whatever users are doing always has Google as an initial destination, it becomes a concern and I think that is the underlying argument for most people Just my 2 cents, Bret From psrchisholm at gmail.com Thu Dec 3 22:20:38 2009 From: psrchisholm at gmail.com (Paul S. R. Chisholm) Date: Thu, 3 Dec 2009 17:20:38 -0500 Subject: news from Google In-Reply-To: <20091203220722.GP8192@sizone.org> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> Message-ID: <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> On Thu, Dec 3, 2009 at 5:07 PM, Ken Chase wrote: > We all know that google is leveraging cross-referenceable information from all > of its services for its profit/advantage ... > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. Ken, this was addressed in the announcement: http://code.google.com/speed/public-dns/privacy.html We built Google Public DNS to make the web faster and to retain as little information about usage as we could, while still being able to detect and fix problems. Google Public DNS does not permanently store personally identifiable information. http://code.google.com/speed/public-dns/faq.html#account http://code.google.com/speed/public-dns/faq.html#shared http://code.google.com/speed/public-dns/faq.html#info Is any of the information collected stored with my Google account? No. Does Google share the information it collects from the Google Public DNS service with anyone else? No. Is information about my queries to Google Public DNS shared with other Google properties, such as Search, Gmail, ads networks, etc.? No. Hope this helps. --PSRC From johns at sstar.com Thu Dec 3 22:26:40 2009 From: johns at sstar.com (John Souvestre) Date: Thu, 3 Dec 2009 16:26:40 -0600 Subject: Historical traceroute logging In-Reply-To: <4B182AA4.50905@spaghetti.zurich.ibm.com> References: <4B18223E.4050805@justinshore.com> <4B182AA4.50905@spaghetti.zurich.ibm.com> Message-ID: <48ACC1D3A02A48069CF943C4AAAC6282@JohnS> Hello Jeroen. I very much like Ping Plotter. http://www.pingplotter.com/ John John Souvestre - New Orleans LA > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: Thursday, December 03, 2009 3:16 PM > To: Justin Shore > Cc: NANOG list > Subject: Re: Historical traceroute logging > > Justin Shore wrote: > > Does anyone know of any tools that can do repeated traceroutes over time > > to a remote IP and log the results for later viewing/comparison? > > RIPE TTM @ http://www.ripe.net/ttm/ > > Greets, > Jeroen From math at sizone.org Thu Dec 3 22:29:29 2009 From: math at sizone.org (Ken Chase) Date: Thu, 3 Dec 2009 17:29:29 -0500 Subject: news from Google In-Reply-To: <90ccfc90912031349y6949d044hfc67369dc1b9df7a@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <4B18312B.8020305@rollernet.us> <90ccfc90912031349y6949d044hfc67369dc1b9df7a@mail.gmail.com> Message-ID: <20091203222929.GQ8192@sizone.org> You mean like this? http://arstechnica.com/telecom/news/2009/12/sprint-fed-customer-gps-data-to-leos-over-8-million-times.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss and this? http://almartinraw.com/public/column417.html just wait til google sews up all voice communications. On Thu, Dec 03, 2009 at 04:49:39PM -0500, Andrey Gordon's said: >sometimes google makes me think of all those futuristic movies where there >is a single corporation running the world, everyone is 'tagged' and tracked >24/7 and everyone who works for that corporation are happy campers and live >in clean and modern neighborhoods and the rest of the people are scam of the >earth and live in the sewer. >IMHO that's where we are heading with google taking over every service >imaginable. That's the feeling I get from google. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From brandon.galbraith at gmail.com Thu Dec 3 22:33:37 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 3 Dec 2009 16:33:37 -0600 Subject: Historical traceroute logging In-Reply-To: <48ACC1D3A02A48069CF943C4AAAC6282@JohnS> References: <4B18223E.4050805@justinshore.com> <4B182AA4.50905@spaghetti.zurich.ibm.com> <48ACC1D3A02A48069CF943C4AAAC6282@JohnS> Message-ID: <366100670912031433m4236814cl142a052e8f82d601@mail.gmail.com> On Thu, Dec 3, 2009 at 4:26 PM, John Souvestre wrote: > Hello Jeroen. > > I very much like Ping Plotter. http://www.pingplotter.com/ > > John > > We've used Ping Plotter before as well. Some shortcomings, but works well for what it's supposed to do. -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From math at sizone.org Thu Dec 3 22:48:41 2009 From: math at sizone.org (Ken Chase) Date: Thu, 3 Dec 2009 17:48:41 -0500 Subject: news from Google In-Reply-To: <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> Message-ID: <20091203224841.GR8192@sizone.org> Thanks for the updates Paul, good to see such policies in place at Google. I still personally hope for the great benevolent open-source-trumpeting /privacy-protecting giant to exist and operate exactly as it does in geeks' wildest fantasies. Really I do. However, I suppose you can make few admissions regarding law enforcement or other govt surveillance queries regarding those 24 or 48 hours of log retention. (It's likely illegal for you to comment, if you do know anything.) I'd love to know what google's policies are there (if any?) - and what kind of latitude google really has over refusing certain types of request, or even refusing to build in certain features that would be useful to law enforcement. But again, you might not be allowed to comment. While google does not do the cross referencing, can law enforcement request logs from various google services seperately and do their own cross referencing based on IP and timestamp? Of course for some obscure site (say ostensibly containing 'typical terrorist profile ideological writings' for a cliched example), those 24-48 hours of logs would positively tie an IP address to at least looking up the site hosting such materials, strengthening evidence that the user visited that site. This is a more wide ranging collection of information than google's search engine (which has its own privacy safeguards im not mentioning right now) as using google dns would log EVERY transaction (other than by raw IP) that the user did on the internet (not just google searches or using the web). This makes an extrordinarily attractive target for law enforcement. Even with strong policies in effect now, Im not sure that anything that currently stops law enforcement wont be challenged or secretly overridden sometime in the future. "Build it and they will come." /kc On Thu, Dec 03, 2009 at 05:20:38PM -0500, Paul S. R. Chisholm's said: >Ken, this was addressed in the announcement: > >http://code.google.com/speed/public-dns/privacy.html > >We built Google Public DNS to make the web faster and to retain as >little information about usage as we could, while still being able to >detect and fix problems. Google Public DNS does not permanently store >personally identifiable information. > >http://code.google.com/speed/public-dns/faq.html#account >http://code.google.com/speed/public-dns/faq.html#shared >http://code.google.com/speed/public-dns/faq.html#info -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From deepak at ai.net Thu Dec 3 23:00:16 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 3 Dec 2009 18:00:16 -0500 Subject: news from Google In-Reply-To: <20091203222929.GQ8192@sizone.org> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <4B18312B.8020305@rollernet.us> <90ccfc90912031349y6949d044hfc67369dc1b9df7a@mail.gmail.com> <20091203222929.GQ8192@sizone.org> Message-ID: Or the whole turning over records from Youtube... Nothing prevents them from changing policies in the future when it becomes more difficult for millions of users to change away... (vis-?-vis the uproar when FB was going to change its privacy policy and more as it continues to do so). > -----Original Message----- > From: Ken Chase [mailto:math at sizone.org] > Sent: Thursday, December 03, 2009 5:29 PM > To: nanog at nanog.org > Subject: Re: news from Google > > You mean like this? > > http://arstechnica.com/telecom/news/2009/12/sprint-fed-customer-gps- > data-to-leos-over-8-million- > times.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss > > and this? > > http://almartinraw.com/public/column417.html > > just wait til google sews up all voice communications. > > On Thu, Dec 03, 2009 at 04:49:39PM -0500, Andrey Gordon's said: > >sometimes google makes me think of all those futuristic movies where > there > >is a single corporation running the world, everyone is 'tagged' and > tracked > >24/7 and everyone who works for that corporation are happy campers > and live > >in clean and modern neighborhoods and the rest of the people are > scam of the > >earth and live in the sewer. > >IMHO that's where we are heading with google taking over every > service > >imaginable. That's the feeling I get from google. > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS > @151 Front St. W. From jbates at brightok.net Fri Dec 4 00:06:23 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Dec 2009 18:06:23 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> Message-ID: <4B18527F.7040403@brightok.net> Mark Newton wrote: > The fact that someone got OpenWRT working in less than a week of spare > time makes it totally clear why the commercial vendors haven't done > anything: They're just simply not interested, nothing more, nothing > less. I suspect they didn't use DHCPv6-PD with that OpenWRT. I've had issues with the dhcp client that comes with it in the past, though I've had an ubuntu box acting as a router with wide-dhcp doing -PD. It works okay, although the devs really should look at better support on the automatic address assignment model and support for PD issued from PD. Of course, I suspect there's just not enough interest in the linux dev community to bother. Finally, one of the home router firmware companies (which I believe linksys used when they didn't use linux) has had IPv6 support in their codebase for a year now. See nanog history. The manufacturers that use their code don't seem to have implemented the new IPv6 code. Jack (sick, so if it doesn't make sense, sorry) From charles at thewybles.com Fri Dec 4 00:56:27 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 3 Dec 2009 16:56:27 -0800 Subject: news from Google In-Reply-To: <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> Message-ID: <63E3E0F2-E398-4744-B58B-CB65E3216688@thewybles.com> LOL. One place I worked at hosted a bunch of websites and called them by business unit. so xxx_nnn One business unit was particularly problematic and frequently returned 500 errors. The version in production was xxx_4xx .... when the next major rev came out we skipped 5xx and went to 6xx. :) On Dec 3, 2009, at 12:36 PM, Matthew Petach wrote: > On Thu, Dec 3, 2009 at 12:09 PM, Scott Berkman wrote: >> Also reminds me of the Level 3 DNS servers in the 4.2.2.[1-8++] range. >> >> -Scott >> > > I suppose I've been too brainwashed by HTTP...I looked at that, and > thought that it would amusing to have a DNS server in the 4.0.2 range. ^_^; > > (for reference... http://en.wikipedia.org/wiki/HTTP_402#4xx_Client_Error > > 402 Payment Required > > :D > > Matt > From Jason.Weil at cox.com Fri Dec 4 02:53:47 2009 From: Jason.Weil at cox.com (Jason.Weil at cox.com) Date: Thu, 3 Dec 2009 21:53:47 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B18527F.7040403@brightok.net> References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> , <4B18527F.7040403@brightok.net> Message-ID: One of the better/only decent implementations I have run across in the retail world so far is the D-Link 615SW. Look for the IPv6_Ready Gold cert emblem (found this on an encap at Fry's and nobody in the department knew what IPv6 was) on the front of the box for easy recognition although there are other modems with RevC (think Rev_B works as well) firmware that don't have the label but work as well. The major feature missing is DHCPv6 IA_PD but you won't find this on any retail router that I am aware of today. What you will find though is WAN interface config via static, stateful or stateless DHCPv6 as well as stateful and stateless PPPoEv6. It even offers a DHCPv6 server for your LAN interfaces to boot. I am not sure if this product was built for the Japanese market and is now being released here to determine interest from the retail sector but it is useful for a trial lab or for testing at home. The major caveat of course is that all the IPv6 configs are done in Advanced Config mode and hence not designed for plug-and-play for your average home user. Jason ________________________________________ From: Jack Bates [jbates at brightok.net] Sent: Thursday, December 03, 2009 7:06 PM To: Mark Newton Cc: nanog at nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. Mark Newton wrote: > The fact that someone got OpenWRT working in less than a week of spare > time makes it totally clear why the commercial vendors haven't done > anything: They're just simply not interested, nothing more, nothing > less. I suspect they didn't use DHCPv6-PD with that OpenWRT. I've had issues with the dhcp client that comes with it in the past, though I've had an ubuntu box acting as a router with wide-dhcp doing -PD. It works okay, although the devs really should look at better support on the automatic address assignment model and support for PD issued from PD. Of course, I suspect there's just not enough interest in the linux dev community to bother. Finally, one of the home router firmware companies (which I believe linksys used when they didn't use linux) has had IPv6 support in their codebase for a year now. See nanog history. The manufacturers that use their code don't seem to have implemented the new IPv6 code. Jack (sick, so if it doesn't make sense, sorry) From jmamodio at gmail.com Fri Dec 4 02:57:23 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 3 Dec 2009 20:57:23 -0600 Subject: news from Google In-Reply-To: <63E3E0F2-E398-4744-B58B-CB65E3216688@thewybles.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> <63E3E0F2-E398-4744-B58B-CB65E3216688@thewybles.com> Message-ID: <202705b0912031857r119076e6q7badb73758e9baa0@mail.gmail.com> talking about evil http://www.bing.com/ : >Oops >This isn't the page you wanted! > >Try this >Refresh the page. If you get this message again, please check back later. > >Ref A: 7d09ba2186d4448a8dd2b99ad2c12b3a Ref B: B498C04FE4F5DC107DF8FC65998D9838 >Ref >C: Thu Dec 03 18:54:06 2009 PST While the younger evil keeps trying to provide better and faster services the oldest one seems to be doing their best effort to screw them. PS. SANS is reporting the service down http://isc.sans.org/diary.html Cheers Jorge From charles at thewybles.com Fri Dec 4 04:03:45 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 3 Dec 2009 20:03:45 -0800 Subject: news from Google In-Reply-To: <202705b0912031857r119076e6q7badb73758e9baa0@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> <63E3E0F2-E398-4744-B58B-CB65E3216688@thewybles.com> <202705b0912031857r119076e6q7badb73758e9baa0@mail.gmail.com> Message-ID: <173AA55C-E648-4130-8D3B-9F0013B9A0E5@thewybles.com> That is an Akami error. On Dec 3, 2009, at 6:57 PM, Jorge Amodio wrote: > talking about evil http://www.bing.com/ : > >> Oops >> This isn't the page you wanted! >> >> Try this >> Refresh the page. If you get this message again, please check back later. >> >> Ref A: 7d09ba2186d4448a8dd2b99ad2c12b3a Ref B: B498C04FE4F5DC107DF8FC65998D9838 >Ref >C: Thu Dec 03 18:54:06 2009 PST > From frnkblk at iname.com Fri Dec 4 05:09:35 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 3 Dec 2009 23:09:35 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> , <4B18527F.7040403@brightok.net> Message-ID: Give their emulator a try: http://support.dlink.com/emulators/dir615_revC/310NA/login.htm Perhaps this is a dumb question, but without DHCPv6 IA_PD support, how are "other" large service providers rolling out IPv6 for their cable broadband, xDSL, BWA, and FTTH customers? 100% SLAAC? Frank -----Original Message----- From: Jason.Weil at cox.com [mailto:Jason.Weil at cox.com] Sent: Thursday, December 03, 2009 8:54 PM To: jbates at brightok.net; newton at internode.com.au Cc: nanog at nanog.org Subject: RE: Consumer Grade - IPV6 Enabled Router Firewalls. One of the better/only decent implementations I have run across in the retail world so far is the D-Link 615SW. Look for the IPv6_Ready Gold cert emblem (found this on an encap at Fry's and nobody in the department knew what IPv6 was) on the front of the box for easy recognition although there are other modems with RevC (think Rev_B works as well) firmware that don't have the label but work as well. The major feature missing is DHCPv6 IA_PD but you won't find this on any retail router that I am aware of today. What you will find though is WAN interface config via static, stateful or stateless DHCPv6 as well as stateful and stateless PPPoEv6. It even offers a DHCPv6 server for your LAN interfaces to boot. I am not sure if this product was built for the Japanese market and is now being released here to determine interest from the retail sector but it is useful for a trial lab or for testing at home. The major caveat of course is that all the IPv6 configs are done in Advanced Config mode and hence not designed for plug-and-play for your average home user. Jason ________________________________________ From: Jack Bates [jbates at brightok.net] Sent: Thursday, December 03, 2009 7:06 PM To: Mark Newton Cc: nanog at nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. Mark Newton wrote: > The fact that someone got OpenWRT working in less than a week of spare > time makes it totally clear why the commercial vendors haven't done > anything: They're just simply not interested, nothing more, nothing > less. I suspect they didn't use DHCPv6-PD with that OpenWRT. I've had issues with the dhcp client that comes with it in the past, though I've had an ubuntu box acting as a router with wide-dhcp doing -PD. It works okay, although the devs really should look at better support on the automatic address assignment model and support for PD issued from PD. Of course, I suspect there's just not enough interest in the linux dev community to bother. Finally, one of the home router firmware companies (which I believe linksys used when they didn't use linux) has had IPv6 support in their codebase for a year now. See nanog history. The manufacturers that use their code don't seem to have implemented the new IPv6 code. Jack (sick, so if it doesn't make sense, sorry) From joe at nethead.com Fri Dec 4 05:14:29 2009 From: joe at nethead.com (Joe Hamelin) Date: Thu, 3 Dec 2009 21:14:29 -0800 Subject: Sr. Net Eng needed. Message-ID: <79db6ae0912032114s1303c6djfadaf4fe1159aaed@mail.gmail.com> Lots of travel, 6 month contract, 4G build-out. Contact Voshte at vgustafson at kforce.com. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From hank at efes.iucc.ac.il Fri Dec 4 05:14:51 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 4 Dec 2009 07:14:51 +0200 (IST) Subject: news from Google In-Reply-To: <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> Message-ID: On Thu, 3 Dec 2009, Jorge Amodio wrote: >> now Google DNS, anything more? > > GoogleNation. Google Opt-out Village: http://www.theonion.com/content/video/google_opt_out_feature_lets_users -Hank From mmc at internode.com.au Fri Dec 4 05:28:29 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 04 Dec 2009 15:58:29 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> , <4B18527F.7040403@brightok.net> Message-ID: <4B189DFD.5090100@internode.com.au> DHCPv6 PD is pretty crucial. I'd love to see the code in an ADSL box (hint hint hint DLINK). MMC Frank Bulk wrote: > Give their emulator a try: > http://support.dlink.com/emulators/dir615_revC/310NA/login.htm > > Perhaps this is a dumb question, but without DHCPv6 IA_PD support, how are > "other" large service providers rolling out IPv6 for their cable broadband, > xDSL, BWA, and FTTH customers? 100% SLAAC? > > Frank > > -----Original Message----- > From: Jason.Weil at cox.com [mailto:Jason.Weil at cox.com] > Sent: Thursday, December 03, 2009 8:54 PM > To: jbates at brightok.net; newton at internode.com.au > Cc: nanog at nanog.org > Subject: RE: Consumer Grade - IPV6 Enabled Router Firewalls. > > One of the better/only decent implementations I have run across in the > retail world so far is the D-Link 615SW. Look for the IPv6_Ready Gold cert > emblem (found this on an encap at Fry's and nobody in the department knew > what IPv6 was) on the front of the box for easy recognition although there > are other modems with RevC (think Rev_B works as well) firmware that don't > have the label but work as well. The major feature missing is DHCPv6 IA_PD > but you won't find this on any retail router that I am aware of today. What > you will find though is WAN interface config via static, stateful or > stateless DHCPv6 as well as stateful and stateless PPPoEv6. It even offers a > DHCPv6 server for your LAN interfaces to boot. > > I am not sure if this product was built for the Japanese market and is now > being released here to determine interest from the retail sector but it is > useful for a trial lab or for testing at home. The major caveat of course is > that all the IPv6 configs are done in Advanced Config mode and hence not > designed for plug-and-play for your average home user. > > Jason > ________________________________________ > From: Jack Bates [jbates at brightok.net] > Sent: Thursday, December 03, 2009 7:06 PM > To: Mark Newton > Cc: nanog at nanog.org > Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. > > Mark Newton wrote: > >> The fact that someone got OpenWRT working in less than a week of spare >> time makes it totally clear why the commercial vendors haven't done >> anything: They're just simply not interested, nothing more, nothing >> less. >> > > I suspect they didn't use DHCPv6-PD with that OpenWRT. I've had issues > with the dhcp client that comes with it in the past, though I've had an > ubuntu box acting as a router with wide-dhcp doing -PD. It works okay, > although the devs really should look at better support on the automatic > address assignment model and support for PD issued from PD. Of course, I > suspect there's just not enough interest in the linux dev community to > bother. > > Finally, one of the home router firmware companies (which I believe > linksys used when they didn't use linux) has had IPv6 support in their > codebase for a year now. See nanog history. The manufacturers that use > their code don't seem to have implemented the new IPv6 code. > > > Jack (sick, so if it doesn't make sense, sorry) > > > > > > From surfer at mauigateway.com Fri Dec 4 07:14:57 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 3 Dec 2009 23:14:57 -0800 Subject: news from Google Message-ID: <20091203231457.47DBE2DF@resin18.mta.everyone.net> jof at thejof.com : 6.6.6.6 belongs to the US Army look at AS 666. At least they know their position in the universe. --------------------------------------------------- andrey.gordon at gmail.com : IMHO that's where we are heading with google taking over every service imaginable Only if you let them. DBS (don't be sheep) --------------------------------------------------- At the most basic minimum manage your cookies. Just a quick search (not with google) gives: google.com/support/urchin45/bin/answer.py?answer=28710 (you'll see a LOT of _utm type cookies as soon as you start watching them) There are many other companies out there that know more about you than you think possible. Small example: Do you allow third party cookies unfettered access to what you do? scott From wbailey at gci.com Fri Dec 4 08:07:36 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 3 Dec 2009 23:07:36 -0900 Subject: news from Google Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA606@DTN1EX01.gci.com> Anyone volunteer to FedEx Scott here a tin foil hat?? If not, I'll be happy to provide one... *cue xfiles theme....* Sent from my Blackberry. Please execute spelling errors. ----- Original Message ----- From: Scott Weeks To: nanog at merit.edu Sent: Thu Dec 03 22:14:57 2009 Subject: Re: news from Google jof at thejof.com : 6.6.6.6 belongs to the US Army look at AS 666. At least they know their position in the universe. --------------------------------------------------- andrey.gordon at gmail.com : IMHO that's where we are heading with google taking over every service imaginable Only if you let them. DBS (don't be sheep) --------------------------------------------------- At the most basic minimum manage your cookies. Just a quick search (not with google) gives: google.com/support/urchin45/bin/answer.py?answer=28710 (you'll see a LOT of _utm type cookies as soon as you start watching them) There are many other companies out there that know more about you than you think possible. Small example: Do you allow third party cookies unfettered access to what you do? scott From greg at bestnet.kharkov.ua Fri Dec 4 09:08:55 2009 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Fri, 4 Dec 2009 11:08:55 +0200 Subject: port scanning from spoofed addresses In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D775E7EE2D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> <823a3sarl9.fsf@mid.bfk.de> <483E6B0272B0284BA86D7596C40D29F9D775E7EE2C@PUR-EXCH07.ox.com> <68F8A2BA-0B32-440C-8E1F-296135860B70@thewybles.com> <483E6B0272B0284BA86D7596C40D29F9D775E7EE2D@PUR-EXCH07.ox.com> Message-ID: <20091204110855.4cca5901@greg.bestnet.kharkov.ua> On Thu, 3 Dec 2009 13:03:20 -0500 Matthew Huff wrote: > I'm not at all concerned about door-knob twisting or network > scanning. What concerns me is that the source addresses are spoofed > from our address range and that our upstream providers aren't willing > to even look at the problem. > But that can be easy addressed by yourself. just do not allow traffic originating from your range on your external interfaces. -- With best regards, Gregory Edigarov From ops.lists at gmail.com Fri Dec 4 09:29:50 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 4 Dec 2009 14:59:50 +0530 Subject: port scanning from spoofed addresses In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D775E7EE24@PUR-EXCH07.ox.com> Message-ID: On Thu, Dec 3, 2009 at 10:35 PM, Matthew Huff wrote: > We are seeing a large number of tcp connection attempts to ports known to have security issues. The source addresses are spoofed from our address range. They are easy to block at our border router obviously, but the number and volume is a bit worrisome. Our upstream providers appear to be uninterested in tracing or blocking them. Is this the new normal? One of my concerns is that if others are seeing probe attempts, they will see them from these addresses and of course, contact us. > > Any suggestions on what to do next? Or just ignore. Filter it out and then ignore. Might as well filter it out - see http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html From jmamodio at gmail.com Fri Dec 4 11:29:01 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 4 Dec 2009 05:29:01 -0600 Subject: news from Google In-Reply-To: <20091203231457.47DBE2DF@resin18.mta.everyone.net> References: <20091203231457.47DBE2DF@resin18.mta.everyone.net> Message-ID: <202705b0912040329j26a132betcb87ee28793c7a7e@mail.gmail.com> > : IMHO that's where we are heading with google taking over every service imaginable Well nobody is forcing to use their services ... For search you can use bing when is not down, for email you can use outlook when the windoze bootnet is not being used to distribute viruses or malware, or hotmail if you want plenty of nice ads directed to fulfill your needs and preferences, for video you can still use YouTube, uuuppppsss you right evil Google owns them now, for maps you can use mapquest if you want to get to a place a mile away where you intended to go, ohhh but they are owned by one of the failed-ex-evils, want to take a quick peak at a book, you can still go to your local library, what else, ohhh yes wanna blog ? use wordpress and wait for the poetry to become hacked. Yes, all eggs in the same basket for some stuff is not a good approach, but what's wrong about using services that are relatively nice, regularly available and being constantly improved, and free ? Well, right nothing is free, you are part of their monetization and world domination scheme ... bad boy Eric, bad boy ... > Only if you let them. ?DBS (don't be sheep) That's 100% right, if you want privacy just don't make yourself public. I'm more concerned about information that by law is being made public and available on-line (like property records in the US) out of my control, or not very easy to "opt-out". Cheers Jorge From jmamodio at gmail.com Fri Dec 4 12:11:34 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 4 Dec 2009 06:11:34 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B16F535.70306@sunwave.net> References: <4B16F535.70306@sunwave.net> Message-ID: <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> I guess Cisco's 800's are out of the "Consumer Grade" price range, but any comments about v6 support on them and how they compare with other options. Just looking for feedback about good options for sort remote/branch/home office. Regards Jorge From ssrigha at gmail.com Fri Dec 4 12:18:43 2009 From: ssrigha at gmail.com (shake righa) Date: Fri, 4 Dec 2009 15:18:43 +0300 Subject: Route Target rewrite In-Reply-To: References: <73439e5a0911291834pc088ehb6eb88005a0b8222@mail.gmail.com> Message-ID: <73439e5a0912040418r228d7b3dkc8c7484bf44ae15e@mail.gmail.com> Thanks Shahid. On 11/30/09, Lala Lander wrote: > Please try this URL. If it doesnt work for you, let me know and I'll send > you a working example. > > http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsrtrw4.html > > Pretty straight forward configuration. > > thanks, > Shahid > > On Sun, Nov 29, 2009 at 6:34 PM, shake righa wrote: > >> Anyone with material on how to perform route target re-write as well as >> filtering during vpnv4 BGP sessions. >> >> Have been ttying but the rewrite is not occuring. >> >> Regards, >> Shake Righa >> > From mmc at internode.com.au Fri Dec 4 12:29:49 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 4 Dec 2009 22:59:49 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> References: <4B16F535.70306@sunwave.net> <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> Message-ID: <0181FC63-6A37-4AEC-83E0-EB570B94DB2A@internode.com.au> They work pretty well. They're one of the few that you can buy which supports DSL and they work. IPv6 support on the WIFI interfaces is IOS version dependent. They support DHCPv6 PD etc. I'm using one right now with v6. MMC On 04/12/2009, at 10:41 PM, Jorge Amodio wrote: > I guess Cisco's 800's are out of the "Consumer Grade" price range, but > any comments > about v6 support on them and how they compare with other options. > > Just looking for feedback about good options for sort remote/branch/home office. > > Regards > Jorge > -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile From trejrco at gmail.com Fri Dec 4 13:16:57 2009 From: trejrco at gmail.com (TJ) Date: Fri, 4 Dec 2009 08:16:57 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <1C9EF593-91C4-445C-8EE7-7671509E51FF@internode.com.au> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <01f001ca7412$6f53d9c0$4dfb8d40$@com> <1C9EF593-91C4-445C-8EE7-7671509E51FF@internode.com.au> Message-ID: <006601ca74e4$1673be10$435b3a30$@com> >From: Mark Newton [mailto:newton at internode.com.au] > > > FWIW - The (Cisco) Linksys 610N does (and perhaps others do?) the same > > amount of IPv6 the Airport Extreme does - 6to4, SLAAC - out of the > > box, by default. In fact, I am not sure you can turn it off .. > > Yep -- which is worse than useless in the presence of a service > provider that's already offering dual-stack service. > I might agree, if my provider offered native IPv6. They don't, so this minimal level of IPv6 is much better than nothing. > (glares at Cisco/Linksys) Don't restrict yourself to just Cisco/Linksys - glare at all of the vendors, and the providers for that matter. :) And don't just glare, poke them insistently / incessantly! /TJ From jeff at ocjtech.us Fri Dec 4 13:21:17 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 4 Dec 2009 07:21:17 -0600 Subject: news from Google In-Reply-To: <202705b0912040329j26a132betcb87ee28793c7a7e@mail.gmail.com> References: <20091203231457.47DBE2DF@resin18.mta.everyone.net> <202705b0912040329j26a132betcb87ee28793c7a7e@mail.gmail.com> Message-ID: <935ead450912040521j33fb41e4vf8732b58ed8cbd45@mail.gmail.com> On Fri, Dec 4, 2009 at 5:29 AM, Jorge Amodio wrote: > > I'm more concerned about information that by law is being made public > and available > on-line (like property records in the US) out of my control, or not very easy to > "opt-out". Property records have always been public information in the US, and no one can "opt out" (well, I suppose you could sell your house). Having information like this available to the public is important because the government uses those records to make decisions like property tax rates. If you were allowed to opt out it would be difficult or impossible for the public to monitor these government actions. For example, if you thought that you were being charged more property tax than you thought you should you could examine the property records for properties that were comparable to yours and see what they were being charged. If all of your neighbors had opted out you wouldn't be able to do that (at least not with out going to court). Similarly, if you were looking at buying a house you could check the property records to see if any liens had been made against the property or if you could afford to pay the property taxes. -- Jeff Ollie From williams.bruce at gmail.com Fri Dec 4 13:23:04 2009 From: williams.bruce at gmail.com (Bruce Williams) Date: Fri, 4 Dec 2009 05:23:04 -0800 Subject: news from Google In-Reply-To: <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> Message-ID: <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> On Thu, Dec 3, 2009 at 2:20 PM, Paul S. R. Chisholm wrote: > On Thu, Dec 3, 2009 at 5:07 PM, Ken Chase wrote: > > We all know that google is leveraging cross-referenceable information > from all > > of its services for its profit/advantage ... > > > > /kc > > -- > > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > Front St. W. > > Ken, this was addressed in the announcement: > > http://code.google.com/speed/public-dns/privacy.html > > We built Google Public DNS to make the web faster and to retain as > little information about usage as we could, while still being able to > detect and fix problems. Google Public DNS does not permanently store > personally identifiable information. > > http://code.google.com/speed/public-dns/faq.html#account > http://code.google.com/speed/public-dns/faq.html#shared > http://code.google.com/speed/public-dns/faq.html#info > > Is any of the information collected stored with my Google account? > No. > Does Google share the information it collects from the Google Public > DNS service with anyone else? > No. > Is information about my queries to Google Public DNS shared with other > Google properties, such as Search, Gmail, ads networks, etc.? > No. > > Hope this helps. --PSRC > > And this will never change? Not even when you check the box for the latest update that says it changes some terms and here is the link,,,,,,, Bruce -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From richard at bennett.com Fri Dec 4 13:53:32 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 04 Dec 2009 05:53:32 -0800 Subject: news from Google In-Reply-To: <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> Message-ID: <4B19145C.8060704@bennett.com> Bruce Williams wrote: On Thu, Dec 3, 2009 at 2:20 PM, Paul S. R. Chisholm [1]wrote On Thu, Dec 3, 2009 at 5:07 PM, Ken Chase [2] wrote: We all know that google is leveraging cross-referenceable information from all of its services for its profit/advantage ... /kc -- Ken Chase - [3]ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. Ken, this was addressed in the announcement: [4]http://code.google.com/speed/public-dns/privacy.html We built Google Public DNS to make the web faster and to retain as little information about usage as we could, while still being able to detect and fix problems. Google Public DNS does not permanently store personally identifiable information. [5]http://code.google.com/speed/public-dns/faq.html#account [6]http://code.google.com/speed/public-dns/faq.html#shared [7]http://code.google.com/speed/public-dns/faq.html#info Is any of the information collected stored with my Google account? No. Does Google share the information it collects from the Google Public DNS service with anyone else? No. Is information about my queries to Google Public DNS shared with other Google properties, such as Search, Gmail, ads networks, etc.? No. Hope this helps. --PSRC And this will never change? Not even when you check the box for the latest update that says it changes some terms and here is the link,,,,,,, Bruce The Adsense tracking cookie was once an opt-in, but after Google acquired that company and crushed the competition it became an opt-out, unbeknownst to many consumers. This is the way these generally go. Google will be all sweetness and light until they've crushed OpenDNS, and when the competitor's out of the picture, they'll get down to the monetizing. -- Richard Bennett References 1. mailto:psrchisholm at gmail.com 2. mailto:math at sizone.org 3. mailto:ken at heavycomputing.ca 4. http://code.google.com/speed/public-dns/privacy.html 5. http://code.google.com/speed/public-dns/faq.html#account 6. http://code.google.com/speed/public-dns/faq.html#shared 7. http://code.google.com/speed/public-dns/faq.html#info From mohacsi at niif.hu Fri Dec 4 14:14:58 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 4 Dec 2009 15:14:58 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> References: <4B16F535.70306@sunwave.net> <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> Message-ID: On Fri, 4 Dec 2009, Jorge Amodio wrote: > I guess Cisco's 800's are out of the "Consumer Grade" price range, but > any comments > about v6 support on them and how they compare with other options. > > Just looking for feedback about good options for sort remote/branch/home office. Some 800's are supporting IPv6 very well even DHCPv6-PD. We tested 83x, 87x, 88x. No IPv6 support however for 80x and 85x series. We also tested Juniper Netscreen - they are also very capable devices. Best Regards, Janos Mohacsi From andrey.gordon at gmail.com Fri Dec 4 14:16:58 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Fri, 4 Dec 2009 09:16:58 -0500 Subject: news from Google In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA606@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA606@DTN1EX01.gci.com> Message-ID: <90ccfc90912040616u391a7a65u38378952a15e6f24@mail.gmail.com> I agree, one could find this though paranoid, but even if we don't use google out of fear that they will take over everything they still seem to be growing. What I'm trying to say is that you/we/they can take all the placards you/we/they want and go and try to convince (or at least educate) the public that google is becoming an evil empire, but there are enough sheep out there to make google succeed. Google makes it's services very attractive to use (free, convenient, great functionality, integration, etc) so we do for the most part. There is a chance that soon google will be collecting "statistics" on all aspects of your digital life and that government has to do is to pass a law or even more than that, nationalize google. That's just one paranoid theory I've got. Send your tin foil hats and emails to PO Box 666, Antarctica, The World. Remember? They started as a search engine? Not sure how, but they are becoming (became) the new Micro$oft, IMHO. ----- Andrey Gordon [andrey.gordon at gmail.com] On Fri, Dec 4, 2009 at 3:07 AM, Warren Bailey wrote: > Anyone volunteer to FedEx Scott here a tin foil hat?? If not, I'll be happy > to provide one... *cue xfiles theme....* > > Sent from my Blackberry. Please execute spelling errors. > > ----- Original Message ----- > From: Scott Weeks > To: nanog at merit.edu > Sent: Thu Dec 03 22:14:57 2009 > Subject: Re: news from Google > > > > jof at thejof.com > > : 6.6.6.6 belongs to the US Army > > look at AS 666. At least they know their position in the universe. > --------------------------------------------------- > > > andrey.gordon at gmail.com > > : IMHO that's where we are heading with google taking over every service > imaginable > > Only if you let them. DBS (don't be sheep) > --------------------------------------------------- > > > > At the most basic minimum manage your cookies. Just a quick search (not > with google) gives: > google.com/support/urchin45/bin/answer.py?answer=28710 (you'll see a LOT > of _utm type cookies as soon as you start watching them) > > There are many other companies out there that know more about you than you > think possible. Small example: Do you allow third party cookies unfettered > access to what you do? > > scott > > From jmamodio at gmail.com Fri Dec 4 14:34:40 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 4 Dec 2009 08:34:40 -0600 Subject: news from Google In-Reply-To: <90ccfc90912040616u391a7a65u38378952a15e6f24@mail.gmail.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA606@DTN1EX01.gci.com> <90ccfc90912040616u391a7a65u38378952a15e6f24@mail.gmail.com> Message-ID: <202705b0912040634g7fdc0b2cn1954f901cbc694de@mail.gmail.com> > Remember? They started as a search engine? Not sure how, but they are > becoming (became) the new Micro$oft, IMHO. Hmnm, I don't agree with your opinion, Micro$oft keeps making money out of you just repackaging and reselling the same crappy software over and over and making people pay for a large number of features they will never use, imposing their OS through hardware distributors and crushing anyone who they may feel becomes a threat to their biz model. Remember? The started as a software company, and still don't get it, IMHO. Regards Jorge From andrey.gordon at gmail.com Fri Dec 4 14:42:38 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Fri, 4 Dec 2009 09:42:38 -0500 Subject: news from Google In-Reply-To: <202705b0912040634g7fdc0b2cn1954f901cbc694de@mail.gmail.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA606@DTN1EX01.gci.com> <90ccfc90912040616u391a7a65u38378952a15e6f24@mail.gmail.com> <202705b0912040634g7fdc0b2cn1954f901cbc694de@mail.gmail.com> Message-ID: <90ccfc90912040642j2885c2e0k13cebf8b983908a2@mail.gmail.com> I didn't say that google is now a software company, i meant they are present in more and more aspects of your life, but yeah, i guess not the best example. Cheers ----- Andrey Gordon [andrey.gordon at gmail.com] On Fri, Dec 4, 2009 at 9:34 AM, Jorge Amodio wrote: > > Remember? They started as a search engine? Not sure how, but they are > > becoming (became) the new Micro$oft, IMHO. > > Hmnm, I don't agree with your opinion, Micro$oft keeps making money out > of you just repackaging and reselling the same crappy software over and > over > and making people pay for a large number of features they will never use, > imposing their OS through hardware distributors and crushing anyone > who they may feel becomes a threat to their biz model. > > Remember? The started as a software company, and still don't get it, IMHO. > > Regards > Jorge > From williams.bruce at gmail.com Fri Dec 4 14:53:34 2009 From: williams.bruce at gmail.com (Bruce Williams) Date: Fri, 4 Dec 2009 06:53:34 -0800 Subject: news from Google In-Reply-To: <4B19145C.8060704@bennett.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> Message-ID: <775e001a0912040653l14d7e4d7vc705883fd1be9240@mail.gmail.com> "We plan to share what we learn from this experimental rollout of Google Public DNS with the broader web community and other DNS providers, to improve the browsing experience for Internet users globally." I wonder how the world managed to function before Google came along.... Bruce On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett wrote: > Bruce Williams wrote: > > On Thu, Dec 3, 2009 at 2:20 PM, Paul S. R. Chisholm wrote > > On Thu, Dec 3, 2009 at 5:07 PM, Ken Chase wrote: > > > We all know that google is leveraging cross-referenceable information > > > from all > > > of its services for its profit/advantage ... > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > > > Front St. W. > > Ken, this was addressed in the announcement: > http://code.google.com/speed/public-dns/privacy.html > > We built Google Public DNS to make the web faster and to retain as > little information about usage as we could, while still being able to > detect and fix problems. Google Public DNS does not permanently store > personally identifiable information. > http://code.google.com/speed/public-dns/faq.html#accounthttp://code.google.com/speed/public-dns/faq.html#sharedhttp://code.google.com/speed/public-dns/faq.html#info > > Is any of the information collected stored with my Google account? > No. > Does Google share the information it collects from the Google Public > DNS service with anyone else? > No. > Is information about my queries to Google Public DNS shared with other > Google properties, such as Search, Gmail, ads networks, etc.? > No. > > Hope this helps. --PSRC > > > And this will never change? Not even when you check the box for the latest > update that says it changes some terms and here is the link,,,,,,, > > Bruce > > > The Adsense tracking cookie was once an opt-in, but after Google acquired > that company and crushed the competition it became an opt-out, unbeknownst > to many consumers. This is the way these generally go. Google will be all > sweetness and light until they've crushed OpenDNS, and when the competitor's > out of the picture, they'll get down to the monetizing. > > -- > Richard Bennett > > -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From nicotine at warningg.com Fri Dec 4 15:44:42 2009 From: nicotine at warningg.com (Brandon Ewing) Date: Fri, 4 Dec 2009 09:44:42 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <0181FC63-6A37-4AEC-83E0-EB570B94DB2A@internode.com.au> References: <4B16F535.70306@sunwave.net> <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> <0181FC63-6A37-4AEC-83E0-EB570B94DB2A@internode.com.au> Message-ID: <20091204154442.GE8736@radiological.warningg.com> On Fri, Dec 04, 2009 at 10:59:49PM +1030, Matthew Moyle-Croft wrote: > They work pretty well. > > They're one of the few that you can buy which supports DSL and they work. IPv6 support on the WIFI interfaces is IOS version dependent. > > They support DHCPv6 PD etc. I'm using one right now with v6. > > MMC > Can you comment on what version you got it to work on? I haven't futzed with it much, but with 12.4(24)T2, you can't put an ipv6 address directly on the wireless subinterface. I tried putting it on a BVI interface, but didn't have much luck. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jnegro at billtrust.com Fri Dec 4 16:25:43 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 4 Dec 2009 11:25:43 -0500 Subject: SPF Configurations Message-ID: <3C5B084431653D4A9C469A22AFCDB5B9042929E8@LOGAN.billtrust.local> I'm wondering if a few DNS experts out there could give me some input on SPF record configuration. Our company sends out about 50k - 100k emails a day, and most emails are on behalf of customers to their end users at various domains (no, we're not spammers, these are email notifications the end users have requested to receive). Some customers insist on making the FROM address use their domain name, but the emails leave our mail servers on our domain. SPF seems to be the way we could possibly avoid more spam filters, and delivery rate is very important to our company. The server configuration consists of a mail server that sends outbound only, out of a specific IP with proper MX, A, and PTR records. This is a sample of the SPF configuration I believe would be correct: Our company (example.com) records: IN MX 10 mail.example.com mail IN A example.com IN TXT "v=spf1 mx -all" example.com IN SPF "v=spf1 mx -all" mail IN TXT "v=spf1 a -all" mail IN SPF "v=spf1 a -all" customer.com IN TXT "v=spf1 include:example.com -all" customer.com IN SPF "v=spf1 include:example.com -all" Our customer's (customer.com) records: IN MX 10 mail.customer.com mail IN A customer.com IN TXT "v=spf1 mx -all" customer.com IN SPF "v=spf1 mx -all" mail IN TXT "v=spf1 a -all" mail IN SPF "v=spf1 a -all" customer.com IN TXT "v=spf1 include:example.com -all" customer.com IN SPF "v=spf1 include:example.com -all" I derived this from this tutorial: http://www.zytrax.com/books/dns/ch9/spf.html . The other part of this that may be of importance would be the NATing. The FQDN that the world sees for the outside address of the NAT is not the same as the inside FQDN that Postfix is using internally. Does this cause any problems with SPF? Any comments or suggestions would be great. Thanks in advance! Jeffrey From jnegro at billtrust.com Fri Dec 4 16:45:12 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 4 Dec 2009 11:45:12 -0500 Subject: SPF Configurations In-Reply-To: <09120408252597_5AC@oregon.uoregon.edu> References: <09120408252597_5AC@oregon.uoregon.edu> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain. I'll check into MAAWG as well Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro at billtrust.com -----Original Message----- From: Joe St Sauver [mailto:joe at oregon.uoregon.edu] Sent: Friday, December 04, 2009 11:25 AM To: Jeffrey Negro Subject: Re: SPF Configurations #Some customers insist on #making the FROM address use their domain name, but the emails leave our #mail servers on our domain. Then your IPs or outbound mail servers should be listed on the customer's SPF record... assuming they also send their own mail, they obviously also want to list their own mail servers. #SPF seems to be the way we could possibly avoid more spam filters, SPF only provides a way of avoiding spoofing, it does not necessarily enhance your IP reputation or your domain reputation #and delivery rate is very important to our company. Are you involved with MAAWG? (see www.maawg.org) Regards, Joe From bclark at spectraaccess.com Fri Dec 4 16:48:21 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 04 Dec 2009 11:48:21 -0500 Subject: SPF Configurations In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> Message-ID: <4B193D55.8030400@spectraaccess.com> If the customer insist on using their domain, then you would have to have the customer setup an SPF record within their domain that points to your email server IP blocks. I would just tell your customer that if they insist of using their FROM domain, to help get past someone's spamming system the customer is going to have to add the a SPF record to their domain similar to the following: [customer domain].com. IN TXT "v=spf1 a mx ip4:[your IP block] Putting an SPF record in your DNS record will have no affect on spamming software. SPF is basically another form of reverse DNS at the mail level. Bret Jeffrey Negro wrote: > Thanks for your input on this. My main concern is mail filters at the > end users side thinking that our mail servers are spoofing our > customer's domain. I'll check into MAAWG as well > > Jeffrey Negro, Network Engineer > Billtrust - Improving Your Billing, Improving Your Business > www.billtrust.com > 609.235.1010 x137 > jnegro at billtrust.com > > -----Original Message----- > From: Joe St Sauver [mailto:joe at oregon.uoregon.edu] > Sent: Friday, December 04, 2009 11:25 AM > To: Jeffrey Negro > Subject: Re: SPF Configurations > > #Some customers insist on > #making the FROM address use their domain name, but the emails leave our > #mail servers on our domain. > > Then your IPs or outbound mail servers should be listed on the > customer's > SPF record... assuming they also send their own mail, they obviously > also > want to list their own mail servers. > > #SPF seems to be the way we could possibly avoid more spam filters, > > SPF only provides a way of avoiding spoofing, it does not necessarily > enhance your IP reputation or your domain reputation > > #and delivery rate is very important to our company. > > Are you involved with MAAWG? (see www.maawg.org) > > Regards, > > Joe > > From jwbensley at gmail.com Fri Dec 4 17:03:08 2009 From: jwbensley at gmail.com (James Bensley) Date: Fri, 4 Dec 2009 17:03:08 +0000 Subject: SPF Configurations In-Reply-To: <4B193D55.8030400@spectraaccess.com> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> Message-ID: <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> 2009/12/4 Bret Clark > If the customer insist on using their domain, then you would have to have > the customer setup an SPF record within their domain that points to your > email server IP blocks. I would just tell your customer that if they insist > of using their FROM domain, to help get past someone's spamming system the > customer is going to have to add the a SPF record to their domain similar to > the following: > > [customer domain].com. IN TXT "v=spf1 a mx ip4:[your IP block] > > Putting an SPF record in your DNS record will have no affect on spamming > software. SPF is basically another form of reverse DNS at the mail level. > > Bret The problem we face is that some people we work with can't do that, they can't even grasp what an SPF record is and so as far as our own spam filtering goes, we have filtered their emails to us sent with the FROM address being an @mysurname.com domain which doesn't exist and as a result we have filtered out their mails so we have had to lower our SPF checking slightly which is so annoying :S -- Regards, James ;) Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." From johnl at iecc.com Fri Dec 4 17:25:04 2009 From: johnl at iecc.com (John Levine) Date: 4 Dec 2009 17:25:04 -0000 Subject: SPF Configurations In-Reply-To: <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> Message-ID: <20091204172504.30269.qmail@simone.iecc.com> >> If the customer insist on using their domain, then you would have to have >> the customer setup an SPF record within their domain that points to your >> email server IP blocks. Right. The only major mail system that pays attention to SPF is Hotmail, but there are enough small poorly run MTAs that use it that an SPF record which lists your outbounds and ~all (not -all) can be marginally useful to avoid bogus rejections of your mail. As everyone here should already know, the fundamental problem with SPF is that although it does an OK job of describing the mail sending patterns of dedicated bulk mail systems, it can't model the way that normal mail systems with human users work. But so deep is the faith of the SPF cult that they blame the world for not matching SPF rather than the other way around, believing that it prevent forgery, having redefined "forgery" as whatever it is that SPF prevents. As the operator of one of the world's more heavily forged domains (abuse.net) I can report that if you think it prevents forgery blowback, you are mistaken. For rants about how badly the world and/or SPF stink, followups to Spam-L. For proposals about other anti-spam magic bullets, followups to ASRG. R's, John From morrowc.lists at gmail.com Fri Dec 4 18:25:11 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 4 Dec 2009 10:25:11 -0800 Subject: news from Google In-Reply-To: <4B19145C.8060704@bennett.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> Message-ID: <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett wrote: > ? Google will be all sweetness and light until they've crushed OpenDNS, > ? and when the competitor's out of the picture, they'll get down to the > ? monetizing. one note: OpenDNS is not the only 'competitor' here.... just one of the better obviously known ones. ie: 4.2.2.2 L(3) 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU Neustar (can't recall ips, sorry) -chris From scott at sberkman.net Fri Dec 4 18:53:17 2009 From: scott at sberkman.net (Scott Berkman) Date: Fri, 4 Dec 2009 13:53:17 -0500 Subject: news from Google In-Reply-To: <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: <015d01ca7513$0b483370$21d89a50$@net> You really can?t count the open Level3/GTEI DNS servers as a competitor for OpenDNS or what Google has just released. These are completely unsupported, and use of these servers from outside Level 3 has been blocked/delayed at different times. I use these all the time for testing and for my own personal use, but depending on these for anything production is a very bad idea. Plus OpenDNS's model is based on selling you their higher level services, while I am sure Google will eventually link the service to google accounts to track your web usage just like they track, index, and show you ads based on your web searches, email messages, etc. Then again, depending on OpenDNS, Google, or anything else outside your control for production services probably isn't a good idea anyway. -Scott -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Friday, December 04, 2009 1:25 PM To: Richard Bennett Cc: nanog at nanog.org; ken at heavycomputing.ca Subject: Re: news from Google On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett wrote: > ? Google will be all sweetness and light until they've crushed OpenDNS, > ? and when the competitor's out of the picture, they'll get down to the > ? monetizing. one note: OpenDNS is not the only 'competitor' here.... just one of the better obviously known ones. ie: 4.2.2.2 L(3) 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU Neustar (can't recall ips, sorry) -chris From graeme at graemef.net Fri Dec 4 18:58:55 2009 From: graeme at graemef.net (Graeme Fowler) Date: Fri, 04 Dec 2009 18:58:55 +0000 Subject: SPF Configurations In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> Message-ID: <1259953135.30483.4.camel@ernie.internal.graemef.net> On Fri, 2009-12-04 at 11:45 -0500, Jeffrey Negro wrote: > Thanks for your input on this. My main concern is mail filters at the > end users side thinking that our mail servers are spoofing our > customer's domain. If you really feel that SPF is going to help, then keep all the mail in your domain's control by using VERP addresses as the envelope sender address (like most decent modern MLM packages do). That way you can have a "From: " header in the customer domain (or of your choosing), and the envelope sender in your own. The benefit here is that not only does it make the usage of SPF a lot less complex, but it also means that all bounces come back to the originating system and can be handled accordingly. Have a look at the headers of this message for a well-formed example. Of course, this does depend upon people believing that SPF is actually useful... Graeme From jnegro at billtrust.com Fri Dec 4 19:21:07 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 4 Dec 2009 14:21:07 -0500 Subject: SPF Configurations In-Reply-To: <1259953135.30483.4.camel@ernie.internal.graemef.net> References: <09120408252597_5AC@oregon.uoregon.edu><3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <1259953135.30483.4.camel@ernie.internal.graemef.net> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B904292A6B@LOGAN.billtrust.local> >From talking to a few people so far it seems like it might be better to have the development team here alter our applications to use a separate Envelope From and friendly From. I can display the email address with the customers domain, but the mail will be coming from our address as the Envelope From. That way the customer is happy their end user is seeing the email coming from their domain, while the Envelope From shows an email address that matches our domain. Seems like a simpler solution. Thank you all for your input, as I know this may be a bit off topic for this list. Jeffrey -----Original Message----- From: Graeme Fowler [mailto:graeme at graemef.net] Sent: Friday, December 04, 2009 1:59 PM To: NANOG Subject: RE: SPF Configurations On Fri, 2009-12-04 at 11:45 -0500, Jeffrey Negro wrote: > Thanks for your input on this. My main concern is mail filters at the > end users side thinking that our mail servers are spoofing our > customer's domain. If you really feel that SPF is going to help, then keep all the mail in your domain's control by using VERP addresses as the envelope sender address (like most decent modern MLM packages do). That way you can have a "From: " header in the customer domain (or of your choosing), and the envelope sender in your own. The benefit here is that not only does it make the usage of SPF a lot less complex, but it also means that all bounces come back to the originating system and can be handled accordingly. Have a look at the headers of this message for a well-formed example. Of course, this does depend upon people believing that SPF is actually useful... Graeme From jmamodio at gmail.com Fri Dec 4 19:44:12 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 4 Dec 2009 13:44:12 -0600 Subject: news from Google In-Reply-To: <015d01ca7513$0b483370$21d89a50$@net> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> <015d01ca7513$0b483370$21d89a50$@net> Message-ID: <202705b0912041144r4414063bj9293f9e4f7388c2d@mail.gmail.com> Put one more down on the evil list ... http://www.techcrunch.com/2009/12/04/google-acquires-appjet-etherpad/ Cheers Jorge From cordmacleod at gmail.com Fri Dec 4 19:53:00 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Fri, 4 Dec 2009 11:53:00 -0800 Subject: news from Google In-Reply-To: <202705b0912041144r4414063bj9293f9e4f7388c2d@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> <015d01ca7513$0b483370$21d89a50$@net> <202705b0912041144r4414063bj9293f9e4f7388c2d@mail.gmail.com> Message-ID: <5801EB1B-2961-453D-8B7E-18201D111A77@gmail.com> On Dec 4, 2009, at 11:44 AM, Jorge Amodio wrote: > Put one more down on the evil list ... > > http://www.techcrunch.com/2009/12/04/google-acquires-appjet-etherpad/ > > Cheers > Jorge Come on. Acquiring a company is now considered evil? Of course there are repercussions to any acquisition. Many companies however have been acquired by Google and are not evil at all. Many companies retain their independence after being acquired. I have enjoyed Google's services for years and never once considered them evil. Everyone should enjoy the fruits of their labor and the services they provide. From plonka at doit.wisc.edu Fri Dec 4 19:56:41 2009 From: plonka at doit.wisc.edu (Dave Plonka) Date: Fri, 04 Dec 2009 13:56:41 -0600 Subject: IP address as a service identifier can be harmful (was "Re: news from Google") In-Reply-To: <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: <20091204195641.GB4207@doit.wisc.edu> Hmm, all these resolution services being advertised Internet-wide by their [temporary?] IP addresses... it is an interesting variation of we put some work into best practice considerations along these lines a few years ago: Embedding Globally-Routable Internet Addresses Considered Harmful BCP 105, RFC 4085: http://www.rfc-editor.org/rfc/bcp/bcp105.txt So, a polite reminder: (while I am well aware that host needs to identify an initial DNS server by IP address, to bootstrap the process) there is a documented history of bad things having happened when publicly-advertised, "popular" Internet services were identified by unique, globally-routable IP addresses without the use of some other rendezvous mechanism (DNS, DHCP, etc.). The addresses, and thus the prefixes in which they reside, become encumbered by their past uses, thus diminishing the ability to reuse those address blocks and raising the unfortunate consideration to legitimately block or hijack those IP addresses to deal with unexpected traffic load or security issues. When the address for one's recursive DNS server is, instead, gotten from a local DHCP server (or by local policy) then there is at least the possibility, by responsible operators, to limit unwanted traffic destined for those addresses in [inevitable] future. Dave On Fri, Dec 04, 2009 at 10:25:11AM -0800, Christopher Morrow wrote: > On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett wrote: > > > ? Google will be all sweetness and light until they've crushed OpenDNS, > > ? and when the competitor's out of the picture, they'll get down to the > > ? monetizing. > > one note: OpenDNS is not the only 'competitor' here.... just one of > the better obviously known ones. > > ie: > 4.2.2.2 L(3) > 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU > Neustar (can't recall ips, sorry) > > -chris > -- plonka at cs.wisc.edu http://net.doit.wisc.edu/~plonka/ Madison, WI From martin at theicelandguy.com Fri Dec 4 20:34:10 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 4 Dec 2009 15:34:10 -0500 Subject: news from Google In-Reply-To: <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: On Fri, Dec 4, 2009 at 1:25 PM, Christopher Morrow wrote: > On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett > wrote: > > > Google will be all sweetness and light until they've crushed OpenDNS, > > and when the competitor's out of the picture, they'll get down to the > > monetizing. > > one note: OpenDNS is not the only 'competitor' here.... just one of > the better obviously known ones. > > ie: > 4.2.2.2 L(3) > 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU > Neustar (can't recall ips, sorry) > > -chris > > Why did Google put an infrastructure critical application into PA space? -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From cscora at apnic.net Fri Dec 4 20:34:27 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Dec 2009 06:34:27 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200912042034.nB4KYR9L014147@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Dec, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 305390 Prefixes after maximum aggregation: 142337 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 150539 Total ASes present in the Internet Routing Table: 32849 Prefixes per ASN: 9.30 Origin-only ASes present in the Internet Routing Table: 28510 Origin ASes announcing only one prefix: 13915 Transit ASes present in the Internet Routing Table: 4339 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 1081 Unregistered ASNs in the Routing Table: 172 Number of 32-bit ASNs allocated by the RIRs: 342 Prefixes from 32-bit ASNs in the Routing Table: 281 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 174 Number of addresses announced to Internet: 2139389760 Equivalent to 127 /8s, 132 /16s and 127 /24s Percentage of available address space announced: 57.7 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.2 Total number of prefixes smaller than registry allocations: 146684 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72874 Total APNIC prefixes after maximum aggregation: 25430 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 69560 Unique aggregates announced from the APNIC address blocks: 30973 APNIC Region origin ASes present in the Internet Routing Table: 3883 APNIC Prefixes per ASN: 17.91 APNIC Region origin ASes announcing only one prefix: 1057 APNIC Region transit ASes present in the Internet Routing Table: 601 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 483411744 Equivalent to 28 /8s, 208 /16s and 71 /24s Percentage of available APNIC address space announced: 80.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 128363 Total ARIN prefixes after maximum aggregation: 67377 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 102877 Unique aggregates announced from the ARIN address blocks: 38831 ARIN Region origin ASes present in the Internet Routing Table: 13385 ARIN Prefixes per ASN: 7.69 ARIN Region origin ASes announcing only one prefix: 5182 ARIN Region transit ASes present in the Internet Routing Table: 1326 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 731875872 Equivalent to 43 /8s, 159 /16s and 138 /24s Percentage of available ARIN address space announced: 64.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70631 Total RIPE prefixes after maximum aggregation: 41162 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 63769 Unique aggregates announced from the RIPE address blocks: 42546 RIPE Region origin ASes present in the Internet Routing Table: 13833 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7185 RIPE Region transit ASes present in the Internet Routing Table: 2094 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 405643136 Equivalent to 24 /8s, 45 /16s and 159 /24s Percentage of available RIPE address space announced: 75.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26702 Total LACNIC prefixes after maximum aggregation: 6480 LACNIC Deaggregation factor: 4.12 Prefixes being announced from the LACNIC address blocks: 25010 Unique aggregates announced from the LACNIC address blocks: 13646 LACNIC Region origin ASes present in the Internet Routing Table: 1219 LACNIC Prefixes per ASN: 20.52 LACNIC Region origin ASes announcing only one prefix: 397 LACNIC Region transit ASes present in the Internet Routing Table: 203 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 68833280 Equivalent to 4 /8s, 26 /16s and 80 /24s Percentage of available LACNIC address space announced: 68.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5972 Total AfriNIC prefixes after maximum aggregation: 1567 AfriNIC Deaggregation factor: 3.81 Prefixes being announced from the AfriNIC address blocks: 4371 Unique aggregates announced from the AfriNIC address blocks: 1513 AfriNIC Region origin ASes present in the Internet Routing Table: 336 AfriNIC Prefixes per ASN: 13.01 AfriNIC Region origin ASes announcing only one prefix: 94 AfriNIC Region transit ASes present in the Internet Routing Table: 70 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 13172992 Equivalent to 0 /8s, 201 /16s and 1 /24s Percentage of available AfriNIC address space announced: 39.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1750 7507 461 Korea Telecom (KIX) 17488 1458 143 132 Hathway IP Over Cable Interne 4755 1280 296 148 TATA Communications formerly 9583 1044 79 514 Sify Limited 4134 1015 19459 395 CHINANET-BACKBONE 18101 984 204 34 Reliance Infocom Ltd Internet 7545 918 198 97 TPG Internet Pty Ltd 17974 864 270 57 PT TELEKOMUNIKASI INDONESIA 9829 850 673 24 BSNL National Internet Backbo 24560 806 293 176 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4235 3879 311 bellsouth.net, inc. 4323 3756 1068 399 Time Warner Telecom 1785 1779 715 136 PaeTec Communications, Inc. 7018 1590 5809 1032 AT&T WorldNet Services 20115 1526 1484 667 Charter Communications 2386 1292 632 933 AT&T Data Communications Serv 3356 1219 10966 439 Level 3 Communications, LLC 6478 1179 255 334 AT&T Worldnet Services 11492 1145 222 14 Cable One 22773 1125 2600 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 516 98 207 Evolva Telecom 35805 475 40 5 United Telecom of Georgia 9198 471 138 12 Kazakhtelecom Data Network Ad 3292 449 1906 394 TDC Tele Danmark 702 416 1837 334 UUNET - Commercial IP service 8551 377 354 41 Bezeq International 8866 375 110 23 Bulgarian Telecommunication C 3320 359 7068 305 Deutsche Telekom AG 3215 349 3144 111 France Telecom Transpac 3301 347 1411 303 TeliaNet Sweden Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1588 2899 231 UniNet S.A. de C.V. 10620 999 223 145 TVCABLE BOGOTA 28573 818 668 84 NET Servicos de Comunicao S.A 7303 665 351 96 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 474 308 59 Instituto Costarricense de El 11172 446 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 431 858 29 Telecomunicacoes da Bahia S.A 3816 425 193 71 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1026 188 7 TEDATA 24863 756 128 63 LINKdotNET AS number 3741 273 857 233 The Internet Solution 2018 176 195 102 Tertiary Education Network 6713 175 167 12 Itissalat Al-MAGHRIB 29571 150 15 8 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 124 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4235 3879 311 bellsouth.net, inc. 4323 3756 1068 399 Time Warner Telecom 1785 1779 715 136 PaeTec Communications, Inc. 4766 1750 7507 461 Korea Telecom (KIX) 7018 1590 5809 1032 AT&T WorldNet Services 8151 1588 2899 231 UniNet S.A. de C.V. 20115 1526 1484 667 Charter Communications 17488 1458 143 132 Hathway IP Over Cable Interne 2386 1292 632 933 AT&T Data Communications Serv 4755 1280 296 148 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3756 3357 Time Warner Telecom 1785 1779 1643 PaeTec Communications, Inc. 8151 1588 1357 UniNet S.A. de C.V. 17488 1458 1326 Hathway IP Over Cable Interne 4766 1750 1289 Korea Telecom (KIX) 4755 1280 1132 TATA Communications formerly 11492 1145 1131 Cable One 22773 1125 1059 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1026 1019 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:65 /12:177 /13:353 /14:644 /15:1224 /16:10779 /17:5006 /18:8561 /19:17650 /20:21503 /21:21436 /22:27640 /23:27536 /24:159858 /25:930 /26:1135 /27:577 /28:234 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2772 4235 bellsouth.net, inc. 4323 2369 3756 Time Warner Telecom 4766 1430 1750 Korea Telecom (KIX) 1785 1244 1779 PaeTec Communications, Inc. 17488 1224 1458 Hathway IP Over Cable Interne 11492 1067 1145 Cable One 18566 1040 1059 Covad Communications 7018 955 1590 AT&T WorldNet Services 8452 924 1026 TEDATA 10620 905 999 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 2:1 4:13 8:234 12:2057 13:8 15:22 16:3 17:5 20:37 24:1282 32:49 34:2 38:625 40:98 41:1838 43:1 44:3 46:1 47:21 52:6 55:2 56:2 57:23 58:647 59:612 60:445 61:974 62:960 63:2009 64:3750 65:2369 66:4099 67:1775 68:1018 69:2810 70:687 71:232 72:1889 73:2 74:2021 75:190 76:357 77:848 78:601 79:399 80:950 81:810 82:469 83:448 84:529 85:1014 86:380 87:681 88:445 89:1507 90:59 91:2644 92:441 93:1157 94:1348 95:832 96:201 97:278 98:429 99:27 109:179 110:278 111:480 112:152 113:190 114:287 115:391 116:1089 117:588 118:366 119:802 120:143 121:698 122:1304 123:797 124:1024 125:1346 128:212 129:200 130:134 131:460 132:82 133:16 134:180 135:40 136:230 137:167 138:239 139:82 140:458 141:122 142:380 143:341 144:393 145:52 146:390 147:171 148:565 149:191 150:148 151:171 152:220 153:161 154:2 155:269 156:167 157:317 158:97 159:359 160:294 161:174 162:279 163:162 164:314 165:472 166:491 167:392 168:754 169:159 170:560 171:42 172:1 173:385 174:424 180:209 183:160 184:1 186:234 187:174 188:1379 189:650 190:3363 192:5733 193:4309 194:3363 195:2779 196:1184 198:3574 199:3380 200:5241 201:1420 202:7924 203:8291 204:3981 205:2149 206:2411 207:3049 208:3967 209:3390 210:2548 211:1144 212:1632 213:1632 214:246 215:57 216:4422 217:1364 218:479 219:422 220:1138 221:448 222:301 End of report From bmanning at vacation.karoshi.com Fri Dec 4 21:37:22 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 4 Dec 2009 21:37:22 +0000 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: <20091204213722.GA10894@vacation.karoshi.com.> On Fri, Dec 04, 2009 at 03:34:10PM -0500, Martin Hannigan wrote: > On Fri, Dec 4, 2009 at 1:25 PM, Christopher Morrow > wrote: > > > On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett > > wrote: > > > > > Google will be all sweetness and light until they've crushed OpenDNS, > > > and when the competitor's out of the picture, they'll get down to the > > > monetizing. > > > > one note: OpenDNS is not the only 'competitor' here.... just one of > > the better obviously known ones. > > > > ie: > > 4.2.2.2 L(3) > > 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU > > Neustar (can't recall ips, sorry) > > > > -chris > > > > > > > Why did Google put an infrastructure critical application into PA space? > > whats PA space in this context? clearly 8.0.0.0/8 was allocated prior to any current group-think about what PA might be. --bill From cidr-report at potaroo.net Fri Dec 4 22:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Dec 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200912042200.nB4M01d7094525@wattle.apnic.net> BGP Update Report Interval: 26-Nov-09 -to- 03-Dec-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8151 20301 2.5% 41.4 -- Uninet S.A. de C.V. 2 - AS23700 13865 1.7% 27.3 -- BM-AS-ID PT. Broadband Multimedia, Tbk 3 - AS7643 13095 1.6% 97.7 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 4 - AS9800 11181 1.4% 81.0 -- UNICOM CHINA UNICOM 5 - AS30890 10047 1.2% 19.8 -- EVOLVA Evolva Telecom s.r.l. 6 - AS14420 10023 1.2% 30.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 7 - AS28477 9205 1.1% 1022.8 -- Universidad Autonoma del Esstado de Morelos 8 - AS14187 8753 1.1% 301.8 -- COMSAT COLOMBIA 9 - AS9829 8676 1.1% 18.2 -- BSNL-NIB National Internet Backbone 10 - AS23216 8432 1.0% 46.1 -- MEGADATOS S.A. 11 - AS35805 7942 1.0% 17.2 -- UTG-AS United Telecom AS 12 - AS9394 7415 0.9% 3.9 -- CRNET CHINA RAILWAY Internet(CRNET) 13 - AS33648 6513 0.8% 3256.5 -- ELEPHANT - ColoFlorida / Elephant Outlook 14 - AS6822 6494 0.8% 282.3 -- SUPERONLINE-AS SuperOnline autonomous system 15 - AS24342 6219 0.8% 144.6 -- BRAC-BDMAIL-AS-BD BRAC BDMail Network Ltd. 16 - AS5800 6071 0.8% 32.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS4249 6011 0.7% 34.7 -- LILLY-AS - Eli Lilly and Company 18 - AS17974 4891 0.6% 18.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS9583 4822 0.6% 6.1 -- SIFY-AS-IN Sify Limited 20 - AS7738 4660 0.6% 10.9 -- Telecomunicacoes da Bahia S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 4398 0.5% 4398.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS33648 6513 0.8% 3256.5 -- ELEPHANT - ColoFlorida / Elephant Outlook 3 - AS36239 3046 0.4% 3046.0 -- EXIGEN-CANADA - Exigen Canada 4 - AS5691 2390 0.3% 2390.0 -- MITRE-AS-5 - The MITRE Corporation 5 - AS27667 2239 0.3% 2239.0 -- Universidad Autonoma de la Laguna 6 - AS14251 1447 0.2% 1447.0 -- MLSLI - Multiple Lising Service of Long Island, Inc. 7 - AS39384 1205 0.1% 1205.0 -- GUILAN-UNIV-AS University of Guilan AS System 8 - AS41060 1078 0.1% 1078.0 -- PRIMBANK-AS Joint-Stock Commercial Bank Primorye 9 - AS47417 1069 0.1% 1069.0 -- CELTRAK-AS Celtrak AS Number 10 - AS28477 9205 1.1% 1022.8 -- Universidad Autonoma del Esstado de Morelos 11 - AS22917 1861 0.2% 930.5 -- INFOCHANNEL ASN-INFOCHAN 12 - AS48481 1850 0.2% 925.0 -- RYBALKA-AS ISP King-Online 13 - AS12732 2671 0.3% 890.3 -- bbTT GmbH 14 - AS37035 805 0.1% 805.0 -- MIC-AS 15 - AS17819 2892 0.4% 723.0 -- ASN-EQUINIX-AP Equinix Asia Pacific 16 - AS24323 2120 0.3% 530.0 -- GLOBAL-ONLINE-AS-AP aamra networks limited, 17 - AS17469 1507 0.2% 502.3 -- ACCESSTEL-AS-AP Access Telecom (BD) Ltd. 18 - AS26381 942 0.1% 471.0 -- HSBC-COM - hsbc.com 19 - AS41343 2543 0.3% 423.8 -- TRIUNFOTEL-ASN TRIUNFOTEL 20 - AS37786 843 0.1% 421.5 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 9141 1.0% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 66.192.106.0/23 6254 0.7% AS33648 -- ELEPHANT - ColoFlorida / Elephant Outlook 3 - 212.253.4.0/24 4951 0.6% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 4 - 91.212.23.0/24 4398 0.5% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 5 - 203.162.118.128/ 4184 0.5% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - 72.28.75.0/24 3046 0.3% AS36239 -- EXIGEN-CANADA - Exigen Canada 7 - 89.144.140.0/24 3006 0.3% AS39308 -- ASK-AS Andishe Sabz Khazar Autonomous System AS39384 -- GUILAN-UNIV-AS University of Guilan AS System 8 - 143.138.107.0/24 2699 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 9 - 222.255.186.0/25 2662 0.3% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 10 - 192.12.120.0/24 2390 0.3% AS5691 -- MITRE-AS-5 - The MITRE Corporation 11 - 148.245.181.0/24 2239 0.2% AS27667 -- Universidad Autonoma de la Laguna 14 - 212.42.236.0/24 2065 0.2% AS12732 -- bbTT GmbH 15 - 202.177.223.0/24 1459 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 16 - 65.223.235.0/24 1447 0.2% AS14251 -- MLSLI - Multiple Lising Service of Long Island, Inc. 17 - 202.167.247.0/24 1428 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 18 - 200.85.240.0/22 1253 0.1% AS14187 -- COMSAT COLOMBIA 19 - 200.85.244.0/22 1253 0.1% AS14187 -- COMSAT COLOMBIA 20 - 200.23.28.0/26 1252 0.1% AS8151 -- Uninet S.A. de C.V. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 4 22:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Dec 2009 22:00:01 GMT Subject: The Cidr Report Message-ID: <200912042200.nB4M01TB094519@wattle.apnic.net> This report has been generated at Fri Dec 4 21:11:26 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-11-09 309743 191782 28-11-09 309731 191730 29-11-09 309930 191931 30-11-09 310070 192022 01-12-09 309965 192378 02-12-09 310335 192495 03-12-09 310687 192616 04-12-09 310737 192817 AS Summary 33047 Number of ASes in routing system 14059 Number of ASes announcing only one prefix 4356 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92613824 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Dec09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 310897 192801 118096 38.0% All ASes AS6389 4235 318 3917 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4356 1941 2415 55.4% TWTC - tw telecom holdings, inc. AS1785 1783 321 1462 82.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1865 584 1281 68.7% KIXS-AS-KR Korea Telecom AS17488 1458 314 1144 78.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1125 71 1054 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1586 674 912 57.5% Uninet S.A. de C.V. AS4755 1280 402 878 68.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1044 236 808 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 957 282 675 70.5% TEDATA TEDATA AS18101 984 328 656 66.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1179 567 612 51.9% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1221 635 586 48.0% LEVEL3 Level 3 Communications AS24560 805 223 582 72.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS10620 1004 431 573 57.1% TV Cable S.A. AS4808 764 196 568 74.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 635 72 563 88.7% MPX-AS Microplex PTY LTD AS7303 665 103 562 84.5% Telecom Argentina S.A. AS4134 1015 455 560 55.2% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1588 1032 556 35.0% ATT-INTERNET4 - AT&T WorldNet Services AS18566 1059 510 549 51.8% COVAD - Covad Communications Co. AS11492 1145 634 511 44.6% CABLEONE - CABLE ONE, INC. AS22047 546 49 497 91.0% VTR BANDA ANCHA S.A. AS4780 627 147 480 76.6% SEEDNET Digital United Inc. AS9443 533 82 451 84.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 564 129 435 77.1% GIGAINFRA Softbank BB Corp. AS5668 786 362 424 53.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS855 614 191 423 68.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS28573 818 398 420 51.3% NET Servicos de Comunicao S.A. AS7011 1033 628 405 39.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 37274 12315 24959 67.0% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 109.198.0.0/19 AS41227 ARTCOMMUNICATION-AS Art Comunication DOO Beograd 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 195.200.252.0/23 AS25137 NFSI NFSi Telecom, Lda. 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jmamodio at gmail.com Fri Dec 4 22:03:16 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 4 Dec 2009 16:03:16 -0600 Subject: news from Google In-Reply-To: <5801EB1B-2961-453D-8B7E-18201D111A77@gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> <015d01ca7513$0b483370$21d89a50$@net> <202705b0912041144r4414063bj9293f9e4f7388c2d@mail.gmail.com> <5801EB1B-2961-453D-8B7E-18201D111A77@gmail.com> Message-ID: <202705b0912041403p320b5f52j847b0cadbc418e00@mail.gmail.com> > Come on. ?Acquiring a company is now considered evil? It's a sarcasm about the ones crying wolf about Google becoming "evil". From martin at theicelandguy.com Fri Dec 4 22:15:49 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 4 Dec 2009 17:15:49 -0500 Subject: news from Google In-Reply-To: <20091204213722.GA10894@vacation.karoshi.com.> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> <20091204213722.GA10894@vacation.karoshi.com.> Message-ID: On Fri, Dec 4, 2009 at 4:37 PM, wrote: > On Fri, Dec 04, 2009 at 03:34:10PM -0500, Martin Hannigan wrote: > > On Fri, Dec 4, 2009 at 1:25 PM, Christopher Morrow > > wrote: > > > > > On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett > > > wrote: > > > > > > > Google will be all sweetness and light until they've crushed > OpenDNS, > > > > and when the competitor's out of the picture, they'll get down to > the > > > > monetizing. > > > > > > one note: OpenDNS is not the only 'competitor' here.... just one of > > > the better obviously known ones. > > > > > > ie: > > > 4.2.2.2 L(3) > > > 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU > > > Neustar (can't recall ips, sorry) > > > > > > -chris > > > > > > > > > > > > Why did Google put an infrastructure critical application into PA space? > > > > > > whats PA space in this context? clearly 8.0.0.0/8 was allocated > prior to any current group-think about what PA might be. > > --bill > Let's call it "conceptual PA". I'm simply asking why something that has the potential to impact all of us is being numbered into address space other than their own? And before the thinkpol start in, I'm referring to the v4 addresses and their status. It's a fair question since it has major impact on the net. If the store for legacy v4 addresses is open I'd like to know what street it's on. Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From bc-list at beztech.net Fri Dec 4 22:31:43 2009 From: bc-list at beztech.net (Ben Carleton) Date: Fri, 4 Dec 2009 17:31:43 -0500 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> <20091204213722.GA10894@vacation.karoshi.com.> Message-ID: <4BFD2586-7360-4220-B518-BCBFB1F5D8D5@beztech.net> I don' think that google will be able to kill opendns right now. Neither google nor any of the other well known DNS services provide the "value-added services" that OpenDNS does, such as filtering, etc which can be a godsend for small businesses that can't afford a rackful of gear... BGC On Dec 4, 2009, at 5:15 PM, Martin Hannigan wrote: > On Fri, Dec 4, 2009 at 4:37 PM, wrote: > >> On Fri, Dec 04, 2009 at 03:34:10PM -0500, Martin Hannigan wrote: >>> On Fri, Dec 4, 2009 at 1:25 PM, Christopher Morrow >>> wrote: >>> >>>> On Fri, Dec 4, 2009 at 5:53 AM, Richard Bennett >>>> wrote: >>>> >>>>> Google will be all sweetness and light until they've crushed >> OpenDNS, >>>>> and when the competitor's out of the picture, they'll get down to >> the >>>>> monetizing. >>>> >>>> one note: OpenDNS is not the only 'competitor' here.... just one of >>>> the better obviously known ones. >>>> >>>> ie: >>>> 4.2.2.2 L(3) >>>> 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU >>>> Neustar (can't recall ips, sorry) >>>> >>>> -chris >>>> >>>> >>> >>> >>> Why did Google put an infrastructure critical application into PA space? >>> >>> >> >> whats PA space in this context? clearly 8.0.0.0/8 was allocated >> prior to any current group-think about what PA might be. >> >> --bill >> > > > Let's call it "conceptual PA". I'm simply asking why something that has the > potential to impact all of us is being numbered into address space other > than their own? > > And before the thinkpol start in, I'm referring to the v4 addresses and > their status. It's a fair question since it has major impact on the net. If > the store for legacy v4 addresses is open I'd like to know what street it's > on. > > Best, > > -M< > > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From andre.engel at fhe3.com Sat Dec 5 00:13:17 2009 From: andre.engel at fhe3.com (Andre Engel) Date: Sat, 5 Dec 2009 01:13:17 +0100 Subject: AW: SPF Configurations In-Reply-To: <20091204172504.30269.qmail@simone.iecc.com> References: <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <20091204172504.30269.qmail@simone.iecc.com> Message-ID: <001001ca753f$bee63db0$3cb2b910$@engel@fhe3.com> John , Nice to meet you :-) > Right. The only major mail system that pays attention to SPF is > Hotmail, but there are enough small poorly run MTAs that use it that > an SPF record which lists your outbounds and ~all (not -all) can be > marginally useful to avoid bogus rejections of your mail. For example : host -t TXT hotmail.com hotmail.com TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" host -t TXT google.com : google.com TXT "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all" host -t TXT amazon.com : amazon.com TXT "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22 ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all" amazon.com TXT "spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22 ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all" host -t TXT ebay.de : ebay.de TXT "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.ebay.com include:c._spf.ebay.com ~all" ebay.de TXT "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com include:p._sid.ebay.com include:c._sid.ebay.com ~all" host -t TXT 1und1.de : TXT "v=spf1 ip4:82.165.0.0/16 ip4:195.20.224.0/19 ip4:212.227.0.0/16 ip4:87.106.0.0/16 ip4:217.160.0.0/16 ip4:213.165.64.0/19 ip4:217.72.192.0/20 ip4:74.208.0.0/17 ip4:74.208.128.0/18 ip4:66.236.18.66 ip4:67.88.206.40 ip4:67.88.206.48 ~all" host -t TXT gmx.com : gmx.com TXT "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:74.208.122.0/26 -all" host -t TXT enterprisemail.de : enterprisemail.de TXT "v=spf1 a:mout.enterprisemail.de -all" etc > As everyone here should already know, the fundamental problem with SPF > is that although it does an OK job of describing the mail sending > patterns of dedicated bulk mail systems, it can't model the way that > normal mail systems with human users work. But so deep is the faith > of the SPF cult that they blame the world for not matching SPF rather > than the other way around, believing that it prevent forgery, having > redefined "forgery" as whatever it is that SPF prevents. As the > operator of one of the world's more heavily forged domains (abuse.net) > I can report that if you think it prevents forgery blowback, you are > mistaken. You do know that I love they way abuse.net flys: In mind of the following situation for instance a infection vector around millions of bots which are sending millions of forged mails within evil polymorphic files camouflage as your customers bills you will be glade to enforce the directive -all for a while . Sorry Im almost german : http://www.heise.de/security/meldung/1-1-warnt-Kunden-vor-gefaelschten-Rechn ungen-131420.html I know SPF is not the answer of all ....but sometimes it helps to secure a little bit of yours "critical customers infrastructure" and sometimes it helps to save your operative resources . I know there is a problem so far with forwarded emails but there is also a solution : The solution could be to rewrite the envelope from of all forwarded mail so that the given domain is a local domain with matching SPF records to the originating mail server (or no SPF records at all). You have to transform the original envelope from into a localpart and add some special local SRS domain to it. Find http://spf.pobox.com/srs.html and http://www.libsrs2.org/ for a full description of SRS. In practice andre.engel at fhe3.com could receiving an email from misterX at google.com where andre.engel at fhe3.com could be forwarded to andre.engel at hotmail.de. Before forwarding the email to the hotmail server I could rewrite the envelope-from from misterX at google.com to google.com=misterX at srs.enterprisemail.de srs.enterprisemail.de could be a valid domain for mails originating from our main mail clusters(enterprisemail) so possible SPF checks at hotmail would not bother. In case a bounce is generated at hotmail it could be delivered back to the SRS address, thus to our enterprisemail main mail cluster, where we would recognise the SRS scheme and "un-rewrite" it back to misterX at google.com and deliver the mail onward to the misterX at google.com mail system. But in the real world the rewriting isn't that simple as stated in the previous section. In fact you have to add some kind of checksum where the original mail address is mangled with a secret password, and a time stamp that makes the SRS address valid for some period of time. The mail address from above could look more like this: Every time a mail arrives that is an SRS address the password and timestamp could be checked, and faked or outdated recipients could be rejected. If you asked around drawbacks your right : SRS generates very long localparts. Mail servers should according to the RFC accept local parts with at least 63 characters. Most mail servers accept longer local parts, but unfortunately some won't. For those rare cases it is possible to configure a list of mail servers for which SRS won't be accomplished. > For rants about how badly the world and/or SPF stink, followups to > Spam-L. For proposals about other anti-spam magic bullets, followups > to ASRG. Indeed Spam-L is the best place to talk about anti-spam . Indeed CII is the best place to talk about critical infrastructures ,indeed nanog is the best place to talk about networkstuff but we are mostly operators looking for a valuable , comfortable solution to protect and share information . I do not really know if this will be a little off topic . Cheers Andre -- Andre Engel Consulting Program Director, Email and Cyber Intelligence Services "..ehy my friend we seek the Grail!" FHE3 GmbH P: +49 721 869 5907 Scheffelstr. 17a M: +49 160 962 44476 76135 Karlsruhe andre.engel at fhe3.com http://www.fhe3.com/ Amtsgericht Mannheim, HRB 702495 Umsatzsteuer-Ident: DE254677931 Gesch?ftsf?hrer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt This message (including any attachments) is the property of FHE3 and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. > -----Urspr?ngliche Nachricht----- > Von: John Levine [mailto:johnl at iecc.com] > Gesendet: Freitag, 4. Dezember 2009 18:25 > An: nanog at nanog.org > Betreff: Re: SPF Configurations > > >> If the customer insist on using their domain, then you would have to > have > >> the customer setup an SPF record within their domain that points to > your > >> email server IP blocks. > > Right. The only major mail system that pays attention to SPF is > Hotmail, but there are enough small poorly run MTAs that use it that > an SPF record which lists your outbounds and ~all (not -all) can be > marginally useful to avoid bogus rejections of your mail. > As everyone here should already know, the fundamental problem with SPF > is that although it does an OK job of describing the mail sending > patterns of dedicated bulk mail systems, it can't model the way that > normal mail systems with human users work. But so deep is the faith > of the SPF cult that they blame the world for not matching SPF rather > than the other way around, believing that it prevent forgery, having > redefined "forgery" as whatever it is that SPF prevents. As the > operator of one of the world's more heavily forged domains (abuse.net) > I can report that if you think it prevents forgery blowback, you are > mistaken. > For rants about how badly the world and/or SPF stink, followups to > Spam-L. For proposals about other anti-spam magic bullets, followups > to ASRG. > > R's, > John > > From ops.lists at gmail.com Sat Dec 5 01:33:15 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 5 Dec 2009 07:03:15 +0530 Subject: SPF Configurations In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B9042929E8@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B9042929E8@LOGAN.billtrust.local> Message-ID: On Fri, Dec 4, 2009 at 9:55 PM, Jeffrey Negro wrote: > I'm wondering if a few DNS experts out there could give me some input on > SPF record configuration. ?Our company sends out about 50k - 100k emails > a day, and most emails are on behalf of customers to their end users at SPF records aren't going ot help as much as some list sending and deliverability best practices (feedback loops etc) are. Look at the MAAWG senders best practices document - www.maawg.org -> Published Documents Other than delivery to hotmail, spf is a total waste of time - plus it plays russian roulette with whatever email you handle From johnl at iecc.com Sat Dec 5 00:54:11 2009 From: johnl at iecc.com (John R. Levine) Date: 4 Dec 2009 19:54:11 -0500 Subject: AW: SPF Configurations In-Reply-To: <001001ca753f$bee63db0$3cb2b910$@engel@fhe3.com> References: <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <20091204172504.30269.qmail@simone.iecc.com> <001001ca753f$bee63db0$3cb2b910$@engel@fhe3.com> Message-ID: >> Right. The only major mail system that pays attention to SPF is >> Hotmail, but there are enough small poorly run MTAs that use it that >> an SPF record which lists your outbounds and ~all (not -all) can be >> marginally useful to avoid bogus rejections of your mail. > > For example : > [ various large ISPs that publish SPF ] Perhaps this is a language problem. In English, "publishes" is not a synonym for "pays attention to." As I said, you need to publish SPF to get mail into Hotmail. That's why people do it. > I know there is a problem so far with forwarded emails but there is also a > solution : > [ hoary SRS proposal to change every SMTP server in the world to make them > match what SPF does ] Sigh. > Every time a mail arrives that is an SRS address the password and timestamp > could be checked, and faked or outdated recipients could be rejected. You might want to look at BATV, which has nothing to do with SPF, but I have found is quite useful for recognizing spam blowback. R's, John PS: > This message (including any attachments) is the property of FHE3 and may > contain confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. Our policy is to send messages with confidentiality notices to all of your competitors. From lars.eggert at nokia.com Sat Dec 5 02:58:20 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Fri, 4 Dec 2009 16:58:20 -1000 Subject: SPF Configurations In-Reply-To: <20091204172504.30269.qmail@simone.iecc.com> References: <20091204172504.30269.qmail@simone.iecc.com> Message-ID: On 2009-12-4, at 7:25, John Levine wrote: > The only major mail system that pays attention to SPF is > Hotmail FWIW, GMX (pretty popular in Europe) does too. Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2490 bytes Desc: not available URL: From dhc2 at dcrocker.net Sat Dec 5 05:11:31 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 04 Dec 2009 21:11:31 -0800 Subject: SPF Configurations In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B9042929E8@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B9042929E8@LOGAN.billtrust.local> Message-ID: <4B19EB83.6060301@dcrocker.net> Jeffrey Negro wrote: > SPF seems to be the way we could possibly > avoid more spam filters, and delivery rate is very important to our > company. You've seen the anti-SPF rants. At the least, they should make clear to you that you should use SPF only and exactly for specific destinations that you already know require it. If you have any doubts about the requirement, you'll try to verify it; otherwise assume SPF won't solve your problems. The other obvious mechanisms for validated identification to receiving operators is, of course, with DKIM. DKIM is entirely comfortable having a validated identifier (the d= parameter in the signature header field) be different than whatever is in the author header field (From:) But either way, that's just identification. As already noted on the thread, what matters most is the set of content and operations practices, to establish a rock solid reputation both of you and of your clients. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chaz at chaz6.com Sat Dec 5 13:21:24 2009 From: chaz at chaz6.com (Chris Hills) Date: Sat, 05 Dec 2009 14:21:24 +0100 Subject: news from Google In-Reply-To: <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: On 04/12/09 19:25, Christopher Morrow wrote: > one note: OpenDNS is not the only 'competitor' here.... just one of > the better obviously known ones. > > ie: > 4.2.2.2 L(3) > 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU > Neustar (can't recall ips, sorry) I maintain a list here [1], many of which are reachable with IPv6. [1] http://www.chaz6.com/files/resolv.conf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From andre.engel at fhe3.com Sat Dec 5 20:53:54 2009 From: andre.engel at fhe3.com (Andre Engel) Date: Sat, 5 Dec 2009 21:53:54 +0100 Subject: AW: AW: SPF Configurations In-Reply-To: References: <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <20091204172504.30269.qmail@simone.iecc.com> <001001ca753f$bee63db0$3cb2b910$@engel@fhe3.com> Message-ID: <001b01ca75ed$0f26a410$2d73ec30$@engel@fhe3.com> John, > -----Urspr?ngliche Nachricht----- > Von: John R. Levine [mailto:johnl at iecc.com] > Gesendet: Samstag, 5. Dezember 2009 01:54 > An: Andre Engel > Cc: nanog at nanog.org > Betreff: Re: AW: SPF Configurations > > >> Right. The only major mail system that pays attention to SPF is > >> Hotmail, but there are enough small poorly run MTAs that use it that > >> an SPF record which lists your outbounds and ~all (not -all) can be > >> marginally useful to avoid bogus rejections of your mail. > > > > For example : > > [ various large ISPs that publish SPF ] > > Perhaps this is a language problem. In English, "publishes" is not a > synonym for "pays attention to." As I said, you need to publish SPF > to get mail into Hotmail. That's why people do it. As I said im almost german :-) Some major providers ,1&1 for example, assigned their customers the "responsibility" to "pay attention on SPF" for getting mails into their boxes.(decision between suspicious or not) > > I know there is a problem so far with forwarded emails but there is > also a > > solution : > > [ hoary SRS proposal to change every SMTP server in the world to make > them > > match what SPF does ] > > Sigh. I do not want to change every SMTP servers in the world. I just gonna show an useful option .-) > > Every time a mail arrives that is an SRS address the password and > timestamp > > could be checked, and faked or outdated recipients could be rejected. > > You might want to look at BATV, which has nothing to do with SPF, but > I have found is quite useful for recognizing spam blowback. Sure ! For instance If your are providing an mail cluster for your customer bills, a newsletter server or a cooperated mail cluster and you know that you are sending emails only to receivers email boxes BATV is indeed a awesome tool. But if you are performing a shared mail cluster for your webhosting or your Dial in customers which are using for instance some special kinds of mailing lists maybe you need a additional solution. >From a reputation perspective Id like the idea to combine a set of anti spam tools if it is useful. Indeed MAAWG is not "the badest place" to learn about. > R's, > John > > PS: > > > This message (including any attachments) is the property of FHE3 and > may > > contain confidential or privileged information. Unauthorized use of > this > > communication is strictly prohibited and may be unlawful. If you have > > received this communication in error, please immediately notify the > sender > > by reply e-mail and destroy all copies of the communication and any > > attachments. > > Our policy is to send messages with confidentiality notices to all of > your competitors. Sure! Im here to learn *** .-) Cheers Andre -- Andre Engel Consulting Program Director, Email and Cyber Intelligence Services "..no space left on the device/Kein Weltraum links auf dem Ger?t" FHE3 GmbH P: +49 721 869 5907 Scheffelstr. 17a M: +49 160 962 44476 76135 Karlsruhe andre.engel at fhe3.com http://www.fhe3.com/ Amtsgericht Mannheim, HRB 702495 Umsatzsteuer-Ident: DE254677931 Gesch?ftsf?hrer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt *** This email is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE ,... From hrlinneweh at sbcglobal.net Sat Dec 5 21:07:34 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Sat, 5 Dec 2009 13:07:34 -0800 (PST) Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: <674692.5473.qm@web180303.mail.gq1.yahoo.com> I think this article best articulates what is going on with Google DNS http://www.pcmag.com/article2/0,2817,2356703,00.asp most people are not going to reconfigure their routers to use gdns as a secondary dns -henry ________________________________ From: Chris Hills To: nanog at nanog.org Sent: Sat, December 5, 2009 5:21:24 AM Subject: Re: news from Google On 04/12/09 19:25, Christopher Morrow wrote: > one note: OpenDNS is not the only 'competitor' here..... just one of > the better obviously known ones. > > ie: > 4.2.2.2? L(3) > 198.6.1.1/2/3/4/5/122/142/146/195 ex-UU > Neustar (can't recall ips, sorry) I maintain a list here [1], many of which are reachable with IPv6. [1] http://www.chaz6.com/files/resolv.conf From frogmanclay at gmail.com Sun Dec 6 01:42:20 2009 From: frogmanclay at gmail.com (frogmanclay at gmail.com) Date: Sun, 06 Dec 2009 01:42:20 +0000 Subject: ASA5580-20 with IOS software Message-ID: <0016e64b9a1ca1b822047a05730b@google.com> Does anyone have experience using an ASA5580-20 with IOS software? On top of that, using it as a headend for an Easy VPN solution? I am trying to figure out how many sites it can safely support, also are there any major problems with it? All of the documentation on Cisco's site only talks about using it with ASA software, but then it only supports Legacy Easy VPN and not Enhanced Easy VPN. In order to support Enhanced you have to run IOS. Thanks for your time, Clay From lukasz at bromirski.net Sun Dec 6 01:54:23 2009 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sun, 06 Dec 2009 02:54:23 +0100 Subject: ASA5580-20 with IOS software In-Reply-To: <0016e64b9a1ca1b822047a05730b@google.com> References: <0016e64b9a1ca1b822047a05730b@google.com> Message-ID: <4B1B0ECF.3020406@bromirski.net> On 2009-12-06 02:42, frogmanclay at gmail.com wrote: > Does anyone have experience using an ASA5580-20 with IOS software? On > top of that, using it as a headend for an Easy VPN solution? I am trying > to figure out how many sites it can safely support, also are there any > major problems with it? All of the documentation on Cisco's site only > talks about using it with ASA software, but then it only supports Legacy > Easy VPN and not Enhanced Easy VPN. In order to support Enhanced you > have to run IOS. ASA doesn't run IOS, it runs ASA OS/PIX OS, so there's no selection to choose from. Ask this question again on cisco-nsp@, this isn't a 'product/vendor selection list'. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From rusnginx at gmail.com Sun Dec 6 20:25:07 2009 From: rusnginx at gmail.com (Alex Aster) Date: Sun, 6 Dec 2009 21:25:07 +0100 Subject: Historical traceroute logging In-Reply-To: <4B18223E.4050805@justinshore.com> References: <4B18223E.4050805@justinshore.com> Message-ID: Hello Justin, I would like to recommend the web service http://www.wipmania.com/en/tools/for your needs. There are traceroutes and pings from multiple points around the world. The trace results also display the AS path, visual distance and the slow routers. Periodical checking will be available soon. At the moment, it can be made with own bash-script and permanent link to results. Regards, Alex 2009/12/3 Justin Shore > Does anyone know of any tools that can do repeated traceroutes over time to > a remote IP and log the results for later viewing/comparison? I'd like to > do a traceroute several times a day and store the details in CVS or > somewhere accessible down the road. Alerting to major path changes would be > nice but not critical. The ability to compare traceroute output down the > road would also be nice but also not critical. I'm more interested in the > path than the individual hops' RTTs. > > What's prompting this is a major change in RTTs for several hours yesterday > to an ITSP with a site in the south. We share a common upstream (L3) and > have in the past always transited that provider to get to each other. I > showed a route change for the specific /23 in question in my border routers' > RIBs. The adjacent /23 originating from the same ITSP but in a different > part of the country did not change (and neither did RTTs to the hosts we > monitor in that /23). The site claimed nothing changed on their end and > that they know of no changes upstream. BGP Play shows a route change from > Level3 to Internap during the time in question (thought the times don't line > up exactly) which most likely caused the more than double RTTs we were > seeing. My Cacti Advanced Ping graphs caught the problem in all its glory. > Nagios alerted me to the high RTT times as well. What I didn't get during > that period of time was a traceroute to the site in question. > > I'd like to run a traceroute several times a day and find some way to store > the output and work with it later if needed. I'd prefer OSS but commercial > apps would be considered too. I'm sure I'm not the first to have a need to > check traceroutes like that. How do the rest of you handle it? > > Thanks > Justin > From sean at donelan.com Sun Dec 6 22:56:05 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 6 Dec 2009 17:56:05 -0500 (EST) Subject: SPF Configurations In-Reply-To: <20091204172504.30269.qmail@simone.iecc.com> References: <20091204172504.30269.qmail@simone.iecc.com> Message-ID: <200912061643380.32BF5B92.1040@clifden.donelan.com> On Fri, 4 Dec 2009, John Levine wrote: > than the other way around, believing that it prevent forgery, having > redefined "forgery" as whatever it is that SPF prevents. As the > operator of one of the world's more heavily forged domains (abuse.net) > I can report that if you think it prevents forgery blowback, you are > mistaken. Nothing can "prevent" forgery. The forgers are going to keep making them. You can only try to make forgery easier to detect. But you need other parties' cooperation to detect the forgery and react in some way. Even if you did stop one forger, i.e. prison; there will be plenty of up and coming forgers to keep making forgeries. SPF, DKIM, PGP, S/MIME, DNSSEC, BCP38, sBGP, DRM, special paper and printing, wax seals, handwriting analysis, and so on; help cooperating parties detect particular types of forgery. Assuming the cooperating parties actually want to. Adding even more complexity probably isn't going to improve the degree of cooperation of uncooperative parties. In practice, any security control will also affect something some "legitimate" party wants to do sometime. And likewise, any security control can be mis-implemented or mis-used. In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Are they better implemented and checked by the application/user instead? Just as many people seem to get mad at ISPs when they do something, as get mad at ISPs when they don't do something. And its often the same something. From ops.lists at gmail.com Sun Dec 6 23:42:09 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 7 Dec 2009 05:12:09 +0530 Subject: Remote hands requested near sherman oaks LA [urgent] Message-ID: Sorry for the noise .. Got me a (personal) box that has a borked grub after an OS upgrade. Need to get somebody there who can just go in, probably fix /boot/grub/menu.lst to say the right thing, run grub (maybe boot in with a live cd, mount and run grub.. you know the drill) Is anybody in or near Sherman Oaks LA who can help fix this? Please email ASAP, I'll hook you up with the person who can get you access. Sorry for the urgent - that box has been down for over 24 hrs now. gave up waiting for root device common problem: boot args (cat/proc/cmdline) check root delay = (did the system wait long enough?) check root = (did the system wait for the right device?0 missing modules (cat/pro/modules;ls/dev) alert! /dev/disk/by-uuid/42b8599e-f7bc-4626-ad08-4ba6427513d1 does not exist. dropping to a shell busybox v1.13.3(ubuntu 1:1.13.3-1ubuntu7 built in shell (ash) enter 'help' for a list of commands (initramfs): -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Sun Dec 6 23:54:00 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 7 Dec 2009 05:24:00 +0530 Subject: Sherman Oaks CA - Re: Remote hands requested near sherman oaks LA [urgent] Message-ID: Too damn early (5:23 AM) .. the box is at Sherman Oaks CA - near Los Angeles LA. Sigh. >> ------Original Message------ >> From: Suresh Ramasubramanian >> To: nanog at nanog.org >> Subject: Remote hands requested near sherman oaks LA [urgent] >> Sent: Dec 6, 2009 15:42 >> >> Sorry for the noise .. ?Got me a (personal) box that has a borked grub >> after an OS upgrade. From ops.lists at gmail.com Mon Dec 7 00:44:49 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 7 Dec 2009 06:14:49 +0530 Subject: Remote hands requested near sherman oaks LA [urgent] In-Reply-To: References: Message-ID: Remote hand found. Thank you. From danny at tcb.net Mon Dec 7 01:30:53 2009 From: danny at tcb.net (Danny McPherson) Date: Sun, 6 Dec 2009 18:30:53 -0700 Subject: news from Google In-Reply-To: <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> Message-ID: I think one of the things that concerns me most with Google validating and jumping on the DNS "open resolver" bandwagon is that it'll force more folks (ISPs, enterprises and end users alike) to leave DNS resolver IP access wide open. Malware already commonly changes DNS resolver settings to rogue resolvers, and removes otherwise resident malcode from the end system to avoid detection by AV and the like. One of the primary recommendations I give to enterprises is to force use of internal resolvers, and log all other attempted DNS resolution queries elsewhere, it's a quick way to detect some compromised systems. My personal recommendation is that ISPs do the same, but that's where network neutrality issues enter the picture. Of course, some of the DNS NXDOMAIN and similar "synthesis" they've been performing may perturb some users, and hence Google's service (and _many before) are presumably welcomed by casual (or expert) end users. So, DNSSEC deployment finally gets close (with validation models mostly just to the resolver) -- primarily to deal with DNS data integrity issues in the infrastructure - yet compromised end systems are simply configured to use rogue resolvers, obviating much of the benefit of the added complexity DNSSEC brings, with "dumb pipe" providers simply enabling the now nefarious transactions.. And this concern is entirely orthogonal of all the issues that arise once Google (and everyone else) decide that _overriding application-level DNS settings (e.g., for Chrome) are perfectly reasonable -- not to mention the value they find in operation of DNS infrastructure from a data mining (e.g., NXDOMAIN data == marketing intelligence/$$) that many other folks have long ago realized... -danny From fergdawgster at gmail.com Mon Dec 7 01:37:24 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 6 Dec 2009 17:37:24 -0800 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> Message-ID: <6cd462c00912061737p315a9666sd2adce4d2cea3e55@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Dec 6, 2009 at 5:30 PM, Danny McPherson wrote: > > I think one of the things that concerns me most with Google > validating and jumping on the DNS "open resolver" bandwagon > is that it'll force more folks (ISPs, enterprises and end > users alike) to leave DNS resolver IP access wide open. > Malware already commonly changes DNS resolver settings to > rogue resolvers, and removes otherwise resident malcode from > the end system to avoid detection by AV and the like. > > One of the primary recommendations I give to enterprises is to > force use of internal resolvers, and log all other attempted > DNS resolution queries elsewhere, it's a quick way to detect > some compromised systems. [...] Indeed -- as this is exactly what we have seen, as discussed in the good white paper by Antoine Schonewille and Dirk-Jan van Helmond in 2006 (I've used this paper as a a reference many times), "The Domain Name Service as an IDS: How DNS can be used for detecting and monitoring badware in a network": http://staff.science.uva.nl/~delaat/snb-2005-2006/p12/report.pdf - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLHFxJq1pz9mNUZTMRAti9AKDYQalIoQ5aHDjsRzU9bz6ulxVLUwCePYbW v3KSVdE37Uyz/GXhC0dhaA0= =K0HW -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jmamodio at gmail.com Mon Dec 7 02:32:05 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 6 Dec 2009 20:32:05 -0600 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> <63ac96a50912031236m2b1507ecv5fa78a625d6952ce@mail.gmail.com> Message-ID: <202705b0912061832r203b02f0l3fd53906ccc70acf@mail.gmail.com> > enter the picture. ?Of course, some of the DNS NXDOMAIN and > similar "synthesis" they've been performing may perturb some > users, and hence Google's service (and _many before) are > presumably welcomed by casual (or expert) end users. What really concerns me is that some ISPs these days are assuming that given that "best practices" are not mandatory, creating "bad habits" for some revenue gain it's OK. We all will be better if they stop using the DNS for what it is not and we focus investment and engineering talent to create new *real* services and improve existing ones. My .02 Jorge From nonobvious at gmail.com Mon Dec 7 06:25:54 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Sun, 6 Dec 2009 22:25:54 -0800 Subject: SPF Configurations In-Reply-To: <200912061643380.32BF5B92.1040@clifden.donelan.com> References: <20091204172504.30269.qmail@simone.iecc.com> <200912061643380.32BF5B92.1040@clifden.donelan.com> Message-ID: <18a5e7cb0912062225u153c73cfkf6a5667a45b2791@mail.gmail.com> On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan wrote: > In particular, what anti-forgery/security controls should network operators > implement and check; and what anti-forgery/security controls should network > operators not implement or check? Depends a bit on whether you're counting inbound-mail-service operators as network operators. As an end user who doesn't have an account at Bank of America, I'd be happy if bankofamerica.com used SPF records so my mail system could discard forged spam from them; that's much different than the kind of forgery prevention I want for my actual bank. (And obviously SPF isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut down some of the noise and leave the rest for Spamassassin.) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From sean at donelan.com Mon Dec 7 14:30:24 2009 From: sean at donelan.com (Sean Donelan) Date: Mon, 7 Dec 2009 09:30:24 -0500 (EST) Subject: SPF Configurations In-Reply-To: <18a5e7cb0912062225u153c73cfkf6a5667a45b2791@mail.gmail.com> References: <20091204172504.30269.qmail@simone.iecc.com> <200912061643380.32BF5B92.1040@clifden.donelan.com> <18a5e7cb0912062225u153c73cfkf6a5667a45b2791@mail.gmail.com> Message-ID: <200912070849050.32BF5B92.19722@clifden.donelan.com> On Sun, 6 Dec 2009, Bill Stewart wrote: > On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan wrote: >> In particular, what anti-forgery/security controls should network operators >> implement and check; and what anti-forgery/security controls should network >> operators not implement or check? > > Depends a bit on whether you're counting inbound-mail-service > operators as network operators. Because this is NANOG, I was scoping it to be just layer 0 to 4. Leaving the application and above layer discussions to other places. I would love to know how the marketplace wants to handle "Official Mail," but I'm not expecting useful answers here. > As an end user who doesn't have an account at Bank of America, I'd be > happy if bankofamerica.com used SPF records so my mail system could > discard forged spam from them; that's much different than the kind of > forgery prevention I want for my actual bank. (And obviously SPF > isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut > down some of the noise and leave the rest for Spamassassin.) Like most things, scaling is the only problem. Your Bank is different from My Bank, and His Bank and Her Bank, and so on. Throw in multiple middle-parties, i.e. the NSP, ISP, MSP, ESP, etc; and the problem becomes very difficult. And that's before adding the problem the real Your Bank (or their marketing partners, or their compromised PCs) may also send stuff you don't want. Network operations probably aren't going to solve those problems. And lots of other places like to discuss them. So instead, what things should network operators be expected to solve? If you can't trust routing, can you trust DNS? If you can't trust DNS, can you trust things using DNS? If you can't trust ???, can you trust ??? From christian.liendo at nytimes.com Mon Dec 7 16:33:36 2009 From: christian.liendo at nytimes.com (Liendo, Christian A) Date: Mon, 7 Dec 2009 11:33:36 -0500 Subject: Historical traceroute logging In-Reply-To: <4B18223E.4050805@justinshore.com> References: <4B18223E.4050805@justinshore.com> Message-ID: <8F3C42E97037844F89866854905FD675D7CC295058@NYHQ-MPW-CCR01V.ent.nytint.com> Smokeping has SmokeTrace http://oss.oetiker.ch/smokeping/ New in Version 2.4 (The SmokeTrace edition) SmokeTrace: An Ajax Traceroute tool. Try the demo. SmokeTrace is written in javascript, using the qooxdoo framework, which is responsible for all the cross browser glory. This may be what you are looking for. Christian Liendo New York Times Digital From rusnginx at gmail.com Mon Dec 7 16:43:03 2009 From: rusnginx at gmail.com (Alex Aster) Date: Mon, 7 Dec 2009 17:43:03 +0100 Subject: news from Google In-Reply-To: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> Message-ID: Google has got a lot of data centers around the world, but the DNS servers are located in some of these. There is the list of data centers with DNS servers: USA, Atlanta USA, Reston,VA USA, Seattle USA, California Brazil, Sao Paulo Taiwan, Taipei City Germany, Frankfurt/Main Netherlands, Groningen Ireland, Dublin United Kingdom, London (anywhere else?) Here you can check ping distance to 8.8.8.8 from the servers all over the world: http://www.wipmania.com/ping/cache/8.8.8.8/?c=f4335d8443172 Regards, Alex 2009/12/3 Eduardo A. Su?rez > Hi, > > now Google DNS, anything more? > > > http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html > > Eduardo.- > > From michael.holstein at csuohio.edu Mon Dec 7 17:51:16 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 07 Dec 2009 12:51:16 -0500 Subject: SPF Configurations In-Reply-To: <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> Message-ID: <4B1D4094.9020303@csuohio.edu> > The problem we face is that some people we work with can't do that Then explain that client-side (their users, to whom they send mail) are probably using Hotmail, et.al. and SPF will simply not allow "spoofing" which is what they want to do, unless they either : A) add the SPF record as previously mentioned. It's a TXT record under their root and isn't hard at all. B) permit you to use a subdomain (like "user at theircompanymail.yourdomain.com"). A variant of (B) would be to ask them if you can register "theircompanymail.[com|net|..]" and send from that with proper SPF records. Most people won't notice the difference. We run into this all the time (a .edu) where users decide they want to use Yahoo for their email (we let them do that) .. but then configure their @edu address as the FROM and wonder why nobody gets their email. (we have to constantly explain how "NO, we won't add Yahoo's mail servers to our SPF record") Personally, I think SPF is a major PITA operations-wise .. but if you've ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's one of the first things they ask .. "do you have a spfv1 record defined?". As an aside, allowing your customers to forward @yourdomain to @otherdomain .. is a good way to get your own MXs blacklisted (this happens to us about once a month, then the "free whatever" adds blast our @edu addresses and a third of them go off to Yahoo .. our spam filters catch most of it, but then they miss a batch, we always have problems because of the forwards.) Regards, Michael Holstein Cleveland State University From michael.holstein at csuohio.edu Mon Dec 7 17:59:21 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 07 Dec 2009 12:59:21 -0500 Subject: news from Google In-Reply-To: <4B1815DC.2030708@xyonet.com> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <4B1815DC.2030708@xyonet.com> Message-ID: <4B1D4279.8030307@csuohio.edu> >> >> now Google DNS, anything more? >> >> http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html > Probably in support of their various Android netbooks that are in the pipe. They'll likely come pre-configured to use GoogleDNS .. that way they won't (accidentally) loose ad/search revenue when a "helpful" ISP redirects NXDOMAIN responses. Will be interesting to see if ISPs respond to a large scale thing like this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 (albeit for other reasons). Therein lies the problem with some of the "net neturality" arguments .. there's a big difference between "doing it because it causes a problem for others", and "doing it because it robs me of revenue opportunities". Cheers, Michael Holstein Cleveland State University From dotis at mail-abuse.org Mon Dec 7 19:20:09 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 7 Dec 2009 11:20:09 -0800 Subject: SPF Configurations In-Reply-To: <4B1D4094.9020303@csuohio.edu> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <4B1D4094.9020303@csuohio.edu> Message-ID: <56DE994B-870E-48A8-AE29-C325A11E964D@mail-abuse.org> On Dec 7, 2009, at 9:51 AM, Michael Holstein wrote: > >> The problem we face is that some people we work with can't do that > > Then explain that client-side (their users, to whom they send mail) are probably using Hotmail, et.al. and SPF will simply not allow "spoofing" which is what they want to do, unless they either : > > A) add the SPF record as previously mentioned. It's a TXT record under their root and isn't hard at all. An authorization tied to a PRA or Mail From will not prevent spoofing, it just constrains the risks to those with access to a provider's service. A provider could insure a user controls the From email-address, but this would conflict with the IP path registration schemes. > B) permit you to use a subdomain (like "user at theircompanymail.yourdomain.com"). A provider can ensure any signed From email-address is controlled by its users by using ping-back email confirmations appended to user profiles. There is a proposal aimed at reducing DNS overhead and scalability issues associated with the all-inclusive IP address path registration scheme with its inability to cope with forwarded email: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 Use of this DKIM extension can safely accommodate a user's desire to authorize third-party signatures to protect acceptance of From headers within domains that differ from the DKIM signature. DKIM does not need to change. Once IPv6 and international TLDs come into the mix, having users "vote" (authorize) DKIM providers could better determine what new domains can be trusted, and help ensure users are allowed to utilize their own language and to seek assistance in obtaining acceptable IPv6 connectivity. -Doug From ops.lists at gmail.com Mon Dec 7 19:55:01 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Dec 2009 01:25:01 +0530 Subject: SPF Configurations In-Reply-To: <4B1D4094.9020303@csuohio.edu> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <4B1D4094.9020303@csuohio.edu> Message-ID: On Mon, Dec 7, 2009 at 11:21 PM, Michael Holstein wrote: > > Personally, I think SPF is a major PITA operations-wise .. but if you've > ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's > one of the first things they ask .. "do you have a spfv1 record defined?". With yahoo and aol - they'd be just as satisfied if you used, say, DKIM. Hotmail's the only one that insists on sender-id (not spfv1 either) As for a university smarthost getting blocked you'd probably need to look at one of two things - 1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN If you took steps to fix some of these - 1. Isolate your forwarding through a separate IP or subnet, filter it before forwarding on 2. Separate your outbound to another set of IPs, again filter and a few other things - related to this .. you'd get blocked far less. Joe St.Sauver of UOregon, being a maawg senior tech advisor and also active in EDUCAUSE etc, might have a white paper on this, like he does on most other security related issues under the sun :) -- Suresh Ramasubramanian (ops.lists at gmail.com) From johnl at iecc.com Mon Dec 7 22:26:27 2009 From: johnl at iecc.com (John Levine) Date: 7 Dec 2009 22:26:27 -0000 Subject: Official Mail, was SPF Configurations In-Reply-To: <200912070849050.32BF5B92.19722@clifden.donelan.com> Message-ID: <20091207222627.10032.qmail@simone.iecc.com> >I would love to know how the marketplace wants to handle "Official Mail," >but I'm not expecting useful answers here. The marketplace doesn't have a clue. We have a plenty of tools in the toolbox, from heavyweight S/MIME to lighter weight DKIM+VBR to proprietary Goodmail, but among the mailers with a stake in having a reliable spoof-resistant channel I don't see much interest in doing anything other than whatever they're doing now. If it were up to me, I'd use per-recipient password-protected RSS or Atom feeds with emailed notices that just say to check your feed, but that has patent issues. R's, John From johnl at iecc.com Mon Dec 7 22:29:12 2009 From: johnl at iecc.com (John Levine) Date: 7 Dec 2009 22:29:12 -0000 Subject: random DNS, was news from Google In-Reply-To: <4B1D4279.8030307@csuohio.edu> Message-ID: <20091207222912.10709.qmail@simone.iecc.com> >Will be interesting to see if ISPs respond to a large scale thing like >this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >(albeit for other reasons). Therein lies the problem with some of the >"net neturality" arguments .. there's a big difference between "doing it >because it causes a problem for others", and "doing it because it robs >me of revenue opportunities". I do hear of ISPs blocking requests to random offsite DNS servers. For most consumer PCs, that's more likely to be a zombie doing DNS hijacking than anything legitimate. If they happen also to block 8.8.8.8 that's just an incidental side benefit. R's, John From jared at puck.nether.net Mon Dec 7 23:00:40 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Dec 2009 18:00:40 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <20091207222912.10709.qmail@simone.iecc.com> References: <20091207222912.10709.qmail@simone.iecc.com> Message-ID: <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> On Dec 7, 2009, at 5:29 PM, John Levine wrote: >> Will be interesting to see if ISPs respond to a large scale thing like >> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >> (albeit for other reasons). Therein lies the problem with some of the >> "net neturality" arguments .. there's a big difference between "doing it >> because it causes a problem for others", and "doing it because it robs >> me of revenue opportunities". > > I do hear of ISPs blocking requests to random offsite DNS servers. > For most consumer PCs, that's more likely to be a zombie doing DNS > hijacking than anything legitimate. If they happen also to block > 8.8.8.8 that's just an incidental side benefit. I've found more and more hotel/edge networks blocking/capturing this traffic. The biggest problem is they tend to break things horribly and fail things like the oarc entropy test. They will often also return REFUSED (randomly) to valid well formed DNS queries. While I support the capturing of malware compromised machines until they are repaired, I do think more intelligence needs to be applied when directing these systems. Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, TCP/443. The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios. Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). - Jared From paul at telcodata.us Mon Dec 7 23:28:41 2009 From: paul at telcodata.us (Paul Timmins) Date: Mon, 07 Dec 2009 18:28:41 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> Message-ID: <4B1D8FA9.6070000@telcodata.us> Jared Mauch wrote: > The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks > IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even > VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios. > > Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). > > - Jared > I'm pretty sure that's the hotel doing the blocking, USS isn't the type to enforce anything specific like that that I've found as they're a wholesaler and blocking that stuff tends to annoy those who are whiteboxing their product. They definitely don't do anything like that on their transit links. -Paul From bruns at 2mbit.com Tue Dec 8 00:23:29 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 07 Dec 2009 17:23:29 -0700 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> Message-ID: <4B1D9C81.6070608@2mbit.com> On 12/7/09 4:00 PM, Jared Mauch wrote: > > Providers to avoid: US Signal Corporation. (64.141.138.226 was my > natted IP in a Hampton Inn depsite whois/swip). > Add Air2Data (seen in Best Western in WY). 20 someodd APs, all routerboards, all same SSID, overlapping channels, hijacking 80 and 53. When using PPTP or IPSec VPN, the AP chokes and locks out all other clients, eventually stops responding completely. SpeedLinks (once again, Best Western, in Tacoma, WA) was almost as bad. Port 53 hijacking, flakey PPTP support, no ethernet jacks. I'm noticing alot of these places are doing things which work perfectly with Windows, but not Mac, Linux, etc. Drives me bonkers, and we make sure to let management know we won't stay at their hotel in the future because of said issues. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jared at puck.nether.net Tue Dec 8 00:38:24 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Dec 2009 19:38:24 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <4B1D9C81.6070608@2mbit.com> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <4B1D9C81.6070608@2mbit.com> Message-ID: On Dec 7, 2009, at 7:23 PM, Brielle Bruns wrote: > I'm noticing alot of these places are doing things which work perfectly with Windows, but not Mac, Linux, etc. Drives me bonkers, and we make sure to let management know we won't stay at their hotel in the future because of said issues. I'd prefer to not create a blacklist of hotels that have ghetto internet access, but perhaps this is something we can aggregate? I'm mostly tired of people saying the internet is http(s) only. Even had hotels in Japan do some really nasty things... - Jared From ops.lists at gmail.com Tue Dec 8 01:15:53 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Dec 2009 06:45:53 +0530 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <4B1D9C81.6070608@2mbit.com> Message-ID: Swisscom Eurospot - found all through europe and ruinously expensive at like 25 euro a day, 9 euro an hour See http://www.mcabee.org/lists/nanog/Feb-07/msg00046.html for what goes on there .. dns proxying, and broken at that. On Tue, Dec 8, 2009 at 6:08 AM, Jared Mauch wrote: > > On Dec 7, 2009, at 7:23 PM, Brielle Bruns wrote: > >> I'm noticing alot of these places are doing things which work perfectly with Windows, but not Mac, Linux, etc. ?Drives me bonkers, and we make sure to let management know we won't stay at their hotel in the future because of said issues. > > I'd prefer to not create a blacklist of hotels that have ghetto internet access, but perhaps this is something we can aggregate? > > I'm mostly tired of people saying the internet is http(s) only. ?Even had hotels in Japan do some really nasty things... > > - Jared > -- Suresh Ramasubramanian (ops.lists at gmail.com) From andrew at accessplus.com.au Tue Dec 8 01:24:04 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Tue, 08 Dec 2009 11:54:04 +1030 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> Message-ID: <4B1DAAB4.8060802@accessplus.com.au> Disclaimer: /I work for a company that provides these services./ IMHO there is no need for any sort of DNS redirection after user authentication has taken place. We of course redirect UDP/TCP 53 to one of our servers along with 80 (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any authentication has occurred, but once this is completed the only reason any guest would use the local DNS server is if they were assigned a DHCP address. As far as our Routerboard/Mikrotik setup works, it'll masquerade for any non standard IP addresses that appear on the network (guests with static ip's assigned, corporate laptops etc) but once again after the authentication stage anything is allowed to pass unhindered. The only redirection that is used after authentication is for port 25 as 90% of user trying to send mail out via port 25 have no idea how to change their mail server, let alone why they might need to. It can be an issue as some systems use authentication on port 25. I would be interested to hear what people have to say about this, as the only other option I could think of would involve checking the incoming connection to see if the end user was trying to authenticate to a mail server before determining where to forward the connection onto (Layer 7 stuff, gets a bit tricky) Regards, Andrew Cox AccessPlus Head Network Administrator Jared Mauch wrote: > On Dec 7, 2009, at 5:29 PM, John Levine wrote: > > >>> Will be interesting to see if ISPs respond to a large scale thing like >>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >>> (albeit for other reasons). Therein lies the problem with some of the >>> "net neturality" arguments .. there's a big difference between "doing it >>> because it causes a problem for others", and "doing it because it robs >>> me of revenue opportunities". >>> >> I do hear of ISPs blocking requests to random offsite DNS servers. >> For most consumer PCs, that's more likely to be a zombie doing DNS >> hijacking than anything legitimate. If they happen also to block >> 8.8.8.8 that's just an incidental side benefit. >> > > I've found more and more hotel/edge networks blocking/capturing this traffic. > > The biggest problem is they tend to break things horribly and fail things like the > oarc entropy test. > > They will often also return REFUSED (randomly) to valid well formed DNS queries. > > While I support the capturing of malware compromised machines until they are > repaired, I do think more intelligence needs to be applied when directing these systems. > > Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, > TCP/443. > > The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks > IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even > VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios. > > Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). > > - Jared > From ops.lists at gmail.com Tue Dec 8 01:35:34 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Dec 2009 07:05:34 +0530 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <4B1DAAB4.8060802@accessplus.com.au> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <4B1DAAB4.8060802@accessplus.com.au> Message-ID: You could just firewall off port 25 and leave 587 open - to save yourself from a bunch of viruses and such. A lot of people will use webmail anyway - from a hotel. And you avoid getting blacklisted The other option is to install a device that examines email flows and allows only stuff it doesnt think is spammy (netflow for email kind of, with all the bayesian etc secret sauce). Two devices come to mind * Symantec E160 (used to be called turntide, and before that, back in 2002-03, spam squelcher) * Mailchannels (www.mailchannels.com) There's probably a few more that do this and are totally transparent. On Tue, Dec 8, 2009 at 6:54 AM, Andrew Cox wrote: > > I would be interested to hear what people have to say about this, as the > only other option I could think of would involve checking the incoming > connection to see if the end user was trying to authenticate to a mail > server before determining where to forward the connection onto (Layer 7 > stuff, gets a bit tricky) -- Suresh Ramasubramanian (ops.lists at gmail.com) From andrew at accessplus.com.au Tue Dec 8 01:44:01 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Tue, 08 Dec 2009 12:14:01 +1030 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <4B1DAAB4.8060802@accessplus.com.au> Message-ID: <4B1DAF61.2020407@accessplus.com.au> Suresh Ramasubramanian wrote: > You could just firewall off port 25 and leave 587 open - to save > yourself from a bunch of viruses and such. > A lot of people will use webmail anyway - from a hotel. And you avoid > getting blacklisted > The problem with doing that is that users don't understand it. All they know is that "it doesn't work here and it does at home". We currently redirect to a couple of dedicated mail relays that will accept any email where: a) the source address = the email address the put on their signup and b) is not detected as spam Alternatively there's a throttling table and spam filter on everything else that comes through. > The other option is to install a device that examines email flows and > allows only stuff it doesnt think is spammy (netflow for email kind > of, with all the bayesian etc secret sauce). > Two devices come to mind > > * Symantec E160 (used to be called turntide, and before that, back in > 2002-03, spam squelcher) > * Mailchannels (www.mailchannels.com) > > There's probably a few more that do this and are totally transparent. > We can also just force the box to accept any unsecured auth-attempts however the SMTPS over port 25 is still a problem. Don't see how any system could examine that mail without causing certificate errors. Allowing it to pass to the original server based on the first packet being detected as a secure connection may be possible thou. > On Tue, Dec 8, 2009 at 6:54 AM, Andrew Cox wrote: > >> I would be interested to hear what people have to say about this, as the >> only other option I could think of would involve checking the incoming >> connection to see if the end user was trying to authenticate to a mail >> server before determining where to forward the connection onto (Layer 7 >> stuff, gets a bit tricky) >> > > > > From smb at cs.columbia.edu Tue Dec 8 02:48:25 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 7 Dec 2009 21:48:25 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> Message-ID: <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: > > On Dec 7, 2009, at 5:29 PM, John Levine wrote: > >>> Will be interesting to see if ISPs respond to a large scale thing like >>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >>> (albeit for other reasons). Therein lies the problem with some of the >>> "net neturality" arguments .. there's a big difference between "doing it >>> because it causes a problem for others", and "doing it because it robs >>> me of revenue opportunities". >> >> I do hear of ISPs blocking requests to random offsite DNS servers. >> For most consumer PCs, that's more likely to be a zombie doing DNS >> hijacking than anything legitimate. If they happen also to block >> 8.8.8.8 that's just an incidental side benefit. > > I've found more and more hotel/edge networks blocking/capturing this traffic. > > The biggest problem is they tend to break things horribly and fail things like the > oarc entropy test. > > They will often also return REFUSED (randomly) to valid well formed DNS queries. > > While I support the capturing of malware compromised machines until they are > repaired, I do think more intelligence needs to be applied when directing these systems. > > Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, > TCP/443. It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... --Steve Bellovin, http://www.cs.columbia.edu/~smb From lou at metron.com Tue Dec 8 03:18:00 2009 From: lou at metron.com (Lou Katz) Date: Mon, 7 Dec 2009 19:18:00 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> Message-ID: <20091208031800.GA25224@metron.com> On Mon, Dec 07, 2009 at 09:48:25PM -0500, Steven Bellovin wrote: > > On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: > > > > > On Dec 7, 2009, at 5:29 PM, John Levine wrote: > > > >>> Will be interesting to see if ISPs respond to a large scale thing like > >>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 > >>> (albeit for other reasons). Therein lies the problem with some of the > >>> "net neturality" arguments .. there's a big difference between "doing it > >>> because it causes a problem for others", and "doing it because it robs > >>> me of revenue opportunities". > >> > >> I do hear of ISPs blocking requests to random offsite DNS servers. > >> For most consumer PCs, that's more likely to be a zombie doing DNS > >> hijacking than anything legitimate. If they happen also to block > >> 8.8.8.8 that's just an incidental side benefit. > > > > I've found more and more hotel/edge networks blocking/capturing this traffic. > > > > The biggest problem is they tend to break things horribly and fail things like the > > oarc entropy test. > > > > They will often also return REFUSED (randomly) to valid well formed DNS queries. > > > > While I support the capturing of malware compromised machines until they are > > repaired, I do think more intelligence needs to be applied when directing these systems. > > > > Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, > > TCP/443. > > It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ me too, as well on on port 80 > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > -- -=[L]=- Our core competencies are office moves and vocabulary. From jgreco at ns.sol.net Tue Dec 8 03:32:20 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 7 Dec 2009 21:32:20 -0600 (CST) Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <4B1DAAB4.8060802@accessplus.com.au> from "Andrew Cox" at Dec 08, 2009 11:54:04 AM Message-ID: <200912080332.nB83WKSo037049@aurora.sol.net> > IMHO there is no need for any sort of DNS redirection after user > authentication has taken place. It may be hazardous even before user authentication has taken place. Even given a very low TTL, client resolvers may cache answers returned during that initial authentication. > We of course redirect UDP/TCP 53 to one of our servers along with 80 > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any > authentication has occurred, but once this is completed the only reason > any guest would use the local DNS server is if they were assigned a DHCP > address. Which, presumably, many/most of them are. Supplying a functional DNS server shouldn't be that difficult, but real world experience shows just how well some operators run these services. > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any > non standard IP addresses that appear on the network (guests with static > ip's assigned, corporate laptops etc) but once again after the > authentication stage anything is allowed to pass unhindered. > > The only redirection that is used after authentication is for port 25 as > 90% of user trying to send mail out via port 25 have no idea how to > change their mail server, let alone why they might need to. > It can be an issue as some systems use authentication on port 25. Sounds like an opportunity for a custom proxy. Clients that can successfully authenticate to an external mailserver on 25 are probably by definition nonproblematic. The remainder probably deserve to get jammed through an aggressive spam, virus, and other-crap filter, with in-line notification of rejections. You can do some other sanity stuff like counting the number of hosts contacted by a client; anything in excess of a small number would seem to be a good indicator to stop. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From johnl at iecc.com Tue Dec 8 03:35:05 2009 From: johnl at iecc.com (John R. Levine) Date: 7 Dec 2009 22:35:05 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> Message-ID: > It's why I run an ssh server on 443 somewhere -- and as needed, I > ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections > as I really need... Same here. It's the most reliable way to break out of a hotel jail. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From smeuse at mara.org Tue Dec 8 03:35:09 2009 From: smeuse at mara.org (Steve Meuse) Date: Mon, 7 Dec 2009 22:35:09 -0500 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: <20091208033509.GA32371@mara.org> Martin Hannigan expunged (martin at theicelandguy.com): > > Why did Google put an infrastructure critical application into PA space? > I'm not sure what the policy is now, but it seemed that when I was at L3 (losing my memory at this point) 4/8 was used as PA space and 8/8 was basically handed out as PI space. I could be wrong... -Steve From eslerj at gmail.com Tue Dec 8 05:12:38 2009 From: eslerj at gmail.com (Joel Esler) Date: Tue, 8 Dec 2009 00:12:38 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> Message-ID: <0234D7B3-43F2-4E18-A152-0BEC97FAE66C@gmail.com> On Dec 7, 2009, at 10:35 PM, John R. Levine wrote: >> It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... > > Same here. It's the most reliable way to break out of a hotel jail. Funny enough, I happen to be staying at a Marriott this week, where apparently I can't do ANYTHING on this network (my iChat client won't even connect!). Just so happens that I brought my Xbox360 this week and plugged it into the TV to get some Modern Warfare 2 on, and of course, THAT wasn't going to work on the network either right? Right. So, I broke out my Mifi (from Verizon). Connected my xbox360 to my mifi and played some Call of Duty. No lag. Okay, I feel better, done ranting against stayonline and guestnet. J From eslerj at gmail.com Tue Dec 8 05:13:15 2009 From: eslerj at gmail.com (Joel Esler) Date: Tue, 8 Dec 2009 00:13:15 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <20091208031800.GA25224@metron.com> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> <20091208031800.GA25224@metron.com> Message-ID: <3A16AD47-0163-43A7-86C7-6A177B44288F@gmail.com> On Dec 7, 2009, at 10:18 PM, Lou Katz wrote: > On Mon, Dec 07, 2009 at 09:48:25PM -0500, Steven Bellovin wrote: >> >> On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: >> >>> >>> On Dec 7, 2009, at 5:29 PM, John Levine wrote: >>> >>>>> Will be interesting to see if ISPs respond to a large scale thing like >>>>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >>>>> (albeit for other reasons). Therein lies the problem with some of the >>>>> "net neturality" arguments .. there's a big difference between "doing it >>>>> because it causes a problem for others", and "doing it because it robs >>>>> me of revenue opportunities". >>>> >>>> I do hear of ISPs blocking requests to random offsite DNS servers. >>>> For most consumer PCs, that's more likely to be a zombie doing DNS >>>> hijacking than anything legitimate. If they happen also to block >>>> 8.8.8.8 that's just an incidental side benefit. >>> >>> I've found more and more hotel/edge networks blocking/capturing this traffic. >>> >>> The biggest problem is they tend to break things horribly and fail things like the >>> oarc entropy test. >>> >>> They will often also return REFUSED (randomly) to valid well formed DNS queries. >>> >>> While I support the capturing of malware compromised machines until they are >>> repaired, I do think more intelligence needs to be applied when directing these systems. >>> >>> Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, >>> TCP/443. >> >> It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... Also handy to set up an SSH tunnel. That works for almost everything else. J From marka at isc.org Tue Dec 8 05:39:22 2009 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Dec 2009 16:39:22 +1100 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: Your message of "Mon, 07 Dec 2009 21:32:20 MDT." <200912080332.nB83WKSo037049@aurora.sol.net> References: <200912080332.nB83WKSo037049@aurora.sol.net> Message-ID: <200912080539.nB85dMHD003129@drugs.dv.isc.org> In message <200912080332.nB83WKSo037049 at aurora.sol.net>, Joe Greco writes: > > IMHO there is no need for any sort of DNS redirection after user > > authentication has taken place. > > It may be hazardous even before user authentication has taken place. > Even given a very low TTL, client resolvers may cache answers returned > during that initial authentication. > > > We of course redirect UDP/TCP 53 to one of our servers along with 80 > > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any > > authentication has occurred, but once this is completed the only reason > > any guest would use the local DNS server is if they were assigned a DHCP > > address. > > Which, presumably, many/most of them are. Supplying a functional DNS > server shouldn't be that difficult, but real world experience shows just > how well some operators run these services. > > > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any > > non standard IP addresses that appear on the network (guests with static > > ip's assigned, corporate laptops etc) but once again after the > > authentication stage anything is allowed to pass unhindered. > > > > The only redirection that is used after authentication is for port 25 as > > 90% of user trying to send mail out via port 25 have no idea how to > > change their mail server, let alone why they might need to. > > It can be an issue as some systems use authentication on port 25. > > Sounds like an opportunity for a custom proxy. Clients that can > successfully authenticate to an external mailserver on 25 are probably > by definition nonproblematic. The remainder probably deserve to get > jammed through an aggressive spam, virus, and other-crap filter, with > in-line notification of rejections. You can do some other sanity stuff > like counting the number of hosts contacted by a client; anything in > excess of a small number would seem to be a good indicator to stop. > > ... 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(CN > N) > With 24 million small businesses in the US alone, that's way too many apples. > This really should be a DHCP option which points to the authentification server using ip addresses. This should be return to clients even if they don't request it. Web browers could have a hot-spot button that retrieves this option then connects using the value returned. No need to compromise the DNS or intercept http. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sthaug at nethelp.no Tue Dec 8 09:14:53 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 08 Dec 2009 10:14:53 +0100 (CET) Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912080539.nB85dMHD003129@drugs.dv.isc.org> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> Message-ID: <20091208.101453.74674743.sthaug@nethelp.no> > This really should be a DHCP option which points to the authentification > server using ip addresses. This should be return to clients even > if they don't request it. Web browers could have a hot-spot button that > retrieves this option then connects using the value returned. Unfortunately, that's not how DHCP works. If you send the client a DHCP option which the client has not requested, you have no idea if the client will use (or for that matter even *understand*) the option. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From andrew at accessplus.com.au Tue Dec 8 09:18:38 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Tue, 08 Dec 2009 19:48:38 +1030 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912080539.nB85dMHD003129@drugs.dv.isc.org> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> Message-ID: <4B1E19EE.40409@accessplus.com.au> Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected. Until such time it's simply unworkable. That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops. Andrew > > This really should be a DHCP option which points to the authentification > server using ip addresses. This should be return to clients even > if they don't request it. Web browers could have a hot-spot button that > retrieves this option then connects using the value returned. > > No need to compromise the DNS or intercept http. > > Mark > From jgreco at ns.sol.net Tue Dec 8 09:39:18 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 8 Dec 2009 03:39:18 -0600 (CST) Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912080539.nB85dMHD003129@drugs.dv.isc.org> from "Mark Andrews" at Dec 08, 2009 04:39:22 PM Message-ID: <200912080939.nB89dIXn090157@aurora.sol.net> > > > In message <200912080332.nB83WKSo037049 at aurora.sol.net>, Joe Greco writes: > > > IMHO there is no need for any sort of DNS redirection after user > > > authentication has taken place. > > > > It may be hazardous even before user authentication has taken place. > > Even given a very low TTL, client resolvers may cache answers returned > > during that initial authentication. > > > > > We of course redirect UDP/TCP 53 to one of our servers along with 80 > > > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any > > > authentication has occurred, but once this is completed the only reason > > > any guest would use the local DNS server is if they were assigned a DHCP > > > address. > > > > Which, presumably, many/most of them are. Supplying a functional DNS > > server shouldn't be that difficult, but real world experience shows just > > how well some operators run these services. > > > > > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any > > > non standard IP addresses that appear on the network (guests with static > > > ip's assigned, corporate laptops etc) but once again after the > > > authentication stage anything is allowed to pass unhindered. > > > > > > The only redirection that is used after authentication is for port 25 as > > > 90% of user trying to send mail out via port 25 have no idea how to > > > change their mail server, let alone why they might need to. > > > It can be an issue as some systems use authentication on port 25. > > > > Sounds like an opportunity for a custom proxy. Clients that can > > successfully authenticate to an external mailserver on 25 are probably > > by definition nonproblematic. The remainder probably deserve to get > > jammed through an aggressive spam, virus, and other-crap filter, with > > in-line notification of rejections. You can do some other sanity stuff > > like counting the number of hosts contacted by a client; anything in > > excess of a small number would seem to be a good indicator to stop. > > This really should be a DHCP option which points to the authentification > server using ip addresses. This should be return to clients even > if they don't request it. Web browers could have a hot-spot button that > retrieves this option then connects using the value returned. > > No need to compromise the DNS or intercept http. But that doesn't change the fact that there's a need; it's a part of the flawed design of the various components, because this problem wasn't envisioned and solved and now we have a mess. Even the hotspot vendors cannot agree on a unified way to do things; this means that each network you try to connect to will implement its own set of unique brokenness, ranging from requirements for a particular OS/browser, use of reserved/ allocated IP spaces for stupid reasons (hi, 1.1.1.1!), various DNS/HTTP attempts at redirection, blocking, etc. I know what you're saying, but seriously, haven't we just repeated all the same mistakes in IPv6? And of course it'd be a nightmare to cover all the edge cases, this is why nobody tries to figure it out, so in the end we end up with many really cruddy hatchet jobs. Why would "web browsers" have a hot-spot button? What if I want to just use ssh? And where's the web browser on my VoIP telephony adapter, etc? :-) It's gotta be difficult for the hotspot networks. Even at&t can't seem to make it all work right even when they control both sides; I've seen iPhones just hang when connecting to attwifi (and I can say I've seen it not work in some way maybe even more often than I've seen it actually work). At least the iPhone seems to have some built-in support for this sort of thing. (Anybody know anything more about that?) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From andrew at accessplus.com.au Tue Dec 8 10:00:17 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Tue, 08 Dec 2009 20:30:17 +1030 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912080939.nB89dIXn090157@aurora.sol.net> References: <200912080939.nB89dIXn090157@aurora.sol.net> Message-ID: <4B1E23B1.5000707@accessplus.com.au> Yeah the iPhone changes were a bit of a pain, we had to build a second iPhone specific version of our login page because the iPhone "auto-login" feature won't allow more than 1 page to be loaded. We would normally redirect users to the page they've originally requested after they click the login button as well as opening a status popup for them to logout and keep track of usage. Not on the iPhone thou, they're using a cut-down safari browser that won't allow more than 1 tab to load and worst of all, if you close off the page it simply disconnects from the wireless network. Andrew > > It's gotta be difficult for the hotspot networks. Even at&t can't seem > to make it all work right even when they control both sides; I've seen > iPhones just hang when connecting to attwifi (and I can say I've seen > it not work in some way maybe even more often than I've seen it actually > work). At least the iPhone seems to have some built-in support for this > sort of thing. (Anybody know anything more about that?) > > ... JG > From lists at quux.de Tue Dec 8 10:14:44 2009 From: lists at quux.de (Jens Link) Date: Tue, 08 Dec 2009 11:14:44 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> (Jorge Amodio's message of "Fri\, 4 Dec 2009 06\:11\:34 -0600") References: <4B16F535.70306@sunwave.net> <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> Message-ID: <87bpi9wz57.fsf@laphroiag.quux.de> Jorge Amodio writes: > I guess Cisco's 800's are out of the "Consumer Grade" price range, but > any comments about v6 support on them and how they compare with other > options. Once you find the right IOS version they are working great. ;-) I had to upgrade my router @home in order to use IPv6 on the wireless lan. Interface configuration wasn't accepting any ipv6 commands. cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From lists at quux.de Tue Dec 8 10:19:45 2009 From: lists at quux.de (Jens Link) Date: Tue, 08 Dec 2009 11:19:45 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091204154442.GE8736@radiological.warningg.com> (Brandon Ewing's message of "Fri\, 4 Dec 2009 09\:44\:42 -0600") References: <4B16F535.70306@sunwave.net> <202705b0912040411u7518f65cxc9c72b4d1587ab02@mail.gmail.com> <0181FC63-6A37-4AEC-83E0-EB570B94DB2A@internode.com.au> <20091204154442.GE8736@radiological.warningg.com> Message-ID: <877hsxwywu.fsf@laphroiag.quux.de> Brandon Ewing writes: > Can you comment on what version you got it to work on? I haven't futzed > with it much, but with 12.4(24)T2, you can't put an ipv6 address directly on > the wireless subinterface. I tried putting it on a BVI interface, but > didn't have much luck. Version 12.4(20)T1 works.... interface Dot11Radio0 !.... ipv6 address 2001:db8:9F6B:2::1/64 ipv6 enable ipv6 nd prefix 2001:db8:9F6B:2::/64 cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From chris at ghostbusters.co.uk Tue Dec 8 13:13:03 2009 From: chris at ghostbusters.co.uk (Chris) Date: Tue, 8 Dec 2009 13:13:03 +0000 Subject: Linux shaping packet loss In-Reply-To: References: Message-ID: Hi All, It would be appreciated if anyone using TC on Linux for shaping could please help with an intermittent problem on an egress interface. I'm seeing about ten per cent of packet loss for all classes at seemingly quiet times and random parts of the day using about forty classes and 250Mbps. I've isolated it to the egress HTB qdisc. Any TC experts out there have a spare minute please ? Any thoughts on the RED qdisc ? Thanks very much, Chris From marka at isc.org Tue Dec 8 14:11:22 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Dec 2009 01:11:22 +1100 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: Your message of "Tue, 08 Dec 2009 10:14:53 BST." <20091208.101453.74674743.sthaug@nethelp.no> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <20091208.101453.74674743.sthaug@nethelp.no> Message-ID: <200912081411.nB8EBMq0009253@drugs.dv.isc.org> In message <20091208.101453.74674743.sthaug at nethelp.no>, sthaug at nethelp.no writes: > > This really should be a DHCP option which points to the authentification > > server using ip addresses. This should be return to clients even > > if they don't request it. Web browers could have a hot-spot button that > > retrieves this option then connects using the value returned. > > Unfortunately, that's not how DHCP works. If you send the client a > DHCP option which the client has not requested, you have no idea if > the client will use (or for that matter even *understand*) the option. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no It can still parse and skip it from the the DHCP response as every option contains its own length. Initially clients will ignore it but over time it will be supported on the client side. This is a much better way than intercepting DNS queries and returning respones that will just be ignored by validating and iterative resolvers. Something like http://1.2.3.4/terms.html or http://[2001::1]/terms.html doesn't require that everthing be intercepted. Just block until acceptance. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bclark at spectraaccess.com Tue Dec 8 14:43:19 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 08 Dec 2009 09:43:19 -0500 Subject: Linux shaping packet loss In-Reply-To: References: Message-ID: <4B1E6607.60503@spectraaccess.com> Won't say I'm an expert with TC, but anytime I see packet loss on an interface I always check the interface itself...10% packet loss is pretty much what you would get if there was a duplex problem. I always try to hard set my interfaces on both the Linux machines and Switches. Bret Chris wrote: > Hi All, > > It would be appreciated if anyone using TC on Linux for shaping could please > help with an intermittent problem on an egress interface. > > I'm seeing about ten per cent of packet loss for all classes at seemingly > quiet times and random parts of the day using about forty classes and > 250Mbps. I've isolated it to the egress HTB qdisc. > > Any TC experts out there have a spare minute please ? Any thoughts on the > RED qdisc ? > > Thanks very much, > > Chris > From marka at isc.org Tue Dec 8 14:52:49 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Dec 2009 01:52:49 +1100 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: Your message of "Tue, 08 Dec 2009 03:39:18 MDT." <200912080939.nB89dIXn090157@aurora.sol.net> References: <200912080939.nB89dIXn090157@aurora.sol.net> Message-ID: <200912081453.nB8EqnY7011360@drugs.dv.isc.org> In message <200912080939.nB89dIXn090157 at aurora.sol.net>, Joe Greco writes: > > > > > > In message <200912080332.nB83WKSo037049 at aurora.sol.net>, Joe Greco writes: > > > > IMHO there is no need for any sort of DNS redirection after user > > > > authentication has taken place. > > > > > > It may be hazardous even before user authentication has taken place. > > > Even given a very low TTL, client resolvers may cache answers returned > > > during that initial authentication. > > > > > > > We of course redirect UDP/TCP 53 to one of our servers along with 80 > > > > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any > > > > authentication has occurred, but once this is completed the only reason > > > > any guest would use the local DNS server is if they were assigned a DHCP > > > > address. > > > > > > Which, presumably, many/most of them are. Supplying a functional DNS > > > server shouldn't be that difficult, but real world experience shows just > > > how well some operators run these services. > > > > > > > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any > > > > non standard IP addresses that appear on the network (guests with static > > > > ip's assigned, corporate laptops etc) but once again after the > > > > authentication stage anything is allowed to pass unhindered. > > > > > > > > The only redirection that is used after authentication is for port 25 as > > > > 90% of user trying to send mail out via port 25 have no idea how to > > > > change their mail server, let alone why they might need to. > > > > It can be an issue as some systems use authentication on port 25. > > > > > > Sounds like an opportunity for a custom proxy. Clients that can > > > successfully authenticate to an external mailserver on 25 are probably > > > by definition nonproblematic. The remainder probably deserve to get > > > jammed through an aggressive spam, virus, and other-crap filter, with > > > in-line notification of rejections. You can do some other sanity stuff > > > like counting the number of hosts contacted by a client; anything in > > > excess of a small number would seem to be a good indicator to stop. > > > > This really should be a DHCP option which points to the authentification > > server using ip addresses. This should be return to clients even > > if they don't request it. Web browers could have a hot-spot button that > > retrieves this option then connects using the value returned. > > > > No need to compromise the DNS or intercept http. > > But that doesn't change the fact that there's a need; it's a part of the > flawed design of the various components, because this problem wasn't > envisioned and solved and now we have a mess. Even the hotspot vendors > cannot agree on a unified way to do things; this means that each network > you try to connect to will implement its own set of unique brokenness, > ranging from requirements for a particular OS/browser, use of reserved/ > allocated IP spaces for stupid reasons (hi, 1.1.1.1!), various DNS/HTTP > attempts at redirection, blocking, etc. > > I know what you're saying, but seriously, haven't we just repeated all > the same mistakes in IPv6? And of course it'd be a nightmare to cover > all the edge cases, this is why nobody tries to figure it out, so in > the end we end up with many really cruddy hatchet jobs. > > Why would "web browsers" have a hot-spot button? Because that would be a easy way to implement this sort of thing. You could have a command line tool or a seperate widget that that launched the browser. > What if I want to just use ssh? You still need to authenticate. It's better if we can reduce the amount of collateral damage required to authenticate. The interception is being done today because there is no standard way to say "go here to authenticate" and the hotspot provider has to do a man in the middle attack to get you to the authentication page. > And where's the web browser on my VoIP telephony adapter, etc? :-) Does you VoIP telephony adapter work today in hotspots that require authentication? It isn't that hard to build in a display. Having a DHCP option is better than the mess we have now. To go further requires agreement on how to present terms, pricing etc. in a standardised way. > It's gotta be difficult for the hotspot networks. Even at&t can't seem > to make it all work right even when they control both sides; I've seen > iPhones just hang when connecting to attwifi (and I can say I've seen > it not work in some way maybe even more often than I've seen it actually > work). At least the iPhone seems to have some built-in support for this > sort of thing. (Anybody know anything more about that?) > > ... 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sthaug at nethelp.no Tue Dec 8 15:01:35 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 08 Dec 2009 16:01:35 +0100 (CET) Subject: Linux shaping packet loss In-Reply-To: <4B1E6607.60503@spectraaccess.com> References: <4B1E6607.60503@spectraaccess.com> Message-ID: <20091208.160135.74707586.sthaug@nethelp.no> > Won't say I'm an expert with TC, but anytime I see packet loss on an > interface I always check the interface itself...10% packet loss is > pretty much what you would get if there was a duplex problem. I always > try to hard set my interfaces on both the Linux machines and Switches. Used to set everything hard five years ago. Nowadays auto works just fine most of the time. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jabley at hopcount.ca Tue Dec 8 15:13:48 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 8 Dec 2009 15:13:48 +0000 Subject: Linux shaping packet loss In-Reply-To: <20091208.160135.74707586.sthaug@nethelp.no> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> Message-ID: <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> On 2009-12-08, at 15:01, sthaug at nethelp.no wrote: >> Won't say I'm an expert with TC, but anytime I see packet loss on an >> interface I always check the interface itself...10% packet loss is >> pretty much what you would get if there was a duplex problem. I always >> try to hard set my interfaces on both the Linux machines and Switches. > > Used to set everything hard five years ago. Nowadays auto works just > fine most of the time. I find there is a lot of hard-coded wisdom that hard-coded speed duplex are the way to avoid pain. The last time I saw anybody do a modern survey of switches, routers and hosts, however, it seemed like the early interop problems with autoneg on FE really don't exist today, and on balance there are probably more duplex problems caused by hard-configured ports that are poorly maintained in the heat of battle than there are because autoneg is flaky. I've also heard people say that whatever you think about autoneg in Fast Ethernet, on Gigabit and 10GE interfaces it's pretty much never the right idea to turn autoneg off. I am profoundly ignorant of the details of layer-2. It'd be nice to have more than vague rhetoric to guide me when configuring interfaces. What reliable guidance exists for this stuff? Joe From chris at ghostbusters.co.uk Tue Dec 8 15:14:01 2009 From: chris at ghostbusters.co.uk (Chris) Date: Tue, 8 Dec 2009 15:14:01 +0000 Subject: Linux shaping packet loss In-Reply-To: <20091208.160135.74707586.sthaug@nethelp.no> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> Message-ID: Thanks, Steiner and everyone for the input. It's good to see the list is still as friendly as ever. There are two paths I'm trying to get my head round after someone offlist helpfully suggested putting cburst and burst on all classes. My thoughts are that any dropped packets on the parent class is a bad thing: qdisc htb 1: root r2q 10 default 265 direct_packets_stat 448 ver 3.17 Sent 4652558768 bytes 5125175 pkt (dropped 819, overlimits 10048800 requeues 0) rate 0bit 0pps backlog 0b 28p requeues 0 Until now I've had Rate and Ceil at the same values on all the classes but I take the point about cburst and burst allowing greater levels of borrowing so I've halved the Rate for all classes and left the Ceil the same. I've gone done this route mainly because I really can't risk breaking things with incorrect cburst and burst values (if anyone can please tell me on an i686 box at, say, 10Mbps the ideal values I can translate them into higher classes, TC seems to work them out as 1600b/8 mpu by default and the timing resolution confuses me.) Thanks again, Chris 2009/12/8 > > Won't say I'm an expert with TC, but anytime I see packet loss on an > > interface I always check the interface itself...10% packet loss is > > pretty much what you would get if there was a duplex problem. I always > > try to hard set my interfaces on both the Linux machines and Switches. > > Used to set everything hard five years ago. Nowadays auto works just > fine most of the time. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > From owen at delong.com Tue Dec 8 15:14:47 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Dec 2009 07:14:47 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <4B1E19EE.40409@accessplus.com.au> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> Message-ID: <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> On Dec 8, 2009, at 1:18 AM, Andrew Cox wrote: > Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected. > Until such time it's simply unworkable. > > That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops. > And it just breaks for those of us who actually expect "internet access" to mean access to the internet, not just the web. I make a habbit of calling support and pushing the issue hard through multiple layers until I finally get a management denial, then, demand refunds of my connectivity charges every time I encounter this at a hotel. I figure that the reason you guys deploy what "just works" as you put it is because it lowers your support costs, so, I do what I can to increase the support costs of delivering a broken internet. I encourage others to do the same. Owen > Andrew >> >> This really should be a DHCP option which points to the authentification >> server using ip addresses. This should be return to clients even >> if they don't request it. Web browers could have a hot-spot button that >> retrieves this option then connects using the value returned. >> >> No need to compromise the DNS or intercept http. >> >> Mark >> From MatlockK at exempla.org Tue Dec 8 15:18:57 2009 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Tue, 8 Dec 2009 08:18:57 -0700 Subject: Linux shaping packet loss In-Reply-To: <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> References: <4B1E6607.60503@spectraaccess.com><20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3CEC@LMC-MAIL2.exempla.org> The biggest problem with duplex had to do with 100mb. Cisco (and a lot of other companies) decided in their infinite wisdom that at 100mb if auto-negotiation fails, to use half duplex as the default. So if you have both sides at auto, or both sides hard-set it's all good. But if one side is hard-set and the other is auto, a lot of times the auto device will come up 100/Half. These days at 1Gb+ Full-Duplex seems to be the 'default' for auto-negotiation failures. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, December 08, 2009 8:14 AM To: sthaug at nethelp.no Cc: nanog at nanog.org Subject: Re: Linux shaping packet loss On 2009-12-08, at 15:01, sthaug at nethelp.no wrote: >> Won't say I'm an expert with TC, but anytime I see packet loss on an >> interface I always check the interface itself...10% packet loss is >> pretty much what you would get if there was a duplex problem. I always >> try to hard set my interfaces on both the Linux machines and Switches. > > Used to set everything hard five years ago. Nowadays auto works just > fine most of the time. I find there is a lot of hard-coded wisdom that hard-coded speed duplex are the way to avoid pain. The last time I saw anybody do a modern survey of switches, routers and hosts, however, it seemed like the early interop problems with autoneg on FE really don't exist today, and on balance there are probably more duplex problems caused by hard-configured ports that are poorly maintained in the heat of battle than there are because autoneg is flaky. I've also heard people say that whatever you think about autoneg in Fast Ethernet, on Gigabit and 10GE interfaces it's pretty much never the right idea to turn autoneg off. I am profoundly ignorant of the details of layer-2. It'd be nice to have more than vague rhetoric to guide me when configuring interfaces. What reliable guidance exists for this stuff? Joe From owen at delong.com Tue Dec 8 15:21:27 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Dec 2009 07:21:27 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912080939.nB89dIXn090157@aurora.sol.net> References: <200912080939.nB89dIXn090157@aurora.sol.net> Message-ID: <581D3A8A-DD00-4D76-B895-D2486D8D2A42@delong.com> > > I know what you're saying, but seriously, haven't we just repeated all > the same mistakes in IPv6? And of course it'd be a nightmare to cover > all the edge cases, this is why nobody tries to figure it out, so in > the end we end up with many really cruddy hatchet jobs. > Not exactly.... With IPv6, RA/SLAAC is nearly instantaneous, unlike DHCP. This is both good and bad. For this purpose, it happens to be good... 1. Have your authentication server running on a host that will accept connections to _ANY_ address. 2. Have your router send RA/SLAAC for your authentication network to unauthenticated machines such that their default gateway is an address that lands them on the authentication server. 3. Once they're authenticated, send them real RA/SLAAC. 4. No need to hork DNS, and, the web page you faked at first can work just fine after they log in, even if they cached the DNS information because you gave them the legitimate address. > Why would "web browsers" have a hot-spot button? What if I want to > just use ssh? And where's the web browser on my VoIP telephony > adapter, etc? :-) > Almost all of these systems require you to call support to get a MAC authentication Exception if you don't have a web browser on your device. Most of them grant exceptions on a not to exceed 30 day basis, too. > It's gotta be difficult for the hotspot networks. Even at&t can't seem > to make it all work right even when they control both sides; I've seen > iPhones just hang when connecting to attwifi (and I can say I've seen > it not work in some way maybe even more often than I've seen it actually > work). At least the iPhone seems to have some built-in support for this > sort of thing. (Anybody know anything more about that?) > Yep... Then there are the airports where there seems to be a spanning tree delay between getting associated with the hotspot and being able to get a DHCP address. (I've only encountered this behavior at a few US airports, never on a hotel network). Owen From andrew at accessplus.com.au Tue Dec 8 15:25:28 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Wed, 09 Dec 2009 01:55:28 +1030 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> Message-ID: <4B1E6FE8.9010705@accessplus.com.au> Owen DeLong wrote: > On Dec 8, 2009, at 1:18 AM, Andrew Cox wrote: > > >> Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected. >> Until such time it's simply unworkable. >> >> That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops. >> > And it just breaks for those of us who actually expect "internet access" to mean > access to the internet, not just the web. > I never said that the *just works* method stopped users from being able to use the internet. In fact catching users with bad IP address settings works just as well as sending them a DHCP address. > I make a habbit of calling support and pushing the issue hard through multiple > layers until I finally get a management denial, then, demand refunds of my > connectivity charges every time I encounter this at a hotel. > > I figure that the reason you guys deploy what "just works" as you put it is because > it lowers your support costs, so, I do what I can to increase the support costs of > delivering a broken internet. > We're in no way in the business of providing half-baked services and likewise, I call up support for other providers if I end up with just web access. > I encourage others to do the same. > > Owen > From andrew at accessplus.com.au Tue Dec 8 15:32:44 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Wed, 09 Dec 2009 02:02:44 +1030 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <581D3A8A-DD00-4D76-B895-D2486D8D2A42@delong.com> References: <200912080939.nB89dIXn090157@aurora.sol.net> <581D3A8A-DD00-4D76-B895-D2486D8D2A42@delong.com> Message-ID: <4B1E719C.4000700@accessplus.com.au> Owen DeLong wrote: > Almost all of these systems require you to call support to get a MAC > authentication Exception if you don't have a web browser on your > device. Most of them grant exceptions on a not to exceed 30 day > basis, too. > Alternatively it's possible to offer both web-based and pppoe authentication options from the same port. Allows users to connect xbox's, ps3's, VoIP phones, Wireless routers. All without the need for the web auth. For us, it's about giving the end user the choice and making the connection as seamless and simple as possible. If that means for some users there's magic going on in the background that they don't know or understand then so be it, that's just another part of the service we're providing. From bicknell at ufp.org Tue Dec 8 15:40:22 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 8 Dec 2009 07:40:22 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912081453.nB8EqnY7011360@drugs.dv.isc.org> References: <200912080939.nB89dIXn090157@aurora.sol.net> <200912081453.nB8EqnY7011360@drugs.dv.isc.org> Message-ID: <20091208154022.GA57438@ussenterprise.ufp.org> In a message written on Wed, Dec 09, 2009 at 01:52:49AM +1100, Mark Andrews wrote: > > What if I want to just use ssh? > > You still need to authenticate. It's better if we can reduce the > amount of collateral damage required to authenticate. The interception > is being done today because there is no standard way to say "go here to > authenticate" and the hotspot provider has to do a man in the middle > attack to get you to the authentication page. Most of the hotels I have used don't actually require authentication. They require a click through indemnification agreement. No username, no password, no room number, just a "click here to accept our terms and conditions". I would much prefer this be added to the check-in process. I already have to sign a contract with the hotel to check in, it should cover use of the WiFi as well. Then there is no need for a click through agreement. If there is need for authentication at that point (I am the one who signed the front desk agreement) then using 802.1x authentication would be the right answer. If I could do it with an OpenID, or other "public" account by providing the account name when I sign the paper at the front desk then I could have all of my devices always on, in a standard way, and never see these stupid pages. Imagine, you make a reservation online for a hotel, you use an ID which is the same as your e-mail so it auto-populates on the online form. When you check in you sign the T&C's, and your devices authenticate with 802.1x, which you just leave configured, since you're always using the same ID. No more MITM, all standards based. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dot at dotat.at Tue Dec 8 15:47:20 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 8 Dec 2009 15:47:20 +0000 Subject: Linux shaping packet loss In-Reply-To: <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> Message-ID: On Tue, 8 Dec 2009, Joe Abley wrote: > > I find there is a lot of hard-coded wisdom that hard-coded speed duplex > are the way to avoid pain. That was definitely true in the mid-to-late 1990s. > The last time I saw anybody do a modern survey of switches, routers and > hosts, however, it seemed like the early interop problems with autoneg > on FE really don't exist today, and on balance there are probably more > duplex problems caused by hard-configured ports that are poorly > maintained in the heat of battle than there are because autoneg is > flaky. Yes. The autoneg specification was fixed in 1998 so modern kit should interoperate properly. > I've also heard people say that whatever you think about autoneg in Fast > Ethernet, on Gigabit and 10GE interfaces it's pretty much never the > right idea to turn autoneg off. Autoneg is a required part of the gig E specification so you'd only be causing yourself trouble by turning it off. (I don't know if it'll also break automatic MDI/MDI-X (crossover) configuration, for an example of something that's nice to have.) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From sronan at fattoc.com Tue Dec 8 16:12:30 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 8 Dec 2009 11:12:30 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> Message-ID: Juniper SSL VPN FTW! On Dec 7, 2009, at 9:48 PM, Steven Bellovin wrote: > > On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: > >> >> On Dec 7, 2009, at 5:29 PM, John Levine wrote: >> >>>> Will be interesting to see if ISPs respond to a large scale thing like >>>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >>>> (albeit for other reasons). Therein lies the problem with some of the >>>> "net neturality" arguments .. there's a big difference between "doing it >>>> because it causes a problem for others", and "doing it because it robs >>>> me of revenue opportunities". >>> >>> I do hear of ISPs blocking requests to random offsite DNS servers. >>> For most consumer PCs, that's more likely to be a zombie doing DNS >>> hijacking than anything legitimate. If they happen also to block >>> 8.8.8.8 that's just an incidental side benefit. >> >> I've found more and more hotel/edge networks blocking/capturing this traffic. >> >> The biggest problem is they tend to break things horribly and fail things like the >> oarc entropy test. >> >> They will often also return REFUSED (randomly) to valid well formed DNS queries. >> >> While I support the capturing of malware compromised machines until they are >> repaired, I do think more intelligence needs to be applied when directing these systems. >> >> Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, >> TCP/443. > > It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > From sthaug at nethelp.no Tue Dec 8 16:13:42 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 08 Dec 2009 17:13:42 +0100 (CET) Subject: Linux shaping packet loss In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D3CEC@LMC-MAIL2.exempla.org> References: <20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> <4288131ED5E3024C9CD4782CECCAD2C7065D3CEC@LMC-MAIL2.exempla.org> Message-ID: <20091208.171342.74699048.sthaug@nethelp.no> > The biggest problem with duplex had to do with 100mb. > > Cisco (and a lot of other companies) decided in their infinite wisdom > that at 100mb if auto-negotiation fails, to use half duplex as the > default. No, that wasn't those companies deciding to do so in their infinite wisdom. That was those companies deciding to follow the IEEE standard! Cisco and others may be to blame for a lot of things, but not this one. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bruns at 2mbit.com Tue Dec 8 16:38:54 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 08 Dec 2009 09:38:54 -0700 Subject: Linux shaping packet loss In-Reply-To: <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> Message-ID: <4B1E811E.2040400@2mbit.com> On 12/8/09 8:13 AM, Joe Abley wrote: > I've also heard people say that whatever you think about autoneg in > Fast Ethernet, on Gigabit and 10GE interfaces it's pretty much never > the right idea to turn autoneg off. From my own experience, turning off auto negotiate can lead to unusual behavior later on that may cause a bit of grief. Our SAN (LHN NSM260) refused flat out to do 802.3ad - giving us duplex errors. Took us around an hour of diagnosing - first we thought it was the switch, then we thought it was the cables we used, etc. Finally it dawned on me that my partner is notorious for hard coding ports on our own equipment. Low and behold, after her swearing up and down that there's no way its that, we set both ends to auto negotiate and boom, bonding came up happy as a clam. Only one port on our entire setup that is hard coded - 10BaseT-FD - and thats only because the darn thing refuses to auto negotiate to full duplex for 10BaseT links. I'm almost positive that a year or two down the line, we're going to forget that is there when we change the link to 100BaseT. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From dot at dotat.at Tue Dec 8 16:39:07 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 8 Dec 2009 16:39:07 +0000 Subject: SPF Configurations In-Reply-To: References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <4B1D4094.9020303@csuohio.edu> Message-ID: On Tue, 8 Dec 2009, Suresh Ramasubramanian wrote: > > As for a university smarthost getting blocked you'd probably need to > look at one of two things - Three :-) > 1. Forwarding users on your campus - with mailboxes that accept a lot > of spam and then forward it over to student / alumni AOL, Comcast, > Yahoo etc accounts > 2. Spam generated by infected PCs / laptops, hacked machines etc on > your campus LAN 3. Spammers abusing your webmail and/or remote message submission service using phished credentials. If your incoming spam blocks are effective then forwarding shouldn't be too much of a problem. For on-campus bots, block port 25 and ensure your MX servers can't be used as outgoing relays (i.e. put your outgoing relay service on a separate address). If you are lucky your colleagues chose a really obscure name (not mail.* or smtp.* etc.) for your outgoing relay service 20 years ago so spammers are less likely to guess it :-) To protect against phished accounts, apply rate-limits to outgoing email. If you have good on-campus security hygeine then you can be much less strict about the limits for on-campus connections. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From ops.lists at gmail.com Tue Dec 8 16:39:57 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Dec 2009 22:09:57 +0530 Subject: SPF Configurations In-Reply-To: References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <4B1D4094.9020303@csuohio.edu> Message-ID: Absolutely #3 - far more of a threat than #1 and #2. On Tue, Dec 8, 2009 at 10:09 PM, Tony Finch wrote: > Three :-) > >> 1. Forwarding users on your campus - with mailboxes that accept a lot >> of spam and then forward it over to student / alumni AOL, Comcast, >> Yahoo etc accounts >> 2. Spam generated by infected PCs / laptops, hacked machines etc on >> your campus LAN > > 3. Spammers abusing your webmail and/or remote message submission service > using phished credentials. -- Suresh Ramasubramanian (ops.lists at gmail.com) From vixie at isc.org Tue Dec 8 16:59:20 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 08 Dec 2009 16:59:20 +0000 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> (Steven Bellovin's message of "Mon\, 7 Dec 2009 21\:48\:25 -0500") References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> Message-ID: Steven Bellovin writes: > It's why I run an ssh server on 443 somewhere -- and as needed, I > ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections > as I really need... me too, more or less. but steve, if we were only trying to build digital infrastructure for people who know how to do that, then we'd all still be using Usenet over modems. we're trying to build digital infrastructure for all of humanity, and that means stuff like the above has to be unnecessary. -- Paul Vixie KI6YSY From mike at mtcc.com Tue Dec 8 17:07:17 2009 From: mike at mtcc.com (Michael Thomas) Date: Tue, 08 Dec 2009 09:07:17 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912080539.nB85dMHD003129@drugs.dv.isc.org> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> Message-ID: <4B1E87C5.5000104@mtcc.com> On 12/07/2009 09:39 PM, Mark Andrews wrote: >>>> 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(CN >> N) >> With 24 million small businesses in the US alone, that's way too many apples. >> > > This really should be a DHCP option which points to the authentification > server using ip addresses. This should be return to clients even > if they don't request it. Web browers could have a hot-spot button that > retrieves this option then connects using the value returned. > > No need to compromise the DNS or intercept http. A DHCP option that ultimately charges my credit card? ::shudder:: Mike From michael.holstein at csuohio.edu Tue Dec 8 18:08:25 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 08 Dec 2009 13:08:25 -0500 Subject: Linux shaping packet loss In-Reply-To: <4B1E811E.2040400@2mbit.com> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> <4B1E811E.2040400@2mbit.com> Message-ID: <4B1E9619.5050600@csuohio.edu> > From my own experience, turning off auto negotiate can lead to unusual > behavior later on I too had this crop up in an unusual manner .. the hardware was HP with Intel Pro 1000 on one side, and Cisco 65xx on the other. Neither side saw errors, and (most) everything seemed to work .. however, one java app that depended on SSL would constantly fail when it tried to retrieve a file. Both sides hard coded (didn't matter to what) wouldn't work. When we upgraded to GigE blades, it still wouldn't work in any hard-coded configuration, even though the O/S (Win2k3 .. RDP, FTP, etc.) appeared to work. Set both sides auto/auto : bam. problem solved. The app was Sonicwall Email Security (on the off-chance someone else is fighting that same issue). Cheers, Michael Holstein Cleveland State University From michael.holstein at csuohio.edu Tue Dec 8 18:19:16 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 08 Dec 2009 13:19:16 -0500 Subject: SPF Configurations In-Reply-To: References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <4B1D4094.9020303@csuohio.edu> Message-ID: <4B1E98A4.3080009@csuohio.edu> > 3. Spammers abusing your webmail and/or remote message submission service > using phished credentials. > I'll admit .. this has happened a few times too. Usually we see the incoming phish attempt and configure an outbound block for RE: (same subject) and it never fails .. we catch at least one person that responds. We've seriously considered sending our own phishing emails with a link that automatically disables anyone's account if they click it. > If your incoming spam blocks are effective then forwarding shouldn't be > too much of a problem. > > Never-ending game of cat & mouse. Our volume is 1.5-2m msg/day, and I'd say we catch ~95% of it .. but when a batch gets through and a third of our students have mail forwarded to Yahoo, from Yahoo's point-of-view, they just got 10,000 spam from our IPs. > For on-campus bots, block port 25 and ensure your MX servers can't be used > as outgoing relays We do that, as well as run daily reports on outbound ACL denies to see who's been compromised (or being naughty on purpose). > (i.e. put your outgoing relay service on a separate > address). If you are lucky your colleagues chose a really obscure name > (not mail.* or smtp.* etc.) They did. > To protect against phished accounts, apply rate-limits to outgoing email. > If you have good on-campus security hygeine then you can be much less > strict about the limits for on-campus connections. > > Anyone know how to do this in Domino off-hand? (without sending IBM a fat check) .. if so, I'd love to hear about it so I can tell our Lotus admins. Cheers, Michael Holstein Cleveland State University From scott at doc.net.au Tue Dec 8 18:24:54 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 8 Dec 2009 10:24:54 -0800 Subject: Linux shaping packet loss In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D3CEC@LMC-MAIL2.exempla.org> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> <4288131ED5E3024C9CD4782CECCAD2C7065D3CEC@LMC-MAIL2.exempla.org> Message-ID: On Tue, Dec 8, 2009 at 7:18 AM, Matlock, Kenneth L wrote: > These days at 1Gb+ Full-Duplex seems to be the 'default' for > auto-negotiation failures. > Thankfully it's even more than a "seems to be" - it's written into the IEEE spec that if duplex negotiation fails then the default is full duplex for 1Gbps, as opposed to HDX for 100Mbps and earlier. Scott From jabley at hopcount.ca Tue Dec 8 18:36:07 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 8 Dec 2009 18:36:07 +0000 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912081453.nB8EqnY7011360@drugs.dv.isc.org> References: <200912080939.nB89dIXn090157@aurora.sol.net> <200912081453.nB8EqnY7011360@drugs.dv.isc.org> Message-ID: <783413A3-6EDB-456C-927D-B47FAE84C374@hopcount.ca> On 2009-12-08, at 14:52, Mark Andrews wrote: >> Why would "web browsers" have a hot-spot button? > > Because that would be a easy way to implement this sort of thing. I once thought that PANA was the clean answer to this. Now the PANA effort has concluded, and documents have been published, but reading through them I can't tell whether PANA is in fact any kind of answer to this. RFC 4058 RFC 5191 It'd be nice if there was a hotspot authentication solution buried in there, somewhere. Joe Begin forwarded message: > From: IESG Secretary > Date: 4 December 2009 21:30:03 GMT > To: ietf-announce at ietf.org > Cc: pana at ietf.org, basavaraj.patil at nokia.com > Subject: WG Action: Conclusion of Protocol for carrying Authentication for Network Access (pana) > list-id: "IETF announcement list. No discussions." > > The Protocol for carrying Authentication for Network Access (pana) working > group in the Internet Area has concluded. > > The IESG contact persons are Jari Arkko and Ralph Droms. > > The mailing list will remain active. > > This working group is closed after successfully completing its chartered > work. The mailing list will be kept open for possible questions and > discussions around PANA. In addition, several remaining documents about > PANA extensions have been submitted for the individual submission process. > The documents will progressed as soon as their necessary revisions become > available. > > The ADs would like to thank everyone who has been involved in the PANA > specification work, the chairs, Mark Townsley who was the responsible AD > when the PANA base documents were published, and various reviewers who > helped greatly improve the PANA specifications. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From dot at dotat.at Tue Dec 8 18:42:19 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 8 Dec 2009 18:42:19 +0000 Subject: SPF Configurations In-Reply-To: <4B1E98A4.3080009@csuohio.edu> References: <09120408252597_5AC@oregon.uoregon.edu> <3C5B084431653D4A9C469A22AFCDB5B9042929FF@LOGAN.billtrust.local> <4B193D55.8030400@spectraaccess.com> <3c857e1c0912040903l41bccedbo44c1afe269e542d2@mail.gmail.com> <4B1D4094.9020303@csuohio.edu> <4B1E98A4.3080009@csuohio.edu> Message-ID: On Tue, 8 Dec 2009, Michael Holstein wrote: > > > 3. Spammers abusing your webmail and/or remote message submission service > > using phished credentials. > > I'll admit .. this has happened a few times too. Usually we see the > incoming phish attempt and configure an outbound block for RE: (same > subject) and it never fails .. we catch at least one person that > responds. We've seriously considered sending our own phishing emails > with a link that automatically disables anyone's account if they click it. In addition to rate-limiting, you can get some assistance from the anti-phishing email reply blacklist (see http://code.google.com/p/anti-phishing-email-reply/) which is included in the Sanesecurity ClamAV add-on databases (see http://sanesecurity.co.uk/databases.htm). Even if it's too late to block the incoming phish it can be useful to block your users' replies. There's also "Kochi" which analyses email for phishing- related patterns, including detecting messages that contain users' passwords (see http://oss.lboro.ac.uk/kochi1.html). There's a fair amount of discussion of this kind of thing on the hied-emailadmin list (see https://listserv.nd.edu/cgi-bin/wa?A0=HIED-EMAILADMIN). > Our volume is 1.5-2m msg/day, and I'd say we catch ~95% of it .. but > when a batch gets through and a third of our students have mail > forwarded to Yahoo, from Yahoo's point-of-view, they just got 10,000 > spam from our IPs. Ah, you have rather more forwarding than we do. > Anyone know how to do this in Domino off-hand? (without sending IBM a > fat check) .. if so, I'd love to hear about it so I can tell our Lotus > admins. Put a Unix mailer between it and the real world :-) I think Exim's rate limiting facility is excellent, but then I wrote it :-) Tony. -- http://dotat.at/ ${sg{\N${sg{\ N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\ \N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}} From r.gelobter at limestonenetworks.com Tue Dec 8 18:42:28 2009 From: r.gelobter at limestonenetworks.com (Ryan Gelobter) Date: Tue, 8 Dec 2009 12:42:28 -0600 Subject: Earthlink SMTP Admin Contact? Message-ID: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD17@lsnexchange.limestonenetworks.com> Any chance there's someone from Earthlink on nanog or anyone that has contact information? We have a large IP block that is being listed as dynamic by Earthlink's mail servers causing mail to be returned and have gotten nowhere with the normal procedures or the abuse mailbox at (866) 525-8194. Feel free to contact me off-list. Thanks, Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelobter at limestonenetworks.com www.limestonenetworks.com Simple. Solid. Superior. From owen at delong.com Tue Dec 8 19:00:33 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Dec 2009 11:00:33 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <4B1E6FE8.9010705@accessplus.com.au> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> Message-ID: <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> On Dec 8, 2009, at 7:25 AM, Andrew Cox wrote: > Owen DeLong wrote: >> >> On Dec 8, 2009, at 1:18 AM, Andrew Cox wrote: >> >> >>> Sounds like a great idea in theory but would require OS support or >>> a dual-hotspot setup that provided for both options until support >>> was expected. >>> Until such time it's simply unworkable. >>> >>> That and as mentioned in my previous post, the setup we have *just >>> works* for users who don't have the permissions to change off of a >>> static IP and use DHCP on their laptops. >>> >> And it just breaks for those of us who actually expect "internet >> access" to mean >> access to the internet, not just the web. >> > I never said that the *just works* method stopped users from being > able to use the internet. In fact catching users with bad IP address > settings works just as well as sending them a DHCP address. I expect my connections to my mail server to actually reach my mail server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just works" settings in question break these things badly. Stop doing man in the middle attacks on my mail, or, expect me to be a support headache. It's just that simple. >> I make a habbit of calling support and pushing the issue hard >> through multiple >> layers until I finally get a management denial, then, demand >> refunds of my >> connectivity charges every time I encounter this at a hotel. >> >> I figure that the reason you guys deploy what "just works" as you >> put it is because >> it lowers your support costs, so, I do what I can to increase the >> support costs of >> delivering a broken internet. >> > We're in no way in the business of providing half-baked services and > likewise, I call up support for other providers if I end up with > just web access. Good... As long as you're not MITM my stuff, then, I won't be calling your support people. Perhaps I misunderstood your explanation of what you do to port 25 traffic that "just works". Owen >> I encourage others to do the same. >> >> Owen >> > From nikky at mnet.bg Tue Dec 8 19:09:57 2009 From: nikky at mnet.bg (Nickola Kolev) Date: Tue, 8 Dec 2009 21:09:57 +0200 Subject: Linux shaping packet loss In-Reply-To: References: Message-ID: <20091208210957.a17c2484.nikky@mnet.bg> On Tue, 8 Dec 2009 13:13:03 +0000 Chris wrote: > Hi All, > > It would be appreciated if anyone using TC on Linux for shaping could please > help with an intermittent problem on an egress interface. Well, it's unbelievable, but almost 5 hours and 11 mails later not even one of them has mentioned something different than L2 incompatibilities! And this, IMHO, has nothing to do with Chris problems. I'd really expect more from the guys that make the Internet run... Anyway... :) > I'm seeing about ten per cent of packet loss for all classes at seemingly > quiet times and random parts of the day using about forty classes and > 250Mbps. I've isolated it to the egress HTB qdisc. I'd start with a careful revisit of each class and the classifier that goes with it. I'd pay special attention to go with u32/hash classifiers (filters), and not with iptables. You can try to visualize the number of packets in each class (queued,dropped), and that way you will probably could see where the problem is. > Any TC experts out there have a spare minute please ? Any thoughts on the > RED qdisc ? As for this, I'd suggest to take a look at: [1] http://lartc.org/howto/lartc.adv-qdisc.red.html [2] http://www.opalsoft.net/qos/DS-26.htm > Thanks very much, > > Chris -- Best regards, Nickola From nanog at daork.net Tue Dec 8 20:48:35 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 9 Dec 2009 09:48:35 +1300 Subject: Linux shaping packet loss In-Reply-To: References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <9EC109B1-66BD-460B-AF86-7A8EB753496B@hopcount.ca> Message-ID: On 9/12/2009, at 4:47 AM, Tony Finch wrote: > Autoneg is a required part of the gig E specification so you'd only be > causing yourself trouble by turning it off. (I don't know if it'll > also > break automatic MDI/MDI-X (crossover) configuration, for an example of > something that's nice to have.) Yes it will break auto MDI/MDI-X. -- Nathan Ward From sethm at rollernet.us Tue Dec 8 21:04:29 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 08 Dec 2009 13:04:29 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <20091208154022.GA57438@ussenterprise.ufp.org> References: <200912080939.nB89dIXn090157@aurora.sol.net> <200912081453.nB8EqnY7011360@drugs.dv.isc.org> <20091208154022.GA57438@ussenterprise.ufp.org> Message-ID: <4B1EBF5D.4020101@rollernet.us> Leo Bicknell wrote: > > Most of the hotels I have used don't actually require authentication. > They require a click through indemnification agreement. No username, > no password, no room number, just a "click here to accept our terms > and conditions". > > I would much prefer this be added to the check-in process. I already > have to sign a contract with the hotel to check in, it should cover use > of the WiFi as well. Then there is no need for a click through > agreement. > Yes there is; if they have wireless then the radio waves don't discriminate between guest and non-guest and could be picked up by someone who didn't sign the check-in paperwork. ~Seth From smb at cs.columbia.edu Tue Dec 8 21:05:44 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 8 Dec 2009 16:05:44 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> Message-ID: <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> On Dec 8, 2009, at 11:59 AM, Paul Vixie wrote: > Steven Bellovin writes: > >> It's why I run an ssh server on 443 somewhere -- and as needed, I >> ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections >> as I really need... > > me too, more or less. but steve, if we were only trying to build digital > infrastructure for people who know how to do that, then we'd all still be > using Usenet over modems. we're trying to build digital infrastructure for > all of humanity, and that means stuff like the above has to be unnecessary. > -- Right -- which means that we need a *good* solution. "Good" has to encompass not just technical cleanliness, but also operational reality, which includes things like slow software update rates -- both on clients and the hotel infrastructures -- the very wide variety of client platforms out there. The problems we're talking about, though, are both competence and policy. There's no intrinsic reason why hotels have to block some ports, especially given that many others do not. They've chosen to, for whatever misguided reason. (Aside: my local library blocks everything but 80 and 443 outbound. I complained to the director; he cited "security". I tried explaining that I knew something about Internet security; he told me that the firm that had installed the system had "done most of the libraries in the county". I translate that as "most of the libraries in the county have broken security policies".) And competence? Again, we've all seen many different ways certain things are done. I once had to boot into Windows to get a lease because NetBSD just wouldn't deal with the broken DNS packets necessary for the sign-up procedure. After that, I rebooted into NetBSD and configured a static address and route. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jmamodio at gmail.com Tue Dec 8 21:21:30 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 8 Dec 2009 15:21:30 -0600 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> Message-ID: <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> > ?(Aside: my local library blocks everything but 80 and 443 outbound. ?I complained to the director; he cited "security". ?I tried explaining that I knew something about Internet security; he told me that the firm that had installed the system had "done most of the libraries in the county". ?I translate that as "most of the libraries in the county have broken security policies".) Among the many wonderful things Internet has created in the past 2+ decades, it gave birth to a countless number of "Internet Experts" ... Perhaps a more organized/focused discussion may help kick off an IETF WG to identify and document the problems/needs/requirements and an informational RFC/BCP can be produced, then the "experts" will know that for better security and reliability they don't need to mutilate internet protocols or dismember the Internet. My .02 Jorge From mike at mtcc.com Tue Dec 8 21:46:43 2009 From: mike at mtcc.com (Michael Thomas) Date: Tue, 08 Dec 2009 13:46:43 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> Message-ID: <4B1EC943.6090805@mtcc.com> On 12/08/2009 01:21 PM, Jorge Amodio wrote: >> (Aside: my local library blocks everything but 80 and 443 outbound. I complained to the director; he cited "security". I tried explaining that I knew something about Internet security; he told me that the firm that had installed the system had "done most of the libraries in the county". I translate that as "most of the libraries in the county have broken security policies".) > > Among the many wonderful things Internet has created in the past 2+ > decades, it gave birth > to a countless number of "Internet Experts" ... > > Perhaps a more organized/focused discussion may help kick off an IETF > WG to identify and > document the problems/needs/requirements and an informational RFC/BCP > can be produced, > then the "experts" will know that for better security and reliability > they don't need to > mutilate internet protocols or dismember the Internet. I'm skeptical to the extreme that IETF can do anything particularly useful here. It's not like there's a lack of protocols -- AAA, tunneling, etc -- that could be bastardized to make some sort of client-side dohickey, or frob on the side something else instead of requiring html, styles sheets, and human eyeballs. Were there some sort of groundswell of such bastardized hacks, then maybe. Mike From vixie at isc.org Tue Dec 8 21:52:23 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 08 Dec 2009 21:52:23 +0000 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: Your message of "Tue, 08 Dec 2009 15:21:30 CST." <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> Message-ID: <77404.1260309143@nsa.vix.com> > Date: Tue, 8 Dec 2009 15:21:30 -0600 > From: Jorge Amodio > > Among the many wonderful things Internet has created in the past 2+ > decades, it gave birth to a countless number of "Internet Experts" ... for example, some of us got a chance to witness the following. i've removed all identifying marks. (i was NOT the author NOR the offender, but the author does read this mailing list, and several of you will no doubt recognize the flaming style once you consider the time/date stamp.) ------- Forwarded Message To: ... Subject: Re: verbal brickbats Date: Sun, 02 Jun 96 23:37:40 PDT From: ... My guess is that most people just ignore you. Which might be a shame, because your point of view is different enough from the average member of the list that you are valuable here just by being different. I think of you as a pompous egomaniac nut case, but that's just my opinion; I have no Greek or Latin quotations to back it up and no 5-point treatise about how some part of scripture says you're a bad person. It's just what I believe, based entirely on what you've said here. In your world you're a fancy professor with power and authority. You're probably the intellectual terror of [your] postal code. Here in my world of cyberspace you're just an arrogant twit who knows Greek. If you want to spend your time making impassioned arguments to the people who already agree with you, then just keep doing what you're doing. If your goal is to change somebody's mind about one of the topics that you address, then you need to learn both some manners and some rhetorical technique. If you want to teach somebody, to expand somebody's understanding, to increase the number of people in the world who agree with you, then please listen to me, because here in cyberspace I'm the guy with the power and experience and authority and you're just an insect. ... Let me give you a few pointers on being taken more seriously. * First, you have the habit of making arguments from authority, rather than as an individual. Sometimes it is important to establish your authority in some area, in much the same way that an expert witness in a courtroom establishes his credibility and authority on the topic for which he is to testify. You may think of yourself as an authority on the matters that you are expounding on, but we don't yet. Your academic pedigree and your quotations from ancient languages are just bluster here on the Internet. The general principle here in cyberspace is that we participate as individuals and not as representatives of authoritative bodies. You can earn the right to wield the authority of some body on whose behalf you speak, but you don't walk in our door holding that authority just because you are B.A., M.A., Ph.D. and have a white beard. [...] If your goal in writing to the Internet is to change somebody's mind about some topic that you care about, then you really must learn to communicate in a very different style. * Second, you are constantly trying to impress us with how much better educated you are than we are. This might be related to the first item, above, since if you're going to be arguing from authority then you probably need to keep establishing that you have some authority. I think you'll find that this is a pretty highly educated crowd, but you don't catch us relying on our academic pedigrees instead of on our ability to communicate. I am quite certain that I have absolutely as many degrees as you do, and I am completely certain that I know many more obscure languages than you do, but if I can't win an argument with you based on what I say and how I say it, then my degrees are all just puffery, aren't they? But in establishing a precedent of authority and pedigree as the basis for power, you are treading on dangerous ground. Here in cyberspace you aren't in your world, you're in mine. If you make the mistake of trying to establish some ground rules in which argument by authority is the norm, then you'd better make sure that you don't ruffle the feathers of somebody who has more of it than you do. I can make the Internet do anything I want it to do. I can perform the digital equivalent of heaving lightning bolts in front of your chariot, and rending the earth beneath your mail reader. I can turn your hard disk into a toad. I'm a technocrat. But I won't, because we professionals don't act that way. I don't have to brandish my power and authority and education and knowledge of arcana in order to get people to listen to me. I try to make a crisp argument and let my words carry that argument. If I fail, then I don't go running for some Greek derivation or invoke some long-dead philosopher. Heck, I don't even go running for analogies from Clint Eastwood's "Unforgiven", which is every bit as fine a piece of literature as Aristophanes. * Third, you convey a complete disdain for your reader. Your writing style reeks of the belief that your time is so much more important than the time of your reader that you can't be bothered to write correctly or to edit what you write. If you'd like to have more readers, then it would be very worthwhile for you to be more respectful of them. Among other things, this means that you need to write in a way that makes it easier for your reader to read: use real sentences with real capital letters at the beginnings of them, and do try to spell as many words right as you can muster. So mind your manners, learn to communicate better, stop insulting your readers, and then come back and contribute your intellect to [this] mailing list. If you keep acting like a jerk I'm going to wake up some morning, yawn, make a cup of tea, and then vaporize your mailbox. Sometimes we supremely powerful technocrats just have a bad day. ------- End of Forwarded Message From eslerj at gmail.com Tue Dec 8 22:12:05 2009 From: eslerj at gmail.com (Joel Esler) Date: Tue, 8 Dec 2009 17:12:05 -0500 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <77404.1260309143@nsa.vix.com> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> <77404.1260309143@nsa.vix.com> Message-ID: <314cf0830912081412v4732c677k56074579301a036d@mail.gmail.com> On Tue, Dec 8, 2009 at 4:52 PM, Paul Vixie wrote: > > Date: Tue, 8 Dec 2009 15:21:30 -0600 > > From: Jorge Amodio > > > > Among the many wonderful things Internet has created in the past 2+ > > decades, it gave birth to a countless number of "Internet Experts" ... > > for example, some of us got a chance to witness the following. i've > removed all identifying marks. (i was NOT the author NOR the offender, > but the author does read this mailing list, and several of you will no > doubt recognize the flaming style once you consider the time/date stamp.) > > ------- Forwarded Message > > To: ... > Subject: Re: verbal brickbats > Date: Sun, 02 Jun 96 23:37:40 PDT > From: ... > > My guess is that most people just ignore you. Which might be a shame, > because your point of view is different enough from the average member > of the list that you are valuable here just by being different. I think > of you as a pompous egomaniac nut case, but that's just my opinion; I > have no Greek or Latin quotations to back it up and no 5-point treatise > about how some part of scripture says you're a bad person. It's just > what I believe, based entirely on what you've said here. > > In your world you're a fancy professor with power and authority. You're > probably the intellectual terror of [your] postal code. Here in my > world of cyberspace you're just an arrogant twit who knows Greek. If > you want to spend your time making impassioned arguments to the people > who already agree with you, then just keep doing what you're doing. If > your goal is to change somebody's mind about one of the topics that you > address, then you need to learn both some manners and some rhetorical > technique. If you want to teach somebody, to expand somebody's > understanding, to increase the number of people in the world who agree > with you, then please listen to me, because here in cyberspace I'm the > guy with the power and experience and authority and you're just an > insect. ... > > Let me give you a few pointers on being taken more seriously. > > * First, you have the habit of making arguments from authority, rather > than as an individual. Sometimes it is important to establish > your authority in some area, in much the same way that an expert > witness in a courtroom establishes his credibility and authority on the > topic for which he is to testify. > > You may think of yourself as an authority on the matters that you are > expounding on, but we don't yet. Your academic pedigree and your > quotations from ancient languages are just bluster here on the Internet. > > The general principle here in cyberspace is that we participate as > individuals and not as representatives of authoritative bodies. You can > earn the right to wield the authority of some body on whose behalf you > speak, but you don't walk in our door holding that authority just > because you are B.A., M.A., Ph.D. and have a white beard. > > [...] > > If your goal in writing to the Internet is to change somebody's mind > about some topic that you care about, then you really must learn to > communicate in a very different style. > > * Second, you are constantly trying to impress us with how much better > educated you are than we are. This might be related to the first item, > above, since if you're going to be arguing from authority then you > probably need to keep establishing that you have some authority. I > think you'll find that this is a pretty highly educated crowd, but you > don't catch us relying on our academic pedigrees instead of on our > ability to communicate. I am quite certain that I have absolutely as > many degrees as you do, and I am completely certain that I know many > more obscure languages than you do, but if I can't win an argument with > you based on what I say and how I say it, then my degrees are all just > puffery, aren't they? > > But in establishing a precedent of authority and pedigree as the basis > for power, you are treading on dangerous ground. Here in cyberspace you > aren't in your world, you're in mine. If you make the mistake of trying > to establish some ground rules in which argument by authority is the > norm, then you'd better make sure that you don't ruffle the feathers of > somebody who has more of it than you do. I can make the Internet do > anything I want it to do. I can perform the digital equivalent of > heaving lightning bolts in front of your chariot, and rending the earth > beneath your mail reader. I can turn your hard disk into a toad. I'm a > technocrat. But I won't, because we professionals don't act that way. I > don't have to brandish my power and authority and education and > knowledge of arcana in order to get people to listen to me. I try to > make a crisp argument and let my words carry that argument. If I fail, > then I don't go running for some Greek derivation or invoke some > long-dead philosopher. Heck, I don't even go running for analogies from > Clint Eastwood's "Unforgiven", which is every bit as fine a piece of > literature as Aristophanes. > > * Third, you convey a complete disdain for your reader. Your writing > style reeks of the belief that your time is so much more important than > the time of your reader that you can't be bothered to write correctly > or to edit what you write. If you'd like to have more readers, then it > would be very worthwhile for you to be more respectful of them. Among > other things, this means that you need to write in a way that makes > it easier for your reader to read: use real sentences with real > capital letters at the beginnings of them, and do try to spell as many > words right as you can muster. > > So mind your manners, learn to communicate better, stop insulting your > readers, and then come back and contribute your intellect to [this] > mailing list. If you keep acting like a jerk I'm going to wake > up some morning, yawn, make a cup of tea, and then vaporize your > mailbox. Sometimes we supremely powerful technocrats just have a bad > day. > > ------- End of Forwarded Message > > This is a great email, it belongs on countless blogs. Written back then, still relevant now. J -- Joel Esler | 302-223-5974 | gtalk: jesler at sourcefire.com From dot at dotat.at Tue Dec 8 22:19:18 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 8 Dec 2009 22:19:18 +0000 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: On Sat, 5 Dec 2009, Chris Hills wrote: > > I maintain a list here [1], many of which are reachable with IPv6. > [1] http://www.chaz6.com/files/resolv.conf Not all of those are open resolvers, so I wonder what the cirteria for listing are. I'm especially surprised to see the IPv6 addresses of Cambridge's resolvers there. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From dot at dotat.at Tue Dec 8 22:36:10 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 8 Dec 2009 22:36:10 +0000 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <783413A3-6EDB-456C-927D-B47FAE84C374@hopcount.ca> References: <200912080939.nB89dIXn090157@aurora.sol.net> <200912081453.nB8EqnY7011360@drugs.dv.isc.org> <783413A3-6EDB-456C-927D-B47FAE84C374@hopcount.ca> Message-ID: On Tue, 8 Dec 2009, Joe Abley wrote: > > I once thought that PANA was the clean answer to this. Now the PANA > effort has concluded, and documents have been published, but reading > through them I can't tell whether PANA is in fact any kind of answer to > this. It'd be nice if there was a hotspot authentication solution buried > in there, somewhere. I know nothing about PANA except that abstract to RFC 4058 says it's a generalized replacement for link-layer authentication protocols such as 802.1x. But 802.1x wifi authentication works today - see for example http://www.eduroam.org/ - though the setup effort is only worth it if you are going to be using the authenticated network(s) a lot. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From jmamodio at gmail.com Tue Dec 8 22:46:14 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 8 Dec 2009 16:46:14 -0600 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <77404.1260309143@nsa.vix.com> References: <20091207222912.10709.qmail@simone.iecc.com> <3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net> <199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu> <666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu> <202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> <77404.1260309143@nsa.vix.com> Message-ID: <202705b0912081446t9d236fdw560aeedc548c4ea8@mail.gmail.com> Did you assume that I was insulting Steve ? not at all, and apologies Steve if my comments were interpreted that way. When I said "Internet Experts" I was referring to the ones that setup the network on his county library. I agree 100% with Steve that we need a Good solution, both technical and operational, that's why I was suggesting that perhaps a IETF WG or whatever framework people believe may work could help identify the problem, requirements and line up potential solutions. BTW I already shaved my beard and it was not white ... ;-) Regards Jorge From chaz at chaz6.com Tue Dec 8 23:09:51 2009 From: chaz at chaz6.com (Chris Hills) Date: Wed, 09 Dec 2009 00:09:51 +0100 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <775e001a0912040523x5a94e914x770aad7420f8fbb6@mail.gmail.com> <4B19145C.8060704@bennett.com> <75cb24520912041025o1ef0697ub0995dde3a0146d5@mail.gmail.com> Message-ID: On 08/12/09 23:19, Tony Finch wrote: > On Sat, 5 Dec 2009, Chris Hills wrote: >> >> I maintain a list here [1], many of which are reachable with IPv6. >> [1] http://www.chaz6.com/files/resolv.conf > > Not all of those are open resolvers, so I wonder what the cirteria for > listing are. I'm especially surprised to see the IPv6 addresses of > Cambridge's resolvers there. The criteria is basically "any server with a public ipv4/ipv6 address that provides a recursive dns service". Those that may be unreachable from off-net are marked "filtered". I have added a note explaining this. From leigh.porter at ukbroadband.com Tue Dec 8 23:57:29 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 8 Dec 2009 23:57:29 -0000 Subject: Breaking the internet (hotels, guestnet style) References: <20091207222912.10709.qmail@simone.iecc.com><3512DFEB-431F-4EDB-A8DB-7ACC04FF7A43@puck.nether.net><199FCDD1-9A96-4C6C-86B6-B8A4B0090A19@cs.columbia.edu><666B64B8-9736-413C-BE9B-F5F2D3B1BE58@cs.columbia.edu><202705b0912081321h7a0b2a31tfca5a9584184bce1@mail.gmail.com> <77404.1260309143@nsa.vix.com> Message-ID: All I can say to that is this: ?? ?? ???????? ????????? ?????, ???????? ??? ????? ??????? ? ??????????? ???? ?????? ??? ????? ?????? ?????. ;-) -- Leigh Porter UK Broadband -----Original Message----- From: Paul Vixie [mailto:vixie at isc.org] Sent: Tue 12/8/2009 9:52 PM To: nanog at merit.edu Subject: Re: Breaking the internet (hotels, guestnet style) > Date: Tue, 8 Dec 2009 15:21:30 -0600 > From: Jorge Amodio > > Among the many wonderful things Internet has created in the past 2+ > decades, it gave birth to a countless number of "Internet Experts" ... for example, some of us got a chance to witness the following. i've removed all identifying marks. (i was NOT the author NOR the offender, but the author does read this mailing list, and several of you will no doubt recognize the flaming style once you consider the time/date stamp.) ------- Forwarded Message To: ... Subject: Re: verbal brickbats Date: Sun, 02 Jun 96 23:37:40 PDT From: ... My guess is that most people just ignore you. Which might be a shame, because your point of view is different enough from the average member of the list that you are valuable here just by being different. I think of you as a pompous egomaniac nut case, but that's just my opinion; I have no Greek or Latin quotations to back it up and no 5-point treatise about how some part of scripture says you're a bad person. It's just what I believe, based entirely on what you've said here. From sean at donelan.com Wed Dec 9 00:18:28 2009 From: sean at donelan.com (Sean Donelan) Date: Tue, 8 Dec 2009 19:18:28 -0500 (EST) Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <200912081453.nB8EqnY7011360@drugs.dv.isc.org> References: <200912080939.nB89dIXn090157@aurora.sol.net> <200912081453.nB8EqnY7011360@drugs.dv.isc.org> Message-ID: <200912081848400.6B95064B.25292@clifden.donelan.com> On Wed, 9 Dec 2009, Mark Andrews wrote: > Having a DHCP option is better than the mess we have now. To go > further requires agreement on how to present terms, pricing etc. > in a standardised way. I hate to sound like a broken record, but PPPOE has had that option for a decade. Major operating system vendors would never implemented that PPPOE option. It wasn't an accidental ommission by one major vendor. In the mean time, i.e. for the last 10 years, hotspot/guestnets have come up with interesting kludges to work around the lack of support in major operating systems and applications. If you get something that works better and works for 90%+ of the potential market in less than 10 years, people will beat a path to your door. Some vendors have 802.1x clients which handle things farily well, in my opinion much better than another DHCP kludge (UDP protocol needing its own protection before causing your computer to run something); but anything requiring your customers to install special software seems to limit your potential market to a few percent. From williamsjj at digitar.com Wed Dec 9 00:30:05 2009 From: williamsjj at digitar.com (Jason Williams) Date: Tue, 8 Dec 2009 17:30:05 -0700 Subject: Earthlink SMTP Admin Contact? In-Reply-To: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD17@lsnexchange.limestonenetworks.com> References: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD17@lsnexchange.limestonenetworks.com> Message-ID: <533370AD-B650-46A9-B282-B7255482EEC6@digitar.com> Their NOC has an unlisted number: +1 404-815-0770 x22277 -J On Dec 8, 2009, at 11:42 AM, Ryan Gelobter wrote: > > Any chance there's someone from Earthlink on nanog or anyone that has contact information? > > We have a large IP block that is being listed as dynamic by Earthlink's mail servers causing mail to be returned and have gotten nowhere with the normal procedures or the abuse mailbox at (866) 525-8194. > > Feel free to contact me off-list. > > Thanks, > > Ryan G > IT Assistant/Support Technician > Limestone Networks, Inc. > r.gelobter at limestonenetworks.com > www.limestonenetworks.com > Simple. Solid. Superior. > > !SIG:4b1e9f00213371829418099! > From horms at verge.net.au Wed Dec 9 01:07:53 2009 From: horms at verge.net.au (Simon Horman) Date: Wed, 9 Dec 2009 12:07:53 +1100 Subject: Linux shaping packet loss In-Reply-To: References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> Message-ID: <20091209010747.GA20524@verge.net.au> On Tue, Dec 08, 2009 at 03:14:01PM +0000, Chris wrote: > Thanks, Steiner and everyone for the input. It's good to see the list is > still as friendly as ever. > > There are two paths I'm trying to get my head round after someone offlist > helpfully suggested putting cburst and burst on all classes. > > My thoughts are that any dropped packets on the parent class is a bad thing: > > qdisc htb 1: root r2q 10 default 265 direct_packets_stat 448 ver 3.17 > Sent 4652558768 bytes 5125175 pkt (dropped 819, overlimits 10048800 > requeues 0) > rate 0bit 0pps backlog 0b 28p requeues 0 > > Until now I've had Rate and Ceil at the same values on all the classes but I > take the point about cburst and burst allowing greater levels of borrowing > so I've halved the Rate for all classes and left the Ceil the same. > > I've gone done this route mainly because I really can't risk breaking things > with incorrect cburst and burst values (if anyone can please tell me on an > i686 box at, say, 10Mbps the ideal values I can translate them into higher > classes, TC seems to work them out as 1600b/8 mpu by default and the timing > resolution confuses me.) Silly question, but are you leaving some headroom? Its a little while since I've worked with HTB and from my experience the exact results do depend somewhat on the kernel that is in use, but trying to use much more than 90% of the link capacity caused troubles for me. In particular I'm referring to the ceil value of the root class. I also noticed that at higher packet rates (I was doing gigabit in a lab) that increasing r2q helped me. However I was looking at (UDP) throughput not packet loss. From beckman at angryox.com Wed Dec 9 04:27:36 2009 From: beckman at angryox.com (Peter Beckman) Date: Tue, 8 Dec 2009 23:27:36 -0500 Subject: Earthlink SMTP Admin Contact? In-Reply-To: <533370AD-B650-46A9-B282-B7255482EEC6@digitar.com> References: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD17@lsnexchange.limestonenetworks.com> <533370AD-B650-46A9-B282-B7255482EEC6@digitar.com> Message-ID: On Tue, 8 Dec 2009, Jason Williams wrote: > On Dec 8, 2009, at 11:42 AM, Ryan Gelobter wrote: > >> Any chance there's someone from Earthlink on nanog or anyone that has contact information? > > Their NOC has an unlisted number: +1 404-815-0770 x22277 Not anymore, it would seem. NANOG Archives FTW. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From gordslater at ieee.org Wed Dec 9 05:47:22 2009 From: gordslater at ieee.org (gordon b slater) Date: Wed, 09 Dec 2009 05:47:22 +0000 Subject: Linux shaping packet loss In-Reply-To: <20091209010747.GA20524@verge.net.au> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <20091209010747.GA20524@verge.net.au> Message-ID: <1260337642.20713.248.camel@ub-g-d2> Apologies to all on handheld devices. If you're not into BSD or Linux TC operationally, skip this post. Due to my usual rambling narrative style for "alternative" troubleshooting I was going to mail this direct to the OP but I was persuaded AMBJ by a co-conspirator to post this to list in full. # @all with similar "traffic shaping" problems Googling in the future: On Wed, 2009-12-09 at 12:07 +1100, Simon Horman wrote: > but trying to use much > more than 90% of the link capacity ......though not directly relevant in this case, for lower speed links and things like xDSL to the CPE that 90% must include protocol overheads (you are getting close to bone in that last 10%) and _much_ more affective (<- that's A-ffective) things like actual modem "sync speed". It depends how the TC is calc'ed/applied of course. Just a general note for a more CPE-oriented occurence of this. So kids, if you're struggling with your IPCOP in a SOHO shop with ADSL+PPPoE, this means you! #### Meanwhile, back at our level....... @all generally: do many of us use Linux TC at small-carrier level? I know of a lot of BSD boxen out there that handle huge complex flows but I suspect Linux kernel is less popular for this - or am I assuming wrong? Personally I'd lean to BSD for big stuff and Linux on for CPE, am I out of touch nowadays? #### Fully back on topic from here on....... @Chris - I've not used RED in any anger, sorry. Other than a typo in the config for the affected queue (maybe an extra digit loose somewhere?), things are definitely going to get complicated. Is something exceeding a tc bucket mtu occasionally? Chris wrote: > >My thoughts are that any dropped packets on the parent class is a bad >thing: yes, generally speaking, but..... > >qdisc htb 1: root r2q 10 default 265 direct_packets_stat 448 ver 3.17 > Sent 4652558768 bytes 5125175 pkt (dropped 819, overlimits 10048800 >requeues 0) > rate 0bit 0pps backlog 0b 28p requeues 0 ... in the above example, that loss rate is extremely low at 000.0159% ( 819 / 5125175 %) It may not be a representative sample, but I just thought I'd check you hadn't dropped a few significant digits in a %loss calc along the way :) That level of loss if operationally insignificant of course, especially for TCP. As you are I'm sure aware, perfect TC through any box is pretty specialist and usually unique to that placement. Without any graphical output, queues and the like are extremely difficult to visualize (mentally) under load (though for smaller boxes the RRD graphs in pfSENSE are nicely readable - see below). Because of this I usually try to eliminate ~everything~ else before I get into qdisks and the nitty-gritty. As a natural control fr/geek I've wasted far to many hours stuck in the buckets to no real improvement in many cases. Chris wrote: > I've isolated it to the egress HTB qdisc > good, though read on for a strange tale You MUST make a distinction between TC dropping the packets and the interface dropping the packets; I see in your later post a TC qdisc line showing that tc itself had dropped packets, BUT it ALWAYS pays to check at the same time (using ifconfig) that no packets are reported being dropped by the interfaces as well. I've had 2 or 3 occasions where `TC drops` were actually somehow linked to _interface_ drops and it really threw me, we never did work out why. The interaction confounded us totally. IF the INTERFACES are ALSO dropping in ifconfig, THEN, and ONLY then, you are into the lowest layer. So, with that in mind and the sheer complexity of possibilities, here's how I personally approach difficult BSD/Linux "TC problems". Note that I have zero experience or inclination towards Cisco TC: Kick the tyres! A lot of people mentioned layer 2 link-config problems, but as far as I can see, no-one has suggested quickly yanking the cables and blowing the dust off the the ends. Whenever I have to reach for a calculator or pen for a problem, I first swap out the interconnects to reduce the mental smoke ;) Next, I check the NICs to see if they're unseated (if applicable), or CPU (think: rogue process - use top) or even bus utililisation if you have only 32bit PCI NICs in a busy box. Next. does the box do anything else like Snort/Squid/etc at the same time? To eliminate wierdness and speedup troubleshooing if TC is acting strange I'd run tcpdump continually from the very start of my troubleshooting, dumping into small 10MB-ish files - use the special -C option ="split to filesize" and the -W option to set about 100 files in a ring buffer so that you have a decent history to go back through if you need it, without clogging the fisystem of the box with TB or packetdata :) (splitting them into 10MB files at the start leads to fast analysis in the shark, though you could carve up larger files manually I guess) That way, if the TC hurts your brain run the dumps them through wireshark's "expert info" filter while you have a coffee. (Analylse>ExpertInfo I think?) It's just in case something external or unusual is splattering the interfaces into confusion, it will only take a minute or less to run this analysis with an "affected" dump, as 10MB is very manageable and you can select the relevant dumpfile from it's last access time. Don't waste any time viewing them manually, just a glance. Remember to kill the tcpdumps when you find the problem though, scrubbing the files if needed for compliance etc. If you need to run tcpdump for a really long time I'd suggest setting it up with setuid because it usually needs to run as root. Personally I get nervous on important perimiter devices dumping during a coffeebreak ;) When I'm trying to get my head around flows through "foreign" Linux boxen I tend to use "iftop" for a couple of minutes or so to just get the feel of connections and throughputs actually travelling through it, I sometimes run it over SSH continually on another monitor when dealing with critical flow boxes that show problems. If you throw a config "switch" somewhere it's nice to see the effect visually, though be careful, it runs as root so again don't leave going 24/7, just while you are fiddling {cough} adjusting. Again, for longterm watching try to use as setuid. I set up a few iperf flows to stimulate your TC setups or use netcat, scp or similar to push some files through to /dev/null at the other end, use "trickle" to limit the flow rates to realistic or less operationally-damaging levels during testing. wfm. Adding 9 flows of about 10% of link capacity each should give tc some thinking work to do in an already active network, script it all to run for only a few seconds at a time in pulses, rather than saturating the operational link for an hour on end or the fone won't stop haha. If your queues are all port-based,(depends how you're feeding flows into the tc mechanism I suppose) set up "engineering test queues" on high ports and force iperf to use these high ports while you test inline. If the box isn't yet in service, this obviously isn't an issue. now, IF there are NO drops reported by ifconfig or kernel messages, just drops reported by the TC mechanism, it gets complicated. Only THEN do I reach for a calculator (and I also print out the relevant man pages!): But! There is one more rapid technique available you shouldn't ignore- Swapouts: --------- TC is hard to get perfect using any vendor, so eliminate the hardware and configs in one swoop if you can! If you feel like trying a swapout (not sure if `availability` will allow in this case) a modern mobo running pfSENSE will allow a quick "have I done something stupid on the Linux box?" comparison. I suggest pfSENSE because it has a reputation for fast throughput and {cringe} a "wizard" in the web GUI so you can have it set up a set of TC rules rapidly. I'd run it direct from the liveCD for a quick comparison, give it min. 256MB ram and a P4 or higher for G-eth speeds with shaping but no ipsec. (this is overkill, but you must eliminate doubt in this case) Allow 10 seconds to swap the interconnects once it's config-ed though, this could be more than you can allow for downtime? Dunno Another `swapout` option, but actually a same-box alternative, is setting up simple TC yourself manually using "tc" at the shell or a (better) a simple script instead of %whatever-you-are-using-right-now% (possibly a flat scripted config file for tc? or maybe some fancy custom web-thingy?) Flattening the tc config this way for an couple of hours can give a comparison though it all depends on the desired availability/quality and if good shaping is essential 24/7 on a saturated link. Luckily, you hint that your hardware is significantly better than i686 I think? If we knew more about the actual hardware and the flows through it + a little about the adjacent topology, we could all offer some hardware sizing comments in case you're pushing something over it's limit. Finally, I've seen more than a few examples of people using old P3-era hardware for heavy duty throughput. It can work well (especially with PCI-X) but NEVER assume that layer one ends at the RJ45. It goes inside the case and a significant distance sometimes: all prone to heat/dust/fluff/broken solder/physical alignment problems. In years gone by, mis-seated AGP cards would take ethernet links down then up again on hot days. In these roles, your old leaky PSU and mobo capacitors can lead you on a merry dance for a l-o-n-g time. Pained memories :) regards, Gord From bazy84 at gmail.com Wed Dec 9 06:02:12 2009 From: bazy84 at gmail.com (Bazy) Date: Wed, 9 Dec 2009 08:02:12 +0200 Subject: Linux shaping packet loss In-Reply-To: References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> Message-ID: <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> On Tue, Dec 8, 2009 at 5:14 PM, Chris wrote: > Thanks, Steiner and everyone for the input. It's good to see the list is > still as friendly as ever. > > There are two paths I'm trying to get my head round after someone offlist > helpfully suggested putting cburst and burst on all classes. > > My thoughts are that any dropped packets on the parent class is a bad thing: > > qdisc htb 1: root r2q 10 default 265 direct_packets_stat 448 ver 3.17 > ?Sent 4652558768 bytes 5125175 pkt (dropped 819, overlimits 10048800 > requeues 0) > ?rate 0bit 0pps backlog 0b 28p requeues 0 > > Until now I've had Rate and Ceil at the same values on all the classes but I > take the point about cburst and burst allowing greater levels of borrowing > so I've halved the Rate for all classes and left the Ceil the same. > > I've gone done this route mainly because I really can't risk breaking things > with incorrect cburst and burst values (if anyone can please tell me on an > i686 box at, say, 10Mbps the ideal values I can translate them into higher > classes, TC seems to work them out as 1600b/8 mpu by default and the timing > resolution confuses me.) > > Thanks again, > > Chris > > 2009/12/8 > >> > Won't say I'm an expert with TC, but anytime I see packet loss on an >> > interface I always check the interface itself...10% packet loss is >> > pretty much what you would get if there was a duplex problem. I always >> > try to hard set my interfaces on both the Linux machines and Switches. >> >> Used to set everything hard five years ago. Nowadays auto works just >> fine most of the time. >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no >> >> > Hi Chris, Try setting txqueuelen to 1000 on the interfaces and see if you still get a lot of packet loss. Bazy From gordslater at ieee.org Wed Dec 9 06:38:31 2009 From: gordslater at ieee.org (gordon b slater) Date: Wed, 09 Dec 2009 06:38:31 +0000 Subject: Linux shaping packet loss In-Reply-To: <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> Message-ID: <1260340711.20713.261.camel@ub-g-d2> On Wed, 2009-12-09 at 08:02 +0200, Bazy wrote: > Hi Chris, > > Try setting txqueuelen to 1000 on the interfaces and see if you still > get a lot of packet loss. > Yes, good point and well worth a try. Rereading Chris's post about "250Mbps" and "forty queues", the "egress" could well be bumping the end of a default fifo line. If 1000 is too high for your kit try pushing it upwards gradually from the default of 100 (?) but back off if you get drops or strangeness in ifconfig output on the egress i/f. I append grep-ped ifconfig outputs into a file every hour on a cron job until I'm happy that strangeness doesn't happen, they never do when you're watching sadly. TC problems aren't always about the TC itself, the physical interfaces are inherently part of the "system", as my long rambling 5am+ up-all-night-over-ssh post about reseating NICs was trying to hint at. Nice one Bazy Gord From gordslater at ieee.org Wed Dec 9 07:05:15 2009 From: gordslater at ieee.org (gordon b slater) Date: Wed, 09 Dec 2009 07:05:15 +0000 Subject: Linux shaping packet loss In-Reply-To: <1260340711.20713.261.camel@ub-g-d2> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> <1260340711.20713.261.camel@ub-g-d2> Message-ID: <1260342315.20713.263.camel@ub-g-d2> On Wed, 2009-12-09 at 06:38 +0000, gordon b slater wrote: > If 1000 is too high for your kit try pushing it upwards gradually from > the default of 100 meh! 6am+insomniac blues for a Gigeth it's more likely to be 1000 already, so push it up to 10000 in stages - you get the idea. From nikky at mnet.bg Wed Dec 9 07:18:17 2009 From: nikky at mnet.bg (Nickola Kolev) Date: Wed, 9 Dec 2009 09:18:17 +0200 Subject: Linux shaping packet loss In-Reply-To: <1260340711.20713.261.camel@ub-g-d2> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> <1260340711.20713.261.camel@ub-g-d2> Message-ID: <20091209091817.44a72d8a.nikky@mnet.bg> ?? Wed, 09 Dec 2009 06:38:31 +0000 gordon b slater ??????: > On Wed, 2009-12-09 at 08:02 +0200, Bazy wrote: > > > Hi Chris, > > > > Try setting txqueuelen to 1000 on the interfaces and see if you > > still get a lot of packet loss. > > > > Yes, good point and well worth a try. Rereading Chris's post about > "250Mbps" and "forty queues", the "egress" could well be bumping the > end of a default fifo line. > > If 1000 is too high for your kit try pushing it upwards gradually from > the default of 100 (?) but back off if you get drops or strangeness in > ifconfig output on the egress i/f. The default *is* 1000. From the ifconfig man page: txqueuelen length Set the length of the transmit queue of the device. It is useful to set this to small values for slower devices with a high atency (modem links, ISDN) to prevent fast bulk transfers from disturbing interactive traffic like telnet too much. So, if you should touch it if and only if you want to have (supposedly) finer grained control on queueing, as the hardware device also does some reordering before it puts the data on the wire. > I append grep-ped ifconfig outputs into a file every hour on a cron > job until I'm happy that strangeness doesn't happen, they never do > when you're watching sadly. > > TC problems aren't always about the TC itself, the physical interfaces > are inherently part of the "system", as my long rambling 5am+ > up-all-night-over-ssh post about reseating NICs was trying to hint > at. > > Nice one Bazy > > Gord > > > > > -- Regards, Nickola From lists at quux.de Wed Dec 9 09:26:34 2009 From: lists at quux.de (Jens Link) Date: Wed, 09 Dec 2009 10:26:34 +0100 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> (Owen DeLong's message of "Tue\, 8 Dec 2009 11\:00\:33 -0800") References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> Message-ID: <87ws0wcxbp.fsf@laphroiag.quux.de> Owen DeLong writes: > I expect my connections to my mail server to actually reach my mail > server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just > works" settings in question break these things badly. One of my customers has an appliance for his WLAN guest access access which filters out AAAA records. :-( jens at bowmore:~$ dig AAAA www.quux.de @8.8.8.8 +short jens at bowmore:~$ Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From smb at cs.columbia.edu Wed Dec 9 12:02:19 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 9 Dec 2009 07:02:19 -0500 Subject: "Cool" ISPs Message-ID: <94EE2416-CDAC-4B96-8A75-051F96D1EF95@cs.columbia.edu> Some folks on this list may be interested in Ars Technica's take on "cool" ISPs: http://arstechnica.com/tech-policy/news/2009/12/the-coolest-isp-in-the-world.ars (note: I neither endorse nor condemn any of the ideas, ISPs, etc. In other words, don't blame me if you disagree...) --Steve Bellovin, http://www.cs.columbia.edu/~smb From bbillon-ml at splio.fr Wed Dec 9 13:15:48 2009 From: bbillon-ml at splio.fr (Benjamin BILLON) Date: Wed, 09 Dec 2009 14:15:48 +0100 Subject: "Cool" ISPs In-Reply-To: <94EE2416-CDAC-4B96-8A75-051F96D1EF95@cs.columbia.edu> References: <94EE2416-CDAC-4B96-8A75-051F96D1EF95@cs.columbia.edu> Message-ID: <4B1FA304.3050900@splio.fr> Cocorico! Another way to measure coolness of ISPs is to check how they're engaged with common people. Several Free.fr managers (including Xavier Niel and Rani Assaf) participate personally on the FRnOG mailing-list (in addition to Free.fr newsgroups). Some SFR employees also read FRnOG. None of Orange AFAIK. Steven Bellovin a ?crit : > Some folks on this list may be interested in Ars Technica's take on "cool" ISPs: http://arstechnica.com/tech-policy/news/2009/12/the-coolest-isp-in-the-world.ars (note: I neither endorse nor condemn any of the ideas, ISPs, etc. In other words, don't blame me if you disagree...) > > --Steve Bellovin, http://www.cs.columbia.edu/~smb From owen at delong.com Wed Dec 9 14:30:45 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Dec 2009 06:30:45 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <87ws0wcxbp.fsf@laphroiag.quux.de> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> <87ws0wcxbp.fsf@laphroiag.quux.de> Message-ID: <38C765FC-EB06-4972-BB74-EBD91AD6A267@delong.com> On Dec 9, 2009, at 1:26 AM, Jens Link wrote: > Owen DeLong writes: > >> I expect my connections to my mail server to actually reach my mail >> server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just >> works" settings in question break these things badly. > > One of my customers has an appliance for his WLAN guest access access > which filters out AAAA records. :-( > > jens at bowmore:~$ dig AAAA www.quux.de @8.8.8.8 +short > jens at bowmore:~$ > Wow... Yeah, that would definitely result in a lengthy conversation between their tech. support department and me. The ones that are even worse, though, are the ones that pass through AAAA and do RA/SLAAC advertisements, but, don't provide IPv6 connectivity. Oh, and, I stayed at one place that didn't pass TCP/53, so, they broke things like Blizzard authentication. Owen From sven at cyberbunker.com Wed Dec 9 15:18:47 2009 From: sven at cyberbunker.com (Sven Olaf Kamphuis) Date: Wed, 9 Dec 2009 15:18:47 +0000 (GMT) Subject: Arrogant RBL list maintainers Message-ID: Hi NANOG readers, We've noticed that Trend Micro "mail-abuse.com" just "assumes" ips are dynamic by default, adds them to their stupid list, and then expects US to update -their- database -for them- for free to get them off their stupid list again. (as ofcourse our customers bug us when their email doesn't arrive on the other side, hell they even tell the customers to bug -us- ;) because they just assume that working, rfc compliant, reverse dns that just-so-happens to be automatically generated would indicate dynamic ip space.. (or actually because they think using customer-pressure is a good way to get isps to maintain their product (their database) for them for free). we've basically told them to go to hell and we advise everyone who uses their RBL lists to remove their RBLs from their configs, as what we have here is a mismanaged list. as ofcourse we neither intend to change our perfectly fine "aXXX-XXX-XXX-XXX.cb3rob.net." reverse dns scheme, nor maintain their database for free for them.. they've probably done the same with other isps that use simular schemes. just to let everyone know... ---------- Forwarded message ---------- Date: Wed, 9 Dec 2009 12:07:50 GMT From: Adelaide Santos via RT To: sven at cb3rob.net Cc: sales at cb3rob.net Subject: [MAPS #322153] Re: WWW remove for 84.22.XX.XX Hello, Thank you for this information. The DUL list is simply a listing of IP blocks which use dynamic IP assignment, and are prohibited (usually by AUP/TOS) from running servers. Many ISP's voluntarily participate in the DUL by providing us with their blocks of dynamically-assigned IP's. ISPs benefit from participating in the DUL because the amount of spam and abusive IP traffic originating from their IP space is reduced, which also reduces the amount of abuse complaints received. We benefit because of increased communications and cooperation with the ISPs makes our lists that much more accurate. Everyone benefits because the DUL helps stop spam. See also "Addition due to ISP Participation": http://mail-abuse.com/support/nominats_dul.html Currently, you are using a generic naming convention that does not show any indication of being static. If this space is indeed static, then all rDNS must reference to static in the rDNS. Here is an example of a generic naming convention: 84.22.XX.0 (a84-22-XX-0.cb3rob.net) 84.22.XX.1 (a84-22-XX-1.cb3rob.net) <...> Here is what you can do: 84.22.XX.0 (a84-22-XX-0.fixed.cb3rob.net) 84.22.XX.1 (customer.cb3rob.net) 84.22.XX.2 (a84-22-XX-2.fixed.cb3rob.net) 84.22.XX.3 (mail.cb3rob.net) 84.22.XX.4 (a84-22-XX-4.fixed.cb3rob.net) <...> Here are the naming conventions that we uses to decide if an IP or CIDRs is static or dynamic. Typical static rDNS terms: bus, biz, colo, ded, fix, mta, perm, server, smtp, static, wsip. Typical dynamic rDNS terms: adsl, cable, dhcp, dialup, dsl, dyn, home, isdn, modem, pool, ppp, or res. Trend Micro supports the Messaging Anti-Abuse Working Group (MAAWG) Best Practices for Dynamic Address Sharing. Please review the Best Practices document (available at http://www.maawg.org/about/publishedDocuments/MAAWG_Dynamic_Space_2008-06.pdf). We need to see these changes before we can proceed with the removal. If changing the rDNS is not possible, we suggest that you add a statement in the WHOIS information stating that this space is statically assigned. Thank you, Adelaide Santos DUL Investigator Trend Micro Email Reputation Services http://www.mail-abuse.com/ [sven at cb3rob.net - 2009-12-08 13:23:03 +0000]: > hi "dul". > > none of our ips are "dynamic", as we simply don't do access networks, > as those are lame and don't make money. > > this includes: > > 84.22.96.0/19 > 205.189.71.0/24 > 205.189.72.0/23 > 91.209.12.0/24 > > all of which originate from AS34109 and none of which are "dynamic" > > furthermore, i really don't see why -we- should spend time and effort on a > problem thats initiated on -your- end by your action of > > 1: incorrectly adding our ips to your list, thereby obviously causing > problems for our customers > > 2: getting our customers to get us to bug you about it instead of just > solving it with our customers directly, and therefore not forcing > us to wasting our time with it. > > we generally do not interfere in 'third party' problems, and this clearly > qualifies as one (together with dmca crap, arrogant irc networks, etc) you > name it, we don't go and sit in the middle, just solve it with the > customers!). > > as the problem is as follows: you put ips on some list therefore our > customer cannot mail, exactly WHY should we spend manhours (and therefore > money) to fix a problem YOU created... > > as i'm damn sure we never put any of our ips on some "dynamic pool" list. > > it's probably just your software thinking "oh automatically generated > reverse dns" (which in our case takes the form of > a84-22-xx-xx.cb3rob.net. as it's RFC complient and we cannot be fucked to > make up host names for each and every one of our many 10000 of ips in our > many isp companies worldwide, and doesn't imply "dynamic" lameness AT ALL. > > thats just your software being all buggy and shit. > > (why oh why does half the world expect isps to solve things for them for > free... when they are not even our customer.. ;) -- Sven Olaf Kamphuis CB3ROB Ltd. & Co. KG DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. From scott at doc.net.au Wed Dec 9 15:22:50 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 9 Dec 2009 07:22:50 -0800 Subject: AT&T blocking individual IP addresses Message-ID: As of about an hour ago AT&T appear to have started blocking access to a few of our IP addresses. This is being done at a /32 level, and the IP addresses above and below are still allowed through. Has anyone seen them do this before, or know who I need to contact to get it fixed? AT&T won't talk to me as I'm not a customer... Traceroute to the blocked IPs from AT&T all end at : 5 cr2.phlpa.ip.att.net (12.122.3.226) [MPLS: Labels 20559/17406 Exp 0] 116 msec 20 msec 20 msec 6 cr2.cl2oh.ip.att.net (12.122.2.209) [MPLS: Labels 20527/17406 Exp 0] 24 msec 20 msec 20 msec 7 cr1.cl2oh.ip.att.net (12.122.2.125) [MPLS: Labels 0/17406 Exp 0] 24 msec 20 msec 20 msec 8 cr82.dtrmi.ip.att.net (12.123.139.154) [MPLS: Label 16623 Exp 0] 24 msec 20 msec 20 msec 9 gar4.dtrmi.ip.att.net (12.122.102.89) 20 msec 20 msec 20 msec 10 12.87.238.238 [AS 7018] 24 msec 20 msec 24 msec 11 12.87.238.237 [AS 7018] !A * * Traceroute to the neighboring IP addresses don't go anywhere near the above path, so it's apparently a blackhole of sorts. Scott. From rdobbins at arbor.net Wed Dec 9 15:25:58 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 9 Dec 2009 15:25:58 +0000 Subject: AT&T blocking individual IP addresses In-Reply-To: References: Message-ID: <6065F302-7CA0-4CB7-A26C-41C41BE760E1@arbor.net> On Dec 9, 2009, at 10:22 PM, Scott Howard wrote: > Traceroute to the neighboring IP addresses don't go anywhere near the above path, so it's apparently a blackhole of sorts. Are they bots or C&C servers, or open DNS recursors? ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From scott at doc.net.au Wed Dec 9 16:03:01 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 9 Dec 2009 08:03:01 -0800 Subject: AT&T blocking individual IP addresses In-Reply-To: <6065F302-7CA0-4CB7-A26C-41C41BE760E1@arbor.net> References: <6065F302-7CA0-4CB7-A26C-41C41BE760E1@arbor.net> Message-ID: On Wed, Dec 9, 2009 at 7:25 AM, Dobbins, Roland wrote: > > Traceroute to the neighboring IP addresses don't go anywhere near the > above path, so it's apparently a blackhole of sorts. > > Are they bots or C&C servers, or open DNS recursors? > They are (authenticated-required) proxy servers with 10's of thousands of users behind them, so it's possible that they were seeing some bot-like traffic from them, although the volume would have been tiny compared to the volume of legitimate traffic. Scott. From rdobbins at arbor.net Wed Dec 9 16:05:08 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 9 Dec 2009 16:05:08 +0000 Subject: AT&T blocking individual IP addresses In-Reply-To: References: <6065F302-7CA0-4CB7-A26C-41C41BE760E1@arbor.net> Message-ID: <0E407EEE-15AB-4F6E-8452-99B770293970@arbor.net> On Dec 9, 2009, at 11:03 PM, Scott Howard wrote: > They are (authenticated-required) proxy servers with 10's of thousands of users behind them, so it's possible that they were seeing some bot-like traffic from them, although the volume would have been tiny compared to the volume of legitimate traffic. So, if, say, AT&T customers are getting zorched from traffic behind those proxies, then blocking them would make sense, no? ;> Do you have visibility into the traffic into/out of those proxies, in order to determine if there's DDoS or spam or other undesirable traffic emanating from them? ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From r.gelobter at limestonenetworks.com Wed Dec 9 16:56:04 2009 From: r.gelobter at limestonenetworks.com (Ryan Gelobter) Date: Wed, 9 Dec 2009 10:56:04 -0600 Subject: Earthlink SMTP Admin Contact? In-Reply-To: References: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD17@lsnexchange.limestonenetworks.com> <533370AD-B650-46A9-B282-B7255482EEC6@digitar.com> Message-ID: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD91@lsnexchange.limestonenetworks.com> Thanks for the number, but their NOC was unable to help me. They referred me back to their Abuse Mailbox and abuse e-mail addresses (blockedbyearthlink at abuse.earthlink.net, abuse at abuse.earthlink.net). They were unable to provide any alternative number or e-mail address. I ended up calling their corporate office (404.815.0770) and spoke to an operator who confirmed with senior tech's that the abuse team their checks the mailbox but they apparently are not in the office and work from home. Senior tech support tells me the mail server is not blocked even though I get blocked messages and escalating it further would not do anything as they show it as not blocked. Tech support uses the same procedure as the mail administrator does which is to e-mail blockedbyearthlink@ address with the subject BLOCKED: xxx.xxx.xxx.xxx (replace with the ip) and if it is blocked they will unblock you. Sadly, I tried that already. Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelobter at limestonenetworks.com www.limestonenetworks.com Simple.? Solid.? Superior. -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Tuesday, December 08, 2009 10:28 PM To: Jason Williams Cc: Ryan Gelobter; nanog at nanog.org Subject: Re: Earthlink SMTP Admin Contact? On Tue, 8 Dec 2009, Jason Williams wrote: > On Dec 8, 2009, at 11:42 AM, Ryan Gelobter wrote: > >> Any chance there's someone from Earthlink on nanog or anyone that has contact information? > > Their NOC has an unlisted number: +1 404-815-0770 x22277 Not anymore, it would seem. NANOG Archives FTW. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From herrin-nanog at dirtside.com Wed Dec 9 16:57:29 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 9 Dec 2009 11:57:29 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: References: Message-ID: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> On Wed, Dec 9, 2009 at 10:18 AM, Sven Olaf Kamphuis wrote: > We've noticed that Trend Micro "mail-abuse.com" just "assumes" ips are > dynamic by default, > > because they just assume that working, rfc compliant, reverse dns that > just-so-happens to be automatically generated would indicate dynamic ip > space. Sven, Which is it? By default or because it looks automatically generated? By default would seem to be a problem. Automatically generated, not so much. If you haven't made the effort to set up and secure a mail server then you shouldn't be talking smtp to the hosts mail-abuse.com is used to protect. If you haven't bothered to set the reverse DNS to match your server's name then you haven't made the effort, at least not with a modicum of competence. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ops.lists at gmail.com Wed Dec 9 17:05:52 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 9 Dec 2009 22:35:52 +0530 Subject: Earthlink SMTP Admin Contact? In-Reply-To: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD91@lsnexchange.limestonenetworks.com> References: <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD17@lsnexchange.limestonenetworks.com> <533370AD-B650-46A9-B282-B7255482EEC6@digitar.com> <216636937ABE004E8CD94DDB2AD8BAA5017E99D5CD91@lsnexchange.limestonenetworks.com> Message-ID: Is the IP space anywhere near these - http://www.spamhaus.org/sbl/listings.lasso?isp=limestonenetworks.com Found 7 SBL listings for IPs under the responsibility of limestonenetworks.com SBL82484 69.162.119.163/32 limestonenetworks.com 03-Dec-2009 18:14 GMT BOA phish site SBL81933 74.63.211.0/24 limestonenetworks.com 25-Nov-2009 01:23 GMT Snowshoe spam range ("Dynabucks") SBL81769 69.162.115.157/32 limestonenetworks.com 22-Nov-2009 21:54 GMT Spammed malware sites on fast-flux hacked systems SBL81707 216.245.216.64/27 limestonenetworks.com 21-Nov-2009 16:24 GMT MMF snowshoe spam SBL81125 216.245.222.192/26 limestonenetworks.com 10-Nov-2009 14:00 GMT Suspected Snowshoe Spam Range SBL78721 69.162.68.160/29 limestonenetworks.com 17-Sep-2009 08:03 GMT emailmkt.org SBL78720 216.245.204.32/27 limestonenetworks.com 17-Sep-2009 08:01 GMT emailmkt.org On Wed, Dec 9, 2009 at 10:26 PM, Ryan Gelobter wrote: > Thanks for the number, but their NOC was unable to help me. They referred me back to their Abuse Mailbox and abuse e-mail addresses (blockedbyearthlink at abuse.earthlink.net, abuse at abuse.earthlink.net). They were unable to provide any alternative number or e-mail address. I ended up calling their corporate office (404.815.0770) and spoke to an operator who confirmed with senior tech's that the abuse team their checks the mailbox but they apparently are not in the office and work from home. Senior tech support tells me the mail server is not blocked even though I get blocked messages and escalating it further would not do anything as they show it as not blocked. > > Tech support uses the same procedure as the mail administrator does which is to e-mail blockedbyearthlink@ address with the subject BLOCKED: xxx.xxx.xxx.xxx (replace with the ip) and if it is blocked they will unblock you. Sadly, I tried that already. -- Suresh Ramasubramanian (ops.lists at gmail.com) From mikelieman at gmail.com Wed Dec 9 17:11:29 2009 From: mikelieman at gmail.com (Mike Lieman) Date: Wed, 9 Dec 2009 12:11:29 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> References: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> Message-ID: <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses? I can understanding keeping rDNS in sync, but that's not the issue here, is it? On Wed, Dec 9, 2009 at 11:57 AM, William Herrin wrote: > On Wed, Dec 9, 2009 at 10:18 AM, Sven Olaf Kamphuis > wrote: > > We've noticed that Trend Micro "mail-abuse.com" just "assumes" ips are > > dynamic by default, > > > > because they just assume that working, rfc compliant, reverse dns that > > just-so-happens to be automatically generated would indicate dynamic ip > > space. > > Sven, > > Which is it? By default or because it looks automatically generated? > > By default would seem to be a problem. Automatically generated, not so > much. > > If you haven't made the effort to set up and secure a mail server then > you shouldn't be talking smtp to the hosts mail-abuse.com is used to > protect. If you haven't bothered to set the reverse DNS to match your > server's name then you haven't made the effort, at least not with a > modicum of competence. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From bmanning at vacation.karoshi.com Wed Dec 9 17:11:53 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 9 Dec 2009 17:11:53 +0000 Subject: Breaking the internet (hotels, guestnet style) - path asumption In-Reply-To: <38C765FC-EB06-4972-BB74-EBD91AD6A267@delong.com> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> <87ws0wcxbp.fsf@laphroiag.quux.de> <38C765FC-EB06-4972-BB74-EBD91AD6A267@delong.com> Message-ID: <20091209171153.GA1716@vacation.karoshi.com.> On Wed, Dec 09, 2009 at 06:30:45AM -0800, Owen DeLong wrote: > > On Dec 9, 2009, at 1:26 AM, Jens Link wrote: > > > Owen DeLong writes: > > > >> I expect my connections to my mail server to actually reach my mail > >> server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just > >> works" settings in question break these things badly. > > > > One of my customers has an appliance for his WLAN guest access access > > which filters out AAAA records. :-( > > > > jens at bowmore:~$ dig AAAA www.quux.de @8.8.8.8 +short > > jens at bowmore:~$ > > > Wow... Yeah, that would definitely result in a lengthy conversation between > their tech. support department and me. > > The ones that are even worse, though, are the ones that pass through AAAA > and do RA/SLAAC advertisements, but, don't provide IPv6 connectivity. > > Owen > why do you presume the DNS service is in the same path as the TLS/SSL? a loose reading of these posts might give the gullible the impression that the IP datagrams between the source and the target pass through the DNS server... which we -KNOW- is false. --bill From doon.bulk at inoc.net Wed Dec 9 17:22:14 2009 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Wed, 9 Dec 2009 12:22:14 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> References: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> Message-ID: <42184085-127E-4968-A3F9-A5755E773FAB@inoc.net> On Dec 9, 2009, at 12:11 PM, Mike Lieman wrote: > Is there an RFC detailing that specific text strings must be used for static > v. dynamic addresses? > Well there is this draft Document, FWIW, http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Which contains suggestions.. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Please send all spam to my main address, root at localhost From sethm at rollernet.us Wed Dec 9 17:24:32 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 09 Dec 2009 09:24:32 -0800 Subject: Arrogant RBL list maintainers In-Reply-To: <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> References: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> Message-ID: <4B1FDD50.6070900@rollernet.us> Mike Lieman wrote: > Is there an RFC detailing that specific text strings must be used for static > v. dynamic addresses? > > I can understanding keeping rDNS in sync, but that's not the issue here, is > it? > There is no RFC that I'm aware of, but I'd say it's pretty common for PTR records that contain the IP address itself to be regarded as dynamic or mass generated. Both of those qualities can indicate the source is not serious about running a mail server. If one chooses this DNS scheme for their mail servers they're playing with fire. ~Seth From paul.w.bennett at gmail.com Wed Dec 9 17:26:35 2009 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Wed, 09 Dec 2009 12:26:35 -0500 Subject: AT&T blocking individual IP addresses In-Reply-To: References: Message-ID: On Wed, 09 Dec 2009 10:22:50 -0500, Scott Howard wrote: > As of about an hour ago AT&T appear to have started blocking access to a > few of our IP addresses. > AT&T won't talk to me as I'm not a customer... So, wait, are they your addresses or not? -- Paul From jlewis at lewis.org Wed Dec 9 17:29:54 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 9 Dec 2009 12:29:54 -0500 (EST) Subject: Arrogant RBL list maintainers In-Reply-To: <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> References: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> <43661d390912090911h55591d94tc6b1091d4cd7bfa3@mail.gmail.com> Message-ID: On Wed, 9 Dec 2009, Mike Lieman wrote: > Is there an RFC detailing that specific text strings must be used for static > v. dynamic addresses? There's this expired draft http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt But really, the rdns should just clearly indicate the use of the IPs if you're going to do generic/script generated rDNS. a84-22-96-117.cb3rob.net doesn't tell me anything except that this IP is part of a large block of generic rDNS. Something like a84-22-96-117.static.cb3rob.net at least indicates that the IPs are static, while a84-22-96-117.dynamic.cb3rob.net clearly indicates the space is dynamic. Doing this takes much of the guesswork out of it when others on the net need to decide "should we accept mail from this IP?" Keeping the indicator as close as possible to the domain helps out for things that do simple string matching. i.e. with a84-22-96-117.dynamic.cb3rob.net, it's a safe bet I don't want mail from *.dynamic.cb3rob.net. That's easier to block (with a single rule) than dynamic.a84-22-96-117.cb3rob.net. Still, if you're serious about getting mail from that IP delivered, its far better to have the PTR = the domain or system name than some generic string roughly equivalent to all the neighboring IP PTRs. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Wed Dec 9 17:33:25 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Dec 2009 12:33:25 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> References: <3c3e3fca0912090857w1444c8c1ue4b3360445ba6eef@mail.gmail.com> Message-ID: <75cb24520912090933v20cb4d89v1bb1f375bdb47f60@mail.gmail.com> On Wed, Dec 9, 2009 at 11:57 AM, William Herrin wrote: > If you haven't made the effort to set up and secure a mail server then perhaps his ISP does something dumb (like verizon does) and only delegates to one server, which may/may-not be available at the time of the incident? (or is blocked/down/something-else from the observation point) btw: why won't verizon (fios/dsl folk I mean) delegate to more than 1 customer DNS server?? -Chris From morrowc.lists at gmail.com Wed Dec 9 17:34:05 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Dec 2009 12:34:05 -0500 Subject: Breaking the internet (hotels, guestnet style) - path asumption In-Reply-To: <20091209171153.GA1716@vacation.karoshi.com.> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> <87ws0wcxbp.fsf@laphroiag.quux.de> <38C765FC-EB06-4972-BB74-EBD91AD6A267@delong.com> <20091209171153.GA1716@vacation.karoshi.com.> Message-ID: <75cb24520912090934i58a8980l87cff7e3e609b708@mail.gmail.com> On Wed, Dec 9, 2009 at 12:11 PM, wrote: > ? ? ? ?that the IP datagrams between the source and the target pass through > ? ? ? ?the DNS server... which we -KNOW- is false. dns-tunnel From jcurran at arin.net Wed Dec 9 17:51:09 2009 From: jcurran at arin.net (John Curran) Date: Wed, 9 Dec 2009 12:51:09 -0500 Subject: Followup regarding Joint Statement on ASN Assignment Discrepancies In-Reply-To: References: Message-ID: ARIN would like to report that it has worked with all its customers who received ASNs from the AS1707-AS1726 range and has provided them with replacement ASNs. Additionally, ARIN is now checking the other RIR databases and global routing tables just prior to issuance of any number resources (ASNs or IP address blocks) to ensure that there are no conflicts in issued resources. FYI, /John John Curran President and CEO ARIN On Nov 26, 2009, at 11:31 AM, John Curran wrote: > ARIN and the RIPE NCC have worked together to research the issues with > the Autonomous System Number (ASN) range AS1707-AS1726. Below is our > analysis of what happened and a plan to resolve these issues. > > It appears that prior to 1993, Renater was issued AS1707 with an AS > name of "ASNBLOCKA". This is the name format used to assign a block > of ASNs, but the DDN NIC (the Defense Data Network Network Information > Center, which was responsible for ASN assignments until 1993) recorded > only a single assignment of AS1707, rather than the entire block of 20 > ASNs (AS1707-AS1726), as would have been expected. AS1712 was never > registered in the DDN NIC database. > > Since the proper registration was never recorded, this mistake carried > over from the InterNIC database into ARIN's database at ARIN?s inception > in 1997. The ASN range was not transferred to the RIPE NCC along with > AS1707 because AS1708-AS1726 appeared to be unassigned, and thus > remained with ARIN. > > Because this is simply an error in registry data and Renater is the > actual registrant of this entire range of ASNs (AS1707-AS1726), ARIN > will work with its customers who received ASNs from this range in July > and August of 2009 to provide them with replacement ASNs. While we > understand that this may cause some difficulty for these customers, we > feel that this is the best path forward given the circumstances. > > RIPE NCC and ARIN will update their respective databases and work with > the IANA to ensure that the ASN registry data is properly updated for > this range. > > To prevent future issues, ARIN and RIPE NCC will implement two new > processes for issuing new ASNs: checking all other RIR databases to > ensure that the ASN is not previously registered, and checking BGP > routing tables to ensure the ASN is not already found in an announced > AS-path. ASNs that fail either of these conditions will not be issued > until the discrepancy has been addressed. > > Regards, > John Curran, President and CEO, ARIN > Axek Pawlik, Managing Director, RIPE NCC > From michael.holstein at csuohio.edu Wed Dec 9 18:09:39 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 09 Dec 2009 13:09:39 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: References: Message-ID: <4B1FE7E3.6000600@csuohio.edu> > we've basically told them to go to hell and we advise everyone who uses > their RBL lists to remove their RBLs from their configs, as what we have > here is a mismanaged list. > Same thing we told them (snippit of my response below). Cheers, Michael Holstein Cleveland State University > [Trend] : But we will maintain our list as we see appropriate to > protect our customer from spam. > Suit yourself .. but you can't arbitrarily force the Internet as a whole to adopt an unwritten standard just to make your lives easier. If we encounter problems with our end-users and not being able to deliver email reliably to one of your customers, we'll have them call you, since we're complying with all the various SPAM prevention standards that presently exist. We hate SPAM as much as the next guy, but we're not going to install "Bob's SPAM module" anymore than we're going to do some custom DNS foolishness for Trend. From scott at doc.net.au Wed Dec 9 18:40:22 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 9 Dec 2009 10:40:22 -0800 Subject: AT&T blocking individual IP addresses In-Reply-To: References: Message-ID: On Wed, Dec 9, 2009 at 9:26 AM, Paul Bennett wrote: > On Wed, 09 Dec 2009 10:22:50 -0500, Scott Howard wrote: > > As of about an hour ago AT&T appear to have started blocking access to a >> few of our IP addresses. >> > > AT&T won't talk to me as I'm not a customer... >> > > So, wait, are they your addresses or not? > They are our non-AT&T addresses, and AT&T was blocking access to them from their network, so any of our customers on AT&T were unable to access our systems. AT&T has now resolved the problem, claiming that it was a "provisioning error"... Thanks, Scott. From stephen at sprunk.org Wed Dec 9 18:41:54 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 09 Dec 2009 12:41:54 -0600 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <87ws0wcxbp.fsf@laphroiag.quux.de> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> <87ws0wcxbp.fsf@laphroiag.quux.de> Message-ID: <4B1FEF72.30505@sprunk.org> Jens Link wrote: > Owen DeLong writes: > >> I expect my connections to my mail server to actually reach my mail server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just works" settings in question break these things badly. >> > > One of my customers has an appliance for his WLAN guest access access > which filters out AAAA records. :-( > > jens at bowmore:~$ dig AAAA www.quux.de @8.8.8.8 +short > jens at bowmore:~$ > That, unfortunately, is not uncommon. Actually, it's one of the _less_ broken systems I've seen, since IPv4 presumably keeps working. One major vendor of hotel guestnet equipment returns an A record for 0.0.0.1 if you do an ANY or AAAA query for any hostname--even ones that don't exist. At least with WinXP, you have to disable IPv6 just to get IPv4 to work! Worse, their tech support sees nothing wrong with this; if you disagree, all they'll do is offer a refund. Unfortunately, "take your money elsewhere" doesn't work when you've already paid for the hotel room--and they know it. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From sethm at rollernet.us Wed Dec 9 19:23:31 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 09 Dec 2009 11:23:31 -0800 Subject: Arrogant RBL list maintainers In-Reply-To: <4B1FE7E3.6000600@csuohio.edu> References: <4B1FE7E3.6000600@csuohio.edu> Message-ID: <4B1FF933.8030200@rollernet.us> Michael Holstein wrote: > > Suit yourself .. but you can't arbitrarily force the Internet as a whole > to adopt an unwritten standard just to make your lives easier. If we > encounter problems with our end-users and not being able to deliver > email reliably to one of your customers, we'll have them call you, since > we're complying with all the various SPAM prevention standards that > presently exist. > One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what. ~Seth From Henk.Steenman at ams-ix.net Wed Dec 9 19:41:01 2009 From: Henk.Steenman at ams-ix.net (Henk Steenman) Date: Wed, 9 Dec 2009 20:41:01 +0100 Subject: Leaving public peering? In-Reply-To: <2CCD1680-B5AE-4777-902F-CCA19BBAF782@ianai.net> References: <20091202212020.GA48616@ussenterprise.ufp.org> <1259790509.31045.144.camel@wks02.probe-networks.de> <2CCD1680-B5AE-4777-902F-CCA19BBAF782@ianai.net> Message-ID: <27E291D3-B42A-4CFD-A9C6-9E7ACB49C97F@ams-ix.net> On Dec 3, 2009, at 1:00 AM, Patrick W. Gilmore wrote: > On Dec 2, 2009, at 4:48 PM, Jonas Frey wrote: > >> the DE-CIX pricing is now 500 Euro/month...since 1st october...see end >> of that page. >> Both DE-CIX and AMS-IX have decreased their pricing this year..almost at >> the same time. I guess this is a move to stop company leaving public >> exchanges...i have seen this trend, too. > > That is not why LINX lowers its prices. (I cannot say why AMS-IX lowers its prices.) > > LINX is a member-based organization. The member _own_ the exchange. They are paying themselves, and they only pay themselves as much as it costs to run the exchange. With more members, more scale, and advances in equipment, unit (i.e. port) costs go down. > > In a cost-recovery model, that means prices drop. For exactly the same reason AMS-IX lowered its prices. - Henk > > LINX dropped prices mid-year 2009, and are dropping prices again in January 2009. AMS-IX dropped prices once in that time. DE-CIX actually raised its prices for many members, so they could lower their prices for others. Interesting strategy.... > > -- > TTFN, > patrick > > >> On Wed, 2009-12-02 at 22:20, Leo Bicknell wrote: >>> In a message written on Wed, Dec 02, 2009 at 12:46:46PM -0800, Lasher, Donn wrote: >>>> I realized that paid transit is down at almost obscene levels, but is >>>> that enough of a reason to increase hop-count, latencies, etc? >>>> >>>> Why disconnect from public mostly-free peering? >>> >>> Let's look at some economics. I'm going to pick on some folks here, >>> solely because they have prices online and because they are, I feel, >>> representative prices. >>> >>> http://www.cogentco.com/us/ >>> >>> "Home of the $4 Megabit!" So we have transit prices at $4 per megabit. >>> >>> http://www.de-cix.net/content/services/public-peering.html >>> >>> A 1GE link to the exchange is 1000 euro per month, which is $1505 USD at >>> the moment, let's call it $1500 for round numbers. >>> >>> Now, your 1GE exchange port really shouldn't be run past 60% or so, if >>> you want to provide good service. So it's really $1500 for 600Mbits, >>> or $2.50 per Megabit. >>> >>> If you're an ISP you look at this and go, humm, I take in $4 from my >>> customer, and hand $2.50 of it right back out to an exchange operator >>> if I use public peering, making the exchange 62% of my costs right up >>> front. On the other hand, if I choose wisely where I private peer I >>> can do it at places with a one-time fee for the cable, so there is >>> $0 in MRC. I have to buy a router port, sure, but it's also $0 MRC, >>> just a capital asset that can get written off over many years. >>> >>> This is the math with the $4 megabit advertised price. The halls at >>> Nanog are awash in $2 a megabit rumors if you have large enough commits >>> (say, a few 10GE's). Taking in $2 and paying the exchange operator >>> $2.50 of it....well, that's not so good. :) >>> >>> Transit prices have fallen enough that MRC's for switch ports, and >>> even MRC's for fiber runs (are any of you still in a colo that wants >>> $500 a month for a fiber run, I didn't think so) are eating up huge >>> chunks of the inbound revenue, and thus just don't make sense. >>> >>> Now, before someone points it out, yes, DECIX's rate per megabit is >>> lower on a 10GE and a second port, so if you can move 2 ports of 10GE of >>> traffic you can make it a lot cheaper. Also, Cogents $4 a megabit is >>> probably predicated on you being in the right location and having the >>> right commit, if you need a DS-3 in West Nowhere you'll pay a higher >>> rate, and that helps offset some of the costs. I've oversimplified, and >>> it's a very complex problem for most providers; however I know many are >>> looking at the fees for peering ports go from being in the noise to a >>> huge part of their cost structure and that doesn't work. >> >> >> > > From michael.holstein at csuohio.edu Wed Dec 9 19:48:28 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 09 Dec 2009 14:48:28 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B1FF933.8030200@rollernet.us> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: <4B1FFF0C.4040404@csuohio.edu> > One could argue that you are *not* complying by using a generic PTR > for a mail server. Some would say that a serious mail server should > have proper DNS records, others will say that you should accept mail > from any IP no matter what. No, we do have it correct .. they wanted us to fix all the *other* ones (that can't even send mail because they're firewalled from doing so) .. $ dig -t mx csuohio.edu [..] ;; ANSWER SECTION: csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu. [..] ;; ADDITIONAL SECTION: antispam5.csuohio.edu. 10800 IN A 137.148.19.13 antispam4.csuohio.edu. 10800 IN A 137.148.18.13 antispam3.csuohio.edu. 10800 IN A 137.148.18.21 antispam2.csuohio.edu. 10800 IN A 137.148.19.12 (and) 13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. 13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. 21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. 12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. Cheers, Michael Holstein Cleveland State University From sethm at rollernet.us Wed Dec 9 20:06:48 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 09 Dec 2009 12:06:48 -0800 Subject: Arrogant RBL list maintainers In-Reply-To: <4B1FFF0C.4040404@csuohio.edu> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> Message-ID: <4B200358.1040900@rollernet.us> Michael Holstein wrote: > No, we do have it correct .. they wanted us to fix all the *other* ones > (that can't even send mail because they're firewalled from doing so) .. > > $ dig -t mx csuohio.edu > [..] > ;; ANSWER SECTION: > csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu. > csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu. > csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu. > csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu. > [..] > ;; ADDITIONAL SECTION: > antispam5.csuohio.edu. 10800 IN A 137.148.19.13 > antispam4.csuohio.edu. 10800 IN A 137.148.18.13 > antispam3.csuohio.edu. 10800 IN A 137.148.18.21 > antispam2.csuohio.edu. 10800 IN A 137.148.19.12 > > (and) > > 13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. > 13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. > 21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. > 12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. > Ah, I must have misread. Yeah that's pretty much the accepted way to do DNS for mail servers. ~Seth From ken at heavycomputing.ca Wed Dec 9 20:09:20 2009 From: ken at heavycomputing.ca (Ken Chase) Date: Wed, 9 Dec 2009 15:09:20 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B1FFF0C.4040404@csuohio.edu> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> Message-ID: <20091209200920.GW19942@sizone.org> To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you? That's egregiously harsh. SORBS was blocking a customer for a generic reverse entry, I gave them a legit looking reverse (that fwds properly too), solved, if a bit irritating. To require the whole BLOCK be totally legit is too much. /kc On Wed, Dec 09, 2009 at 02:48:28PM -0500, Michael Holstein's said: >No, we do have it correct .. they wanted us to fix all the *other* ones >(that can't even send mail because they're firewalled from doing so) .. > >$ dig -t mx csuohio.edu >[..] >;; ANSWER SECTION: >csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu. >csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu. >csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu. >csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu. >Michael Holstein >Cleveland State University > -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From Valdis.Kletnieks at vt.edu Wed Dec 9 20:23:54 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Dec 2009 15:23:54 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: Your message of "Wed, 09 Dec 2009 15:09:20 EST." <20091209200920.GW19942@sizone.org> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> Message-ID: <15881.1260390234@localhost> On Wed, 09 Dec 2009 15:09:20 EST, Ken Chase said: > To be clear: because the legitimate mailserver with a proper non-generic > reverse was in a block with other generic reverses, they blacklisted you? > > That's egregiously harsh. > > SORBS was blocking a customer for a generic reverse entry, I gave them a legit > looking reverse (that fwds properly too), solved, if a bit irritating. To > require the whole BLOCK be totally legit is too much. Especially if they think the "block" is a /24 and you think it's a /27 and somebody else entirely has the /27 either side of you. I've seen *that* sort of brain damage far too often even in recent years. RFC1519 was 16 frikking years ago, and some people *still* aren't on board. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Wed Dec 9 20:23:40 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Dec 2009 12:23:40 -0800 Subject: Breaking the internet (hotels, guestnet style) In-Reply-To: <4B1FEF72.30505@sprunk.org> References: <200912080332.nB83WKSo037049@aurora.sol.net> <200912080539.nB85dMHD003129@drugs.dv.isc.org> <4B1E19EE.40409@accessplus.com.au> <7F808C14-7B07-4EE9-98AB-D60F994BF24B@delong.com> <4B1E6FE8.9010705@accessplus.com.au> <6849D220-4B18-43E8-907A-AA87398E61C5@delong.com> <87ws0wcxbp.fsf@laphroiag.quux.de> <4B1FEF72.30505@sprunk.org> Message-ID: On Dec 9, 2009, at 10:41 AM, Stephen Sprunk wrote: > Jens Link wrote: >> Owen DeLong writes: >> >>> I expect my connections to my mail server to actually reach my >>> mail server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many >>> of the "just works" settings in question break these things badly. >>> >> >> One of my customers has an appliance for his WLAN guest access access >> which filters out AAAA records. :-( >> >> jens at bowmore:~$ dig AAAA www.quux.de @8.8.8.8 +short >> jens at bowmore:~$ >> > > That, unfortunately, is not uncommon. Actually, it's one of the > _less_ > broken systems I've seen, since IPv4 presumably keeps working. > > One major vendor of hotel guestnet equipment returns an A record for > 0.0.0.1 if you do an ANY or AAAA query for any hostname--even ones > that > don't exist. At least with WinXP, you have to disable IPv6 just to > get > IPv4 to work! Worse, their tech support sees nothing wrong with this; > if you disagree, all they'll do is offer a refund. Unfortunately, > "take > your money elsewhere" doesn't work when you've already paid for the > hotel room--and they know it. > I've actually extracted significant rebates from Hotels where their internet was provably broken, and, their third-party provider would not resolve the issue. More than just a refund of the IP fees. In one case, 1/2 the cost of my multi-night stay. Owen From johnl at iecc.com Wed Dec 9 20:30:35 2009 From: johnl at iecc.com (John Levine) Date: 9 Dec 2009 20:30:35 -0000 Subject: Arrogant RBL list maintainers In-Reply-To: <4B1FFF0C.4040404@csuohio.edu> Message-ID: <20091209203035.81823.qmail@simone.iecc.com> >;; ANSWER SECTION: >csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu. >csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu. >csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu. >csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu. >(and) > >13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. >13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. >21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. >12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. All of the DNSBLs I know are about outbound mail hosts, not inbound ones. What are your sending hosts called? R's, John From michael.holstein at csuohio.edu Wed Dec 9 20:53:10 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 09 Dec 2009 15:53:10 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <20091209203035.81823.qmail@simone.iecc.com> References: <20091209203035.81823.qmail@simone.iecc.com> Message-ID: <4B200E36.4010703@csuohio.edu> > All of the DNSBLs I know are about outbound mail hosts, not inbound > ones. What are your sending hosts called? > Outbound goes through the same 4 boxes. We used to split it up (2 at MX10, 2 at MX20 .. reversed for outbound) but for capital (licensing/hardware) reasons we decided to do in/out through the same system. This is just "first touch" on the way in and "last touch" on the way out. We also have spfv1 records defined (albeit a rather permissive "ptr ~all") .. but as I mentioned, the firewall disallows smtp to anywhere but appropriate hosts. We do still allow smtps and submission to accommodate folks that travel, as we haven't (yet) had a problem with bots using either of those services. My beef with Trend was that they were in essence telling us to re-do DNS on our /16 because they didn't like the way we did it .. despite the mail part (the one that matters) being technically correct by most everyone else's standards. Personally, I think this is just so they can have a "big list" when they sell it (.. our DNSBL has $x million more entries than $competitor..). Cheers, Michael Holstein Cleveland State University From michael.holstein at csuohio.edu Wed Dec 9 21:18:21 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 09 Dec 2009 16:18:21 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <20091209200920.GW19942@sizone.org> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> Message-ID: <4B20141D.9090906@csuohio.edu> > To be clear: because the legitimate mailserver with a proper non-generic > reverse was in a block with other generic reverses, they blacklisted you? > Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] and then went on to say : [snip] To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE ? in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. After some arguing back-and-forth .. they (Trend) said : [snip] Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? (Note: they did eventually say "okay, we see the MXs as static so those aren't listed" .. but not without some discussion). Cheers, Michael Holstein Cleveland State University From ccariffe at gmail.com Wed Dec 9 21:58:47 2009 From: ccariffe at gmail.com (Chris Cariffe) Date: Wed, 9 Dec 2009 13:58:47 -0800 Subject: Cogent admin request Message-ID: if there's a Cogent NOC admin here, can you please contact me privately, off the list. thanks. -c From jlewis at lewis.org Wed Dec 9 22:13:32 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 9 Dec 2009 17:13:32 -0500 (EST) Subject: Arrogant RBL list maintainers In-Reply-To: <4B20141D.9090906@csuohio.edu> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> Message-ID: On Wed, 9 Dec 2009, Michael Holstein wrote: > Their initial email said : > > [snip] > Trend Micro Notification: 137.148.0.0/16 added to DUL > [snip] That's just lazy/sloppy. A quick survey of your /16 suggests that the majority of it has PTRs in the format of csu-137-148-36-160.csuohio.edu, which looks like generic rDNS...but assuming that a university has a /16 of dynamic space is just dumb...and in that quick survey of your /16, there are obvious pockets of non-generic rDNS. > To work with us, please generate the following three lists: > > 1) TOTAL ALLOCATED SPACE  in CIDR format > Please include all information for the space you announce. > The total of Static and Dynamic space must equal the > Total Allocated Space. > 2) DYNAMIC SPACE LIST - in CIDR format > 3) STATIC SPACE LIST - in CIDR Format > [snip] > > > Which was, of course, impossible .. since trunking a VLAN across the > core just to have all the printers in the same /22 would be silly. Maybe you misunderstood them? What's trunking a VLAN across the core for a printers subnet have to do with anything? They were asking you to tell them which of your subnets are dynamic and which are static, presumably so they could remove your /16 and list just the bits of it that really are dynamic or otherwise appropriate for their list. > Also we don't see the IP address as static as we see the generic naming > convention of *csuohio.edu* as dynamic and the WHOIS information doesn't > indicate that the space is static. [snip] It really sounds like you were dealing with an idiot and would have done well to see if there was any other individual at Trend/MAPS with maintenance access to their DUL. > Seriously .. we're a college campus, not a colo. Org-Abuse roles is > defined (and valid) and real people read the RFC2142 required addresses. > What more do these people want? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From johnl at iecc.com Thu Dec 10 00:27:47 2009 From: johnl at iecc.com (John Levine) Date: 10 Dec 2009 00:27:47 -0000 Subject: Arrogant RBL list maintainers In-Reply-To: <4B20141D.9090906@csuohio.edu> Message-ID: <20091210002747.39382.qmail@simone.iecc.com> >1) TOTAL ALLOCATED SPACE ? in CIDR format > Please include all information for the space you announce. > The total of Static and Dynamic space must equal the > Total Allocated Space. >2) DYNAMIC SPACE LIST - in CIDR format >3) STATIC SPACE LIST - in CIDR Format >[snip] > >Which was, of course, impossible .. since trunking a VLAN across the >core just to have all the printers in the same /22 would be silly. Is your network setup so chaotic that you don't know what address chunks are allocated by DHCP or PPP? They're not asking you to aggregate your printers, they're just asking which ranges are dynamic, since mail directly from dynamic ranges is about 99.999% bot spam. If you really don't know what's dynamic, I can't say I blame them for assuming the worst. R's, John From frnkblk at iname.com Thu Dec 10 03:08:07 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 9 Dec 2009 21:08:07 -0600 Subject: Arrogant RBL list maintainers In-Reply-To: <4B20141D.9090906@csuohio.edu> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> Message-ID: Michael: I've seen their form, too. I think you're reading too much into their policies/requests. Does it matter if they label your non e-mail server IPs as dynamic space, and therefore put it on their DUL? Frank -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Wednesday, December 09, 2009 3:18 PM To: Ken Chase Cc: nanog at nanog.org Subject: Re: Arrogant RBL list maintainers > To be clear: because the legitimate mailserver with a proper non-generic > reverse was in a block with other generic reverses, they blacklisted you? > Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] and then went on to say : [snip] To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE - in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. After some arguing back-and-forth .. they (Trend) said : [snip] Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? (Note: they did eventually say "okay, we see the MXs as static so those aren't listed" .. but not without some discussion). Cheers, Michael Holstein Cleveland State University From frnkblk at iname.com Thu Dec 10 03:15:57 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 9 Dec 2009 21:15:57 -0600 Subject: Arrogant RBL list maintainers In-Reply-To: <4B1FF933.8030200@rollernet.us> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: Each network can decide how they want to run their network, and Trend Micro can make any list they like, but if cb3rob.net wants to send e-mail to other networks that use Trend Micro's list for spam control, cb3rob.net will have to decide whether to comply with the other network's rules, even if those rules seem unreasonable. Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict deliverability of e-mail from my dynamic space, so I have appropriately named PTRs so that others don't have to guess what kind of host it is. Perhaps I forgot those customers with static hosts and that want to send e-mail -- I make sure those PTRs are well-named, too. Frank -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Wednesday, December 09, 2009 1:24 PM To: nanog at nanog.org Subject: Re: Arrogant RBL list maintainers Michael Holstein wrote: > > Suit yourself .. but you can't arbitrarily force the Internet as a whole > to adopt an unwritten standard just to make your lives easier. If we > encounter problems with our end-users and not being able to deliver > email reliably to one of your customers, we'll have them call you, since > we're complying with all the various SPAM prevention standards that > presently exist. > One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what. ~Seth From swmike at swm.pp.se Thu Dec 10 04:35:43 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 10 Dec 2009 05:35:43 +0100 (CET) Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: On Wed, 9 Dec 2009, Frank Bulk wrote: > Two sides of an SP's coin: I want to maximize my e-mail servers' > deliverability, so I make sure those have appropriately named PTRs and make > sure that outbound messages aren't spammy; I also want to restrict The point he was trying to make is that there is no standard for what those "appropriately named PTRs" should look like. He has forward/reverse that is perfectly ok according to standard (forward/reverse matches) and if he had a automatic dictionary for naming those IPs instead of putting the IPs there, things would be different. If people want to make standards on how to put information into DNS for RBL use, they should take it to the IETF and make a standard out of it, not just ad-hoc create something of their own and expect everybody else to conform. If there is an "industry standard" (which the replies here seem to indicate), that should be written down and standardized by the people who actually make money out of it, in this case Trend Micro. This would remove the problem of having to maintain tens or hundred points of contacts for "what is dynamic dialup space" which is the problem right now as there are a lot of RBLs to deal with. Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. -- Mikael Abrahamsson email: swmike at swm.pp.se From scott.mackenzie at bikouware.com Thu Dec 10 04:57:46 2009 From: scott.mackenzie at bikouware.com (Scott E. MacKenzie) Date: Thu, 10 Dec 2009 04:57:46 -0000 Subject: Data Centre - Advice? (Shenzhen, China) Message-ID: Hi, Does anyone have any great websites to share or advice where I can locate all the tier one Internet Data Centre (IDC) providers in Shenzhen China? My second question would be on any advice that anyone can offer about the problems that can be faced operating your technology foot print inside the PRC, if there are any? Warm Regards, Scott From chris at ghostbusters.co.uk Thu Dec 10 12:49:33 2009 From: chris at ghostbusters.co.uk (Chris) Date: Thu, 10 Dec 2009 12:49:33 +0000 Subject: Linux shaping packet loss In-Reply-To: <20091209091817.44a72d8a.nikky@mnet.bg> References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> <1260340711.20713.261.camel@ub-g-d2> <20091209091817.44a72d8a.nikky@mnet.bg> Message-ID: Thanks to all that replied. Trial and error it is ... I'm now waiting (22 hours later) for it to break again after I changed the priority on the "default" catch-all class. It lasted five days before. I'm looking at CBQ but it's not at all friendly relative to HTB. If I'm forced to go down the proprietary traffic-shaping route. What's good for really cheap gigabit, redundant, high throughput (including during 64-byte UDP attacks) shapers ? Suggestions appreciated. Chris 2009/12/9 Nickola Kolev > ?? Wed, 09 Dec 2009 06:38:31 +0000 > gordon b slater ??????: > > > On Wed, 2009-12-09 at 08:02 +0200, Bazy wrote: > > > > > Hi Chris, > > > > > > Try setting txqueuelen to 1000 on the interfaces and see if you > > > still get a lot of packet loss. > > > > > > > Yes, good point and well worth a try. Rereading Chris's post about > > "250Mbps" and "forty queues", the "egress" could well be bumping the > > end of a default fifo line. > > > > If 1000 is too high for your kit try pushing it upwards gradually from > > the default of 100 (?) but back off if you get drops or strangeness in > > ifconfig output on the egress i/f. > > The default *is* 1000. From the ifconfig man page: > > txqueuelen length > > Set the length of the transmit queue of the device. It is useful to > set this to small values for slower devices with a high atency (modem > links, ISDN) to prevent fast bulk transfers from disturbing interactive > traffic like telnet too much. > > So, if you should touch it if and only if you want to have (supposedly) > finer grained control on queueing, as the hardware device also does > some reordering before it puts the data on the wire. > > > I append grep-ped ifconfig outputs into a file every hour on a cron > > job until I'm happy that strangeness doesn't happen, they never do > > when you're watching sadly. > > > > TC problems aren't always about the TC itself, the physical interfaces > > are inherently part of the "system", as my long rambling 5am+ > > up-all-night-over-ssh post about reseating NICs was trying to hint > > at. > > > > Nice one Bazy > > > > Gord > > > > > > > > > > > > > -- > Regards, > Nickola > > From chris at eng.gla.ac.uk Thu Dec 10 12:56:38 2009 From: chris at eng.gla.ac.uk (Chris Edwards) Date: Thu, 10 Dec 2009 12:56:38 +0000 (GMT) Subject: Arrogant RBL list maintainers In-Reply-To: <4B20141D.9090906@csuohio.edu> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> Message-ID: On Wed, 9 Dec 2009, Michael Holstein wrote: | Their initial email said : | | [snip] | Trend Micro Notification: 137.148.0.0/16 added to DUL | [snip] Oh dear. I can see why many sites that once used MAPS now don't :-( From dot at dotat.at Thu Dec 10 13:20:42 2009 From: dot at dotat.at (Tony Finch) Date: Thu, 10 Dec 2009 13:20:42 +0000 Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> Message-ID: On Thu, 10 Dec 2009, Chris Edwards wrote: > On Wed, 9 Dec 2009, Michael Holstein wrote: > > | Their initial email said : > | > | [snip] > | Trend Micro Notification: 137.148.0.0/16 added to DUL > | [snip] > > Oh dear. I can see why many sites that once used MAPS now don't :-( It isn't just idiocy like this thread. They never expire entries from the RBL, even when IP address space changes hands. The most stupid thing is that they will not accept bug reports from their customers, insisting that they come from the sender (not recipient). WTF?! Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From setient at gmail.com Thu Dec 10 13:59:58 2009 From: setient at gmail.com (Ronald Cotoni) Date: Thu, 10 Dec 2009 08:59:58 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> Message-ID: <2f1d68350912100559h200c0447s14640f90604d421f@mail.gmail.com> On Thu, Dec 10, 2009 at 8:20 AM, Tony Finch wrote: > On Thu, 10 Dec 2009, Chris Edwards wrote: >> On Wed, 9 Dec 2009, Michael Holstein wrote: >> >> | Their initial email said : >> | >> | [snip] >> | Trend Micro Notification: 137.148.0.0/16 added to DUL >> | [snip] >> >> Oh dear. ?I can see why many sites that once used MAPS now don't :-( > > It isn't just idiocy like this thread. They never expire entries from the > RBL, even when IP address space changes hands. The most stupid thing is > that they will not accept bug reports from their customers, insisting that > they come from the sender (not recipient). WTF?! > > Tony. > -- > f.anthony.n.finch ? ?http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. > > Very true. At my old place of employment a DUHL listed an ip since before my previous company existed. For some reason, when we obtained it, they still listed it. Sounds like a bug in the DUHL bot to me. Also the standard makes a lot of sense. You may be on Trend Micros DUHL by following the rules on SORBS DUHL and vica versa. Makes life a pain. From sam at themerritts.org Thu Dec 10 15:29:15 2009 From: sam at themerritts.org (Sam Hayes Merritt, III) Date: Thu, 10 Dec 2009 09:29:15 -0600 (CST) Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: > Creating a standard on what to put in WHOIS/DNS for > dynamic/static/infrastructure would make a lot of sense, seems nobody is > doing it though. As previously noted in this thread, msullivan at sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the "right way". http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 sam From dhc2 at dcrocker.net Thu Dec 10 15:43:36 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 10 Dec 2009 07:43:36 -0800 Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: <4B211728.8050302@dcrocker.net> On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: > As previously noted in this thread, msullivan at sorbs did a fairly good > job of documenting this in an RFC draft. I'd say its still the primary > goto to point people at for how to do things the "right way". > > http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 The time to pursue something like this in the IETF is when there is a substantial industry consensus that it is the right approach and that the folks supporting it will actually use it. Are those of you who have participated in this thread willing to conform to the model specified in this draft? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jjackson at aninetworks.net Thu Dec 10 15:47:32 2009 From: jjackson at aninetworks.net (Joseph Jackson) Date: Thu, 10 Dec 2009 07:47:32 -0800 Subject: Linux Network Generator Message-ID: <695277448C537A469D28FF68D0938C8372F2549221@EXMBX04.exchhosting.com> Hey list, I've been doing some stress testing of a router this week using Network Traffic Generator from http://sourceforge.net/projects/traffic/ and while it works well I was wondering what other generators you all have used and find helpful. Maybe something that Traffic doesn't do like provide response times and other stats.. tho I realize iperf would be a better app for that. From michael.holstein at csuohio.edu Thu Dec 10 15:48:05 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 10 Dec 2009 10:48:05 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <20091210002747.39382.qmail@simone.iecc.com> References: <20091210002747.39382.qmail@simone.iecc.com> Message-ID: <4B211835.2030006@csuohio.edu> > Is your network setup so chaotic that you don't know what address > chunks are allocated by DHCP or PPP? Aww .. stop it, just stop. I could send the .vsd of the network overview to everyone and there'd still be someone that'd chime in and say "Ha! you moron .. you used ORANGE lines to interconnect things, nobody ever does it that way". We've drifted waaaay O/T here. But to answer a few questions : > Maybe you misunderstood them? What's trunking a VLAN across the core for > a printers subnet have to do with anything? They were asking you to tell > them which of your subnets are dynamic and which are static, presumably so > they could remove your /16 and list just the bits of it that really are > dynamic or otherwise appropriate for their list. > We break the /16 up into /23s and /24s (and a few /22s) based on building/router and security class (along with a bunch of 1918 space that we only NAT internally). What would be more chaotic? .. further dividing a /24 just to put static stuff within a (^2) boundary? Like many places, we run seperate internal and external DNS .. when a user requests a static IP, they can opt to make it "external", but few do, since we point out that when they do that, they loose the anonymity of the "generic" rDNS. An internal DNS entry might look like : lastname-modelnumber.router.building.csuohio.edu While the external entry might look like : csu-137-148-19-3.csuohio.edu People that need remote access use our WebVPN (or client VPN) and can then use the internal DNS to find their machine. There's little motivation to create a static unless it's a server or printer. > Does it matter if they label your non e-mail server IPs as dynamic space, > and therefore put it on their DUL? No, not at all. As I've said all along, my beef was that as a mail-abuse DNSBL provider, they were taking issue with our naming scheme for things that had nothing to do with email. As several have already recognized, we are doing the mail part correctly .. there are exactly 4 IPs that are permitted to send mail to the Internet .. FOUR of them, all of which have proper A=PTR, SPFv1 records, abuse@ contacts, etc. /thread Regards, Michael Holstein Cleveland State University From schampeo at hesketh.com Thu Dec 10 15:54:12 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 10 Dec 2009 10:54:12 -0500 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: <20091210155412.GA31002@hesketh.com> on Thu, Dec 10, 2009 at 09:29:15AM -0600, Sam Hayes Merritt, III wrote: > >> Creating a standard on what to put in WHOIS/DNS for >> dynamic/static/infrastructure would make a lot of sense, seems nobody is >> doing it though. > > As previously noted in this thread, msullivan at sorbs did a fairly good job > of documenting this in an RFC draft. I'd say its still the primary goto to > point people at for how to do things the "right way". > > http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 There's also Dan Senie and Andrew Sullivan's draft: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 ...which basically boils down to "if you're not using rDNS to project a clear picture of the intended uses of a given IP, you're screwed". Or maybe that's just my read. I've written up my thoughts on naming and why it matters in a series of posts on my Web site; this is the cumulative wisdom acquired after six years or more of collecting and attempting to classify naming conventions worldwide. We're at close to 47K patterns for over 18K domains worldwide, so I think it's safe to say I've seen my share of this stuff and can draw general observations. In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate. Full archive here: http://enemieslist.com/news/archives/gripes/ Of particular interest, perhaps: http://enemieslist.com/news/archives/2009/06/principles.html http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html http://enemieslist.com/news/archives/2009/07/why_we_suspect.html http://enemieslist.com/news/archives/2009/07/a_passionate_cr.html but the whole archive is full of examples of DNS stupidity, for your enjoyment, and as an expression of years of pent up frustration. ;) Cheers, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From michael.holstein at csuohio.edu Thu Dec 10 16:00:08 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 10 Dec 2009 11:00:08 -0500 Subject: Linux shaping packet loss In-Reply-To: References: <4B1E6607.60503@spectraaccess.com> <20091208.160135.74707586.sthaug@nethelp.no> <6c2184ab0912082202g54efdee5kdf5471d705419c30@mail.gmail.com> <1260340711.20713.261.camel@ub-g-d2> <20091209091817.44a72d8a.nikky@mnet.bg> Message-ID: <4B211B08.20607@csuohio.edu> > What's good for really cheap gigabit, redundant, high throughput Well .. I'd say you could pick any two of those and come up with a list .. but we use Packeteer (now owned by Bluecoat) to great success. It fails the first requirement miserably, IMHO, though. I've also used these in a MDU setting, but certainly not at gigabit speeds : http://www.netequalizer.com/nda.htm They claim models are available up to 5gbps ($11k). 1gbps is ~$9k. Cheers, Michael Holstein Cleveland State University From schampeo at hesketh.com Thu Dec 10 16:00:30 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 10 Dec 2009 11:00:30 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B211835.2030006@csuohio.edu> References: <20091210002747.39382.qmail@simone.iecc.com> <4B211835.2030006@csuohio.edu> Message-ID: <20091210160030.GB31002@hesketh.com> on Thu, Dec 10, 2009 at 10:48:05AM -0500, Michael Holstein wrote: > Like many places, we run seperate internal and external DNS .. when a > user requests a static IP, they can opt to make it "external", but few > do, since we point out that when they do that, they loose the anonymity > of the "generic" rDNS. > > An internal DNS entry might look like : > lastname-modelnumber.router.building.csuohio.edu > While the external entry might look like : csu-137-148-19-3.csuohio.edu At least at one point in 2003, you also used, eg finance137-148-212-227.dhcp.csuohio.edu [137.148.212.227] which kindly pointed out that the IP was dynamically assigned (or at least suggested it, I know DHCP can push statics, too). I have the pattern for the csu-n-n-n-n.csuohio.edu naming convention above marked as 'static/lan' - should I have this down as 'natproxy/unknown' instead? Or 'static/unknown'? Or 'static/wan'? I'm a bit confused by what it means to have an "internal" static public IP, I guess. Or are you saying that they have the option of making their chosen internal name also visible via external DNS lookups, with all IPs being public just not all visible via custom names to the outside? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From mike at mtcc.com Thu Dec 10 16:11:18 2009 From: mike at mtcc.com (Michael Thomas) Date: Thu, 10 Dec 2009 08:11:18 -0800 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: <20091210155412.GA31002@hesketh.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> Message-ID: <4B211DA6.9000203@mtcc.com> On 12/10/2009 07:54 AM, Steven Champeon wrote: > In a nutshell, if you're not clearly indicating mail sources as mail > sources, don't expect great deliverability. If you're running a Web > hosting shop and don't have rate-limited outbound smarthosts, expect all > your clients' mail to be suspected of being phishing scams. If you run a > corporate network that allows unsecured outbound port 25 via NAT, you > lose. If you run a university network (or part of one) without clearly > distinguishing between server infrastructure and student-use end nodes, > you really might want to rethink that. And if you're a consumer ISP that > allows both static and dynamic assignments or serves both residential > and commercial under the same useless generic naming convention, you are > Making It Harder for the rest of us, which is an automatic upgrade path > to reflexive blocking of all traffic. Oh, and if it's out of your control > or what you consider your responsibility, SWIP it and label it clearly > so we can figure out what it is and decide whether we want it as part > of our view of the Internet. Keep your whois up to date and indicate > if nothing else whether a given block is static or dynamically assigned, > residential or corporate. I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is. Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack. If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not. To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike From schampeo at hesketh.com Thu Dec 10 16:15:10 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 10 Dec 2009 11:15:10 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B211728.8050302@dcrocker.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: <20091210161509.GC31002@hesketh.com> on Thu, Dec 10, 2009 at 07:43:36AM -0800, Dave CROCKER wrote: > > > On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: >> As previously noted in this thread, msullivan at sorbs did a fairly good >> job of documenting this in an RFC draft. I'd say its still the primary >> goto to point people at for how to do things the "right way". >> >> http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 > > > The time to pursue something like this in the IETF is when there is a > substantial industry consensus that it is the right approach and that the > folks supporting it will actually use it. > > Are those of you who have participated in this thread willing to conform to > the model specified in this draft? That draft has a few issues; perhaps foremost is the Anglocentric choice of names. Why should a Pole care to name his poczta "mail"? Or a Brazilian name his "correio" using an English term? But that's a minor point, and there aren't *that* many variations on "mx" vs "mail" vs "smtp", etc in non-English languages. If anything, I'd have liked to have seen a more widespread use of the protocol as a canonical name for a box providing service for that protocol, but www's ship sailed a long time ago... M. Sullivan's proposals for the most part, however, conform to the best of current practice as far as I can determine from having looked at several hundred thousand hosts and tens of thousands of naming conventions over the past few years. There are probably ways the proposals could be expanded to cover other edge cases or to conform to current practices (properly naming NATs, VPN hosts, University resnets, "vps" instead of "shared", perhaps, dealing with "cloud" computing, Web and other proxies). And there are certainly plenty of other network situations that might be covered in a future draft, certainly more than I could describe here. The bottom line is that people *are* using rDNS/PTR naming as a means to help them determine policy. It's not abstract, it's happening. I'd love to see some way to define emission policies for a given netblock that could be queried in real-time, by the receiving services, but I suspect that's a long way off. Until then, clear and informative labeling is the best way to go. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From Michael_OReirdan at Cable.Comcast.com Thu Dec 10 16:19:33 2009 From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael) Date: Thu, 10 Dec 2009 11:19:33 -0500 Subject: best practices for PTR naming and whois (was, sadly, Re: ArrogantRBL list maintainers) In-Reply-To: <4B211DA6.9000203@mtcc.com> Message-ID: MAAWG has published an approach that it recommends is taken to share information as to nature of IP space. This may be of interest here. It can be found here: http://www.maawg.org/about/publishedDocuments Mike On 12/10/09 11:11 AM, "Michael Thomas" wrote: > On 12/10/2009 07:54 AM, Steven Champeon wrote: >> > In a nutshell, if you're not clearly indicating mail sources as mail >> > sources, don't expect great deliverability. If you're running a Web >> > hosting shop and don't have rate-limited outbound smarthosts, expect all >> > your clients' mail to be suspected of being phishing scams. If you run a >> > corporate network that allows unsecured outbound port 25 via NAT, you >> > lose. If you run a university network (or part of one) without clearly >> > distinguishing between server infrastructure and student-use end nodes, >> > you really might want to rethink that. And if you're a consumer ISP that >> > allows both static and dynamic assignments or serves both residential >> > and commercial under the same useless generic naming convention, you are >> > Making It Harder for the rest of us, which is an automatic upgrade path >> > to reflexive blocking of all traffic. Oh, and if it's out of your control >> > or what you consider your responsibility, SWIP it and label it clearly >> > so we can figure out what it is and decide whether we want it as part >> > of our view of the Internet. Keep your whois up to date and indicate >> > if nothing else whether a given block is static or dynamically assigned, >> > residential or corporate. > > I'd say that Mikael Abrahamsson's sentiment (or at least the way I read > it) would be a better start: take a step back and ask what the problem is. > Naming conventions blah, blah, blah all started from the _lack_ of a > standard and trying to educe knowledge from chaos. In other words, a > bunch of hacks. Which doesn't work especially well, especially when > every RBL has its own hack. > > If IETF can do something here, which seems plausible, it would be to actually > define the problem and _then_ write a protocol to fit the needs of the > problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming > conventions > (ick), probably it does not. But if it were standardized, it would at least > be predictable which the current situation manifestly is not. > > To Crocker's point though: if IETF came up with a way to publish your > network's > dynamic space (assuming that's The Problem!), would operators do that? Or is > this another case where the energy barrier is too high? > > Mike > > From schampeo at hesketh.com Thu Dec 10 16:29:25 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 10 Dec 2009 11:29:25 -0500 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: <4B211DA6.9000203@mtcc.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> <4B211DA6.9000203@mtcc.com> Message-ID: <20091210162925.GD31002@hesketh.com> on Thu, Dec 10, 2009 at 08:11:18AM -0800, Michael Thomas wrote: > I'd say that Mikael Abrahamsson's sentiment (or at least the way I read > it) would be a better start: take a step back and ask what the problem is. Well, as I see it, the problem is a widespread and systemic failure to prevent massive abuses from being perpetrated by unauthorized software in the control of entities other than the administrators of those networks and servers in question, resulting in a near-total breakdown of trust in any given unknown host's reputation, resulting in desparate attempts to gain insight into which hosts might be trusted and which not, using what means may be available (naming, whois, DNSBLs, etc.) > Naming conventions blah, blah, blah all started from the _lack_ of a > standard and trying to educe knowledge from chaos. In other words, a > bunch of hacks. Which doesn't work especially well, especially when > every RBL has its own hack. Well, I'd like to think my approach (name-based, rather than IP-based) works fairly well, going as it does in the names you give your IPs and whatever other public information may be available, but I understand your frustration with the various approaches used by IP-based DULs; I can also understand the lack of patience on the side of the DUL operators. The situation is a mess. > If IETF can do something here, which seems plausible, it would be to > actually define the problem and _then_ write a protocol to fit the > needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it > uses naming conventions (ick), probably it does not. But if it were > standardized, it would at least be predictable which the current > situation manifestly is not. Like it or not, naming conventions are useful and powerful and widespread. Would you rather have to deal with inbound mail from 134.25.177.41-get-allinone-adsl-and-free-webhosting-for-only-r189.saol.com or 196-200-118.isnigeria or one-of-hosts-our-net.dn.cv.ua [194.146.136.24] or dressless-debate.volia.net [77.123.181.13] or dont-blame-admin-its-a-dsl-pool-251-41.wobline.de or cable-66-103-40-69.clarenville.dyn.personainc.net [66.103.40.69] or 200.72.157.254: pcdibujante2.eiser.local ? > To Crocker's point though: if IETF came up with a way to publish your > network's dynamic space (assuming that's The Problem!), would > operators do that? Or is this another case where the energy barrier is > too high? It's not just dynamics, either. Static generic IPs also emit spam and abuse. Finding all the dynamics on the Net would only stop from half to maybe two thirds of the traffic we see, for example. http://enemieslist.com/news/archives/2009/07/why_we_suspect.html Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From michael.holstein at csuohio.edu Thu Dec 10 16:33:36 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 10 Dec 2009 11:33:36 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <20091210160030.GB31002@hesketh.com> References: <20091210002747.39382.qmail@simone.iecc.com> <4B211835.2030006@csuohio.edu> <20091210160030.GB31002@hesketh.com> Message-ID: <4B2122E0.1030408@csuohio.edu> > I'm a bit confused by what it > means to have an "internal" static public IP "internal" means behind the firewall (which everything is, transparently). We don't NAT because we don't have to .. the 1918 space is used for stuff we don't want to be routable (like thermostats). > that they have the option of making their chosen internal name also > visible via external DNS lookups, with all IPs being public just not > all visible via custom names to the outside? > Correct. When you request a DNS entry, there's a little box on the webform that says "external?" .. and if you check it, the same entry gets put in the outward-facing DNS (both A and PTR). Otherwise it stays the default csu-x-x-x-x.csuohio.edu, regardless of what it is on the inside. Regards, Michael Holstein Cleveland State Unviersity From marka at isc.org Thu Dec 10 16:38:00 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Dec 2009 03:38:00 +1100 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: Your message of "Thu, 10 Dec 2009 08:11:18 -0800." <4B211DA6.9000203@mtcc.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> <4B211DA6.9000203@mtcc.com> Message-ID: <200912101638.nBAGc01C004456@drugs.dv.isc.org> In message <4B211DA6.9000203 at mtcc.com>, Michael Thomas writes: > On 12/10/2009 07:54 AM, Steven Champeon wrote: > > In a nutshell, if you're not clearly indicating mail sources as mail > > sources, don't expect great deliverability. If you're running a Web > > hosting shop and don't have rate-limited outbound smarthosts, expect all > > your clients' mail to be suspected of being phishing scams. If you run a > > corporate network that allows unsecured outbound port 25 via NAT, you > > lose. If you run a university network (or part of one) without clearly > > distinguishing between server infrastructure and student-use end nodes, > > you really might want to rethink that. And if you're a consumer ISP that > > allows both static and dynamic assignments or serves both residential > > and commercial under the same useless generic naming convention, you are > > Making It Harder for the rest of us, which is an automatic upgrade path > > to reflexive blocking of all traffic. Oh, and if it's out of your control > > or what you consider your responsibility, SWIP it and label it clearly > > so we can figure out what it is and decide whether we want it as part > > of our view of the Internet. Keep your whois up to date and indicate > > if nothing else whether a given block is static or dynamically assigned, > > residential or corporate. > > I'd say that Mikael Abrahamsson's sentiment (or at least the way I read > it) would be a better start: take a step back and ask what the problem is. > Naming conventions blah, blah, blah all started from the _lack_ of a > standard and trying to educe knowledge from chaos. In other words, a > bunch of hacks. Which doesn't work especially well, especially when > every RBL has its own hack. > > If IETF can do something here, which seems plausible, it would be to actually > define the problem and _then_ write a protocol to fit the needs of the > problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions > (ick), probably it does not. But if it were standardized, it would at least > be predictable which the current situation manifestly is not. > > To Crocker's point though: if IETF came up with a way to publish your network's > dynamic space (assuming that's The Problem!), would operators do that? Or is > this another case where the energy barrier is too high? > > Mike The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mike at mtcc.com Thu Dec 10 16:42:28 2009 From: mike at mtcc.com (Michael Thomas) Date: Thu, 10 Dec 2009 08:42:28 -0800 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: <200912101638.nBAGc01C004456@drugs.dv.isc.org> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> <4B211DA6.9000203@mtcc.com> <200912101638.nBAGc01C004456@drugs.dv.isc.org> Message-ID: <4B2124F4.2050101@mtcc.com> On 12/10/2009 08:38 AM, Mark Andrews wrote: > In message<4B211DA6.9000203 at mtcc.com>, Michael Thomas writes: > To Crocker's point though: if IETF came up with a way to publish your network's >> dynamic space (assuming that's The Problem!), would operators do that? Or is >> this another case where the energy barrier is too high? >> >> Mike > > The way to do this is to put other data in the ip6.arpa/in-addr.arpa and > stop trying to infer things from the PTR records. Sigh. What is the "this" to which you refer? The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. Mike From sven at cyberbunker.com Thu Dec 10 16:46:50 2009 From: sven at cyberbunker.com (Sven Olaf Kamphuis) Date: Thu, 10 Dec 2009 16:46:50 +0000 (GMT) Subject: Arrogant RBL list maintainers In-Reply-To: <4B211728.8050302@dcrocker.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: > > On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: > > As previously noted in this thread, msullivan at sorbs did a fairly good > > job of documenting this in an RFC draft. I'd say its still the primary > > goto to point people at for how to do things the "right way". > > > > http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 > > > The time to pursue something like this in the IETF is when there is a > substantial industry consensus that it is the right approach and that the folks > supporting it will actually use it. > > Are those of you who have participated in this thread willing to conform to the > model specified in this draft? no, as having PTR records in "dot seperated form" could potentially cause confusion with normal ip addresses in case the search domain is the same. we stick to the "must start with an alphabetic and not contain dots" method, as in "a84-22-123-123" not as in 84.22.123.123.bla.cb3rob.com (which actually are also the host names on the devices on those ips in most cases (although customers are ofcourse free to change that after the control has been given over to them in case of rented out servers). as for the rest of it, i really don't see why we should specifically "mark" static space as being static space as it's simply the de-facto standard, anything else (dhcp, radius, etc) is -optional- and requires extra protocols, so just mark dynamic ip space explicitly instead (if anything) It's also a thing that does not "belong" in dns but rather in whois if anywhere at all. RBLs are neither authorised (EU privacy laws anyone?), nor the appointed authority to keep databases on "whats static or not". RIRs -are-, if anyone should maintain a database on such things, i'd be the rirs (which they have, it's called "whois", it just lacks a field that indicates the type of assignment method used. but i guess that would quickly end the "selling point" of such databases, as who needs Trend Micro if either DNS or whois already contained all required data to just make your mailservers check it in real-time. Anyway, i wish Trend Micro all the luck with maintaining their little database in the age of IPv6 and decaying SMTP use anyway (we nowadays prefer methods like skype, msn, jabber for most of our communications, SMTP has been considered end-of-life for the past 5 years or so over here in our companies, guess why, because it hardly ever works, thanks to companies like Trend Micro just making up their own little standards. it's just a bit annoying for customers that happen to want to send SMTP based (legacy) email to parties that use their RBL, that's all, but indeed, their list will rapidly be removed by any party using it that finds out about their "criteria" to be removed (as they seem to add a lot of stuff by default as being dynamic, kinda the wrong way around ;) spam is -not- what will eventually kill all support for smtp (that can be easily solved by adding a header field with a unique password for each contact you have approved, and bouncing everything that doesnt contain one ;), shitty amateuristic RBL lists and graylisting (so your urgent mail arrives 20 minutes late) is what's killing smtp support. the only reason -we- still run it is that RIPE etc do not support other address types in whois and mailinglists (such as nanog) still use it. as it's neither peer to peer anymore, nor real-time (with a lot of parties blocking port 25), nor very certain that your message actually will be delivered anymore. We prefer the pre-approved contact list method anyway, you may notice our emails have this X-CONTACT-FILTER-MATCH: nanog "header" at the bottom, added by our contact-filter software (kinda like procmail but different) as "nanog" happens to be the "super secret password" for this list. business cards etc all contain a unique password, as when you don't know us and we don't know you, you have no business mailing us, same as on skype and msn "contact lists". methods like that could ofcourse be implemented in the protocol SMTP itself and in all the clients so it could become a proper mail header at one point, removing the need for all the other crap that only slows the exchange of mail down and lessens its reliability and doesn't really stop spam anyway ;). we don't feel that: - dns is the proper place to distinquish between address assignment methods - dns should be relevant for SMTP to work anyway - RBLs should be authorative to maintain databases of address assignment methods (although the EU privacy laws take it a bit too far, prohibiting companies in germany where we are from even storing IP addresses in the first place ;) - RBLs are an effective method to stop spam (it stops -some-.. not -all-) - Making SMTP less reliable and less fast is a good way to go forward if we want to keep the SMTP protocol around in the future. - Making it impossible to use SMTP in a peer-to-peer fashion on eyeball networks and therefore not very real-time anymore is a good idea. furthermore, trend micro is simply on crack, thinking that they can force us to practically work for them for free and maintain their list for them. if they want us to update their -product- as that's what it is with our -information- they should simply pay us for the manhours, which they don't, so there. (not to mention that what trend micro is doing is illegal under german law so we cannot cooperate with them on that ;) > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > X-CONTACT-FILTER-MATCH: "nanog" > From raymond at prolocation.net Thu Dec 10 16:50:52 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 10 Dec 2009 17:50:52 +0100 (CET) Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: Hi! > RBLs are neither authorised (EU privacy laws anyone?), nor the appointed > authority to keep databases on "whats static or not". RIRs -are-, if > anyone should maintain a database on such things, i'd be the rirs > (which they have, it's called "whois", it just lacks a field that > indicates the type of assignment method used. Who cares!? This is something between the ISP using them and YOU. If people want to make use of ANY datasource thats their own thing. They are not forced to use it at all. There is no EU law or anything involved here. There are blacklists that block .CN, so what, up to you to use it it not. Same with iptables, you can also filter anything you like there, yourselve. No EU law telling anything about that. Stick to the point, solve your issue with the party receiving your mails. they dediced to use the list, and most likely were not forced to do so. If you want to mail with them, fix your reverses. If not, no problem either. But stop whining :) Byem, Raymond. From sven at cyberbunker.com Thu Dec 10 16:55:37 2009 From: sven at cyberbunker.com (Sven Olaf Kamphuis) Date: Thu, 10 Dec 2009 16:55:37 +0000 (GMT) Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: thing is that it's illegal to maintain a database with "personal details" which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* sometimes laws really come in handy you know ;) -- Sven Olaf Kamphuis CB3ROB Ltd. & Co. KG DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Thu, 10 Dec 2009, Raymond Dijkxhoorn wrote: > Hi! > > > RBLs are neither authorised (EU privacy laws anyone?), nor the appointed > > authority to keep databases on "whats static or not". RIRs -are-, if > > anyone should maintain a database on such things, i'd be the rirs > > (which they have, it's called "whois", it just lacks a field that > > indicates the type of assignment method used. > > Who cares!? > > This is something between the ISP using them and YOU. If people want to > make use of ANY datasource thats their own thing. They are not forced to > use it at all. > > There is no EU law or anything involved here. > > There are blacklists that block .CN, so what, up to you to use it it not. > > Same with iptables, you can also filter anything you like there, > yourselve. No EU law telling anything about that. > > Stick to the point, solve your issue with the party receiving your mails. > they dediced to use the list, and most likely were not forced to do so. > > If you want to mail with them, fix your reverses. If not, no problem > either. But stop whining :) > > Byem, > Raymond. > > X-CONTACT-FILTER-MATCH: "nanog" > From raymond at prolocation.net Thu Dec 10 17:01:16 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 10 Dec 2009 18:01:16 +0100 (CET) Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: Hi! > thing is that it's illegal to maintain a database with "personal details" > which ip addresses according to various german courts are (don't ask.. > mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not > persons, but the germans seem to mainain a different view on this, > despite us isps being the owners of the internet and not the german > government ;). > > therefore we are not even -allowed- to cooperate with trend micro *grin* > > sometimes laws really come in handy you know ;) I am not a german neither do i live there. This is nanog, not denog ;) Ok and how many german blacklists are in use? There are reasons most of the blacklists are not based there. Its a silly story and you should focus on the ISP using the list and not some legal thing. Thats irrelevant here. Technically i dont see any new points and stick to the old story. Contact that ISP and negotiate with them. Good luck. bye, Raymond. From jgreco at ns.sol.net Thu Dec 10 17:05:36 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 10 Dec 2009 11:05:36 -0600 (CST) Subject: Arrogant RBL list maintainers In-Reply-To: from "Sven Olaf Kamphuis" at Dec 10, 2009 04:46:50 PM Message-ID: <200912101705.nBAH5aNZ088189@aurora.sol.net> > RBLs are neither authorised (EU privacy laws anyone?), nor the appointed > authority to keep databases on "whats static or not". RIRs -are-, if > anyone should maintain a database on such things, i'd be the rirs > (which they have, it's called "whois", it just lacks a field that > indicates the type of assignment method used. Please don't be ridiculous. Of course DNSBL's are authorized to do this. There is no compulsory use; if I choose to USE a DNSBL, I am electing to allow them to assist me in making decisions about who I receive mail from. If you receive a request for information about your address space from a DNSBL operator, there is no compulsory requirement for you to respond. If you choose to provide it, you authorize the DNSBL to share that information. If you do not, the DNSBL may take whatever action it considers appropriate. Do you believe that some further "authorization" is required? If so, please explain... because there are businesses whose business models revolve around providing much more detailed information about IP address usage. Your next obvious reply will probably be that some EU privacy law somehow considers this to be "personally identifiable information" of some sort; however, that is simply ridiculous. One bit of information about whether the address is a dynamic or static allocation is not PII, it's a bit of information that describes the network operator's intended use of the address. The only way it could be construed as PII is to note that it might be an address assigned to a person. However, you can assign both static and dynamic addresses to a person. Since the person in question could be anyone, interchangeably, it is obviously not PII. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jabley at hopcount.ca Thu Dec 10 17:06:12 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 10 Dec 2009 17:06:12 +0000 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: <4B2124F4.2050101@mtcc.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> <4B211DA6.9000203@mtcc.com> <200912101638.nBAGc01C004456@drugs.dv.isc.org> <4B2124F4.2050101@mtcc.com> Message-ID: <478ACC6D-3B1B-4AC5-A0C9-749CA9CD4BF2@hopcount.ca> On 2009-12-10, at 16:42, Michael Thomas wrote: > On 12/10/2009 08:38 AM, Mark Andrews wrote: > >> The way to do this is to put other data in the ip6.arpa/in-addr.arpa and >> stop trying to infer things from the PTR records. > > Sigh. What is the "this" to which you refer? I think Mark means "the question of whether a particular address is statically-assigned or dynamically-assigned", but... > The problem space here is what's important. And I think it's worth considering > that port 25 isn't the only abuse vector anymore. ... I agree that there's no clear limit to the kind of questions we could come up with that we could answer in such a way. Maybe we don't need to boil the ocean, though. $ORIGIN 90.212.90.in-addr.arpa. @ SOA ... @ NS ... ; 13 PTR calamari.hopcount.ca. 13 HINFO Apple-Mac-Mini "Mac OS X Server" 13 RP jabley.hopcount.ca. . 13 TXT "dynamic" ; * RP jabley.hopcount.ca. . * HINFO Nothing "Unallocated" * TXT "unallocated, should source no traffic" Joe From mike at mtcc.com Thu Dec 10 17:27:44 2009 From: mike at mtcc.com (Michael Thomas) Date: Thu, 10 Dec 2009 09:27:44 -0800 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: <478ACC6D-3B1B-4AC5-A0C9-749CA9CD4BF2@hopcount.ca> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> <4B211DA6.9000203@mtcc.com> <200912101638.nBAGc01C004456@drugs.dv.isc.org> <4B2124F4.2050101@mtcc.com> <478ACC6D-3B1B-4AC5-A0C9-749CA9CD4BF2@hopcount.ca> Message-ID: <4B212F90.90201@mtcc.com> On 12/10/2009 09:06 AM, Joe Abley wrote: > > On 2009-12-10, at 16:42, Michael Thomas wrote: > >> On 12/10/2009 08:38 AM, Mark Andrews wrote: >> >>> The way to do this is to put other data in the ip6.arpa/in-addr.arpa and >>> stop trying to infer things from the PTR records. >> >> Sigh. What is the "this" to which you refer? > > I think Mark means "the question of whether a particular address is statically-assigned or dynamically-assigned", but... Which assumes that that's the question that actually needs to be answered. >> The problem space here is what's important. And I think it's worth considering >> that port 25 isn't the only abuse vector anymore. > > ... I agree that there's no clear limit to the kind of questions we could come up with that we could answer in such a way. Maybe we don't need to boil the ocean, though. Sure, but positing the deployment of any infrastructure comes at a huge cost. Making certain that you're solving the right problem should be the first concern, since it's so expensive. > $ORIGIN 90.212.90.in-addr.arpa. > @ SOA ... > @ NS ... > ; > 13 PTR calamari.hopcount.ca. > 13 HINFO Apple-Mac-Mini "Mac OS X Server" > 13 RP jabley.hopcount.ca. . > 13 TXT "dynamic" See, that makes the assumption that that is the right question. Is it really though? Dynamic vs static is a placeholder for "authorized for this role or not", right? And not a very good one when you start to consider the larger world of protocols. I don't think it's "boiling the ocean" to ask the question of what the producers and consumers of that information are actually looking for. Mike > ; > * RP jabley.hopcount.ca. . > * HINFO Nothing "Unallocated" > * TXT "unallocated, should source no traffic" > > > Joe From schampeo at hesketh.com Thu Dec 10 18:01:29 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 10 Dec 2009 13:01:29 -0500 Subject: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers) In-Reply-To: <4B212F90.90201@mtcc.com> References: <4B1FF933.8030200@rollernet.us> <20091210155412.GA31002@hesketh.com> <4B211DA6.9000203@mtcc.com> <200912101638.nBAGc01C004456@drugs.dv.isc.org> <4B2124F4.2050101@mtcc.com> <478ACC6D-3B1B-4AC5-A0C9-749CA9CD4BF2@hopcount.ca> <4B212F90.90201@mtcc.com> Message-ID: <20091210180129.GB4520@hesketh.com> on Thu, Dec 10, 2009 at 09:27:44AM -0800, Michael Thomas wrote: > On 12/10/2009 09:06 AM, Joe Abley wrote: >> I think Mark means "the question of whether a particular address is >> statically-assigned or dynamically-assigned", but... > > Which assumes that that's the question that actually needs to be answered. Well, it seems to be a question that folks at MAAWG are currently trying to answer; I know of at least one effort to coordinate standard means of publishing your "dynamics" between various MAAWG members, so it seems to be a question that does need to be answered. I'd agree that it's not the only question - see my post on why we consider generic statics suspect. I think in the end, we'll see anyone without a custom, clear, legible, name indicating that a host should be sending mail simply having their mail refused. >> ... I agree that there's no clear limit to the kind of questions we could >> come up with that we could answer in such a way. Maybe we don't need to >> boil the ocean, though. > > Sure, but positing the deployment of any infrastructure comes at a > huge cost. Yeah, for example, it took Road Runner something on the order of 18 months to move all of their residential account PTRs under 'res.rr.com', and their business class under 'biz.rr.com'. They're a bit of a special case, as they're more of a franchise than a single entity, but still. They came to realize that doing so was useful and good, so they did it. And kudos to them for doing so. > Making certain that you're solving the right problem should be the first > concern, since it's so expensive. All I'm saying, and feel free to do with this what you will, is that there is a demand for means for assigning reputation to IPs based partly on their PTR records; antispam appliance vendors, reputation service providers, carrier class cable and telco companies and ISPs, are all exploring or actively using PTR naming classification as one of those means. You can either recognize this and make your networks more transparent to such enquries, or not. Whois is not the only answer; without a way to quickly associate a PTR with a whois record that happens to say "dynamic residential" or "static business" (to use the most broad of available classifications) in real time by DNS lookup or other means, your detailed whois records are useless in direct, practical terms, to postmasters and spam filtering software and others. Spamhaus PBL is one answer, mapping IPs based on ISP-provided information or Spamhaus researcher-discovered information, into zones to be used for rejecting mail. SORBS DUL works in similar way, and makes assumptions on the basis of rDNS scans at the /24 level (among other mechanisms). Enemieslist uses whatever information we can to classify PTR naming; whois, Web sites, price lists and a la carte menus ("do they charge extra for static IPs?", "do they even provide static IPs?", etc.) and then bases that classification on the name of the remote host at connect time - so we don't have the same "falls in a suspicious /24" problem seen so often with SORBS and now MAPS DUL, but just because a customer /can/ ask for and pay for and receive a custom PTR for their mail server doesn't mean they always do - just that over time, they will have to or face poor deliverability, hassles, and the like. But the bottom line is that failure to provide transparency via PTRs is a problem, particularly for deliverability, whether directly (your mail server is named "rrcs-12-34-56-78.se.biz.rr.com", which is static but generic, so would be scored suspicious via Enemieslist) or indirectly (your mail server is in a block of generic PTRs that may be static or dynamically assigned based on vague rDNS, so it ended up in a SORBS DUL listing) or (your mail server is in a block with no custom rDNS that the whois record doesn't indicate is static, so ended up in a PBL listing due to lack of cooperation from the ISP), and so on and so on. Of course it makes it easier for me, and Spamhaus, and SORBS, and Trend, if the networking community helps us make these determinations and pass along the proper and appropriate classifications, so that our users and licensees can use our data to make fine-grained policy decisions. Also true is that doing this stuff right can be difficult, or expensive, but I think the point to take away here is that it's already being done, and you can either help, or be an obstacle to progress. Asking whether this is "the right question" isn't terribly helpful /now/, given that debates have raged here and on mailop and in other forums for years. I prefer to look at the available data (spamtraps, filters, mail flow analyses, etc.) and do something /now/ that is helpful to people wishing to ameliorate abuse /now/. And for the moment, as for the past six years, associating classifications with PTRs based on their naming is a very effective strategy, and one which we're going to continue to use. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From deric.kwok2000 at gmail.com Thu Dec 10 18:24:06 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 10 Dec 2009 13:24:06 -0500 Subject: Optical fiber question Message-ID: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> Hi My provider said they can provide single / mulit mode Optical fiber Apart from the length and cost different, what is the Adv/Disadv between them for our connection? Thank you From jared at puck.nether.net Thu Dec 10 18:28:59 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Dec 2009 13:28:59 -0500 Subject: Optical fiber question In-Reply-To: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> References: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> Message-ID: On Dec 10, 2009, at 1:24 PM, Deric Kwok wrote: > Hi > > My provider said they can provide single / mulit mode Optical fiber > > Apart from the length and cost different, what is the Adv/Disadv > between them for our connection? The advantages are always in the distance capabilities of the single mode fiber. You can reach much further on this, but the optics tend to be more expensive. If you are going a short distance (eg: 2km or less) multi-mode is the way. If you're going to go any further, or want to ever go any further, take the extra cost and know you can swap optics in the future to do gig, 10G and possibly more (in the future) with less pain. - Jared From jared at puck.nether.net Thu Dec 10 18:35:16 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Dec 2009 13:35:16 -0500 Subject: More ASN collissions Message-ID: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> As always, good research by renesys. http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml - Jared From rdobbins at arbor.net Thu Dec 10 18:51:29 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 10 Dec 2009 18:51:29 +0000 Subject: More ASN collissions In-Reply-To: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> Message-ID: <359A8DB8-C0DE-485D-B5C4-1A08B5D5E9E5@arbor.net> On Dec 11, 2009, at 1:35 AM, Jared Mauch wrote: > As always, good research by renesys. What happens when an ASN is requested, and it's discovered that said ASN is already in use by an unauthorized network, and that some proportion of the Internet are accepting it due to a lack of appropriate routing policy? Is there a process to try and reclaim said ASN via persuasion, or some jurisdictionally-appropriate legal action, or peer pressure (pardon the pun), or . . . ? This is a different circumstance than either accidental or deliberate use of an already-assigned and -utilized ASN; has this situation occurred in the past, and if so, how was it resolved? If the situation isn't resolved in a timely manner, is the ASN in question considered 'poisoned' until a resolution is attained, and the next available ASN which isn't being utilized in a rogue fashion issued in its place? Apologies if this is a naive question; I've not run into this particular circumstance before, nor have I found any reference to it in any of the various list archives. I do believe that it may become a bit more common, given some of the confusion and drama regarding the operationalization of 4-byte ASNs. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nanog at data102.com Thu Dec 10 19:36:33 2009 From: nanog at data102.com (randal k) Date: Thu, 10 Dec 2009 12:36:33 -0700 Subject: Qwest mail admin contact? Message-ID: If one is listening, can I get a Qwest mail admin to drop me a line off-list? Numerous emails to postmaster, abuse, relay, etc all seem to be deadends. Thanks, Randal From ck at sandcastl.es Thu Dec 10 20:54:14 2009 From: ck at sandcastl.es (christian koch) Date: Thu, 10 Dec 2009 12:54:14 -0800 Subject: More ASN collissions In-Reply-To: <359A8DB8-C0DE-485D-B5C4-1A08B5D5E9E5@arbor.net> References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> <359A8DB8-C0DE-485D-B5C4-1A08B5D5E9E5@arbor.net> Message-ID: <8c308e8b0912101254n57cadcefp7a05c31ae847fe57@mail.gmail.com> i believe john curran just posted the follow up to the list yesterday on this matter On Thu, Dec 10, 2009 at 10:51 AM, Dobbins, Roland wrote: > > On Dec 11, 2009, at 1:35 AM, Jared Mauch wrote: > > > As always, good research by renesys. > > What happens when an ASN is requested, and it's discovered that said ASN is > already in use by an unauthorized network, and that some proportion of the > Internet are accepting it due to a lack of appropriate routing policy? Is > there a process to try and reclaim said ASN via persuasion, or some > jurisdictionally-appropriate legal action, or peer pressure (pardon the > pun), or . . . ? > > This is a different circumstance than either accidental or deliberate use > of an already-assigned and -utilized ASN; has this situation occurred in the > past, and if so, how was it resolved? If the situation isn't resolved in a > timely manner, is the ASN in question considered 'poisoned' until a > resolution is attained, and the next available ASN which isn't being > utilized in a rogue fashion issued in its place? > > Apologies if this is a naive question; I've not run into this particular > circumstance before, nor have I found any reference to it in any of the > various list archives. I do believe that it may become a bit more common, > given some of the confusion and drama regarding the operationalization of > 4-byte ASNs. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > From deepak at ai.net Thu Dec 10 21:24:41 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 10 Dec 2009 16:24:41 -0500 Subject: Optical fiber question In-Reply-To: References: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> Message-ID: > My provider said they can provide single / mulit mode Optical fiber > > > > Apart from the length and cost different, what is the Adv/Disadv > > between them for our connection? > > The advantages are always in the distance capabilities of the single > mode fiber. You can reach much further on this, but the optics tend to > be more expensive. If you are going a short distance (eg: 2km or less) > multi-mode is the way. If you're going to go any further, or want to > ever go any further, take the extra cost and know you can swap optics > in the future to do gig, 10G and possibly more (in the future) with > less pain. Just to amplify Jared's very complete answer. The principle reason you would use multimode instead of single mode is reduced cost. If cost isn't an issue, single mode has more potential to be used in more applications. Even the longer range SM optics can be used for short range uses with inexpensive attenuators. Service Providers support both because their customers may only support one or the other. Deepak Jain AiNET From leslie at craigslist.org Thu Dec 10 21:29:45 2009 From: leslie at craigslist.org (Leslie) Date: Thu, 10 Dec 2009 13:29:45 -0800 Subject: Optical fiber question In-Reply-To: References: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> Message-ID: <4B216849.3040804@craigslist.org> Jared Mauch wrote: > On Dec 10, 2009, at 1:24 PM, Deric Kwok wrote: > >> Hi >> >> My provider said they can provide single / mulit mode Optical fiber >> >> Apart from the length and cost different, what is the Adv/Disadv >> between them for our connection? > > The advantages are always in the distance capabilities of the single mode fiber. You can reach much further on this, but the optics tend to be more expensive. If you are going a short distance (eg: 2km or less) multi-mode is the way. If you're going to go any further, or want to ever go any further, take the extra cost and know you can swap optics in the future to do gig, 10G and possibly more (in the future) with less pain. I'm assuming you're talking about someone actually giving you a strand of fiber you'd be lighting yourself. If it's a short intrabuilding handoff, then it doesn't really matter - I'd just go with what's cheapest. Plus, while I'm sure someone in a lab has done it, you really don't run DWDM over multimode fiber - I'd second the opinion of it's cheap enough, go for the single mode and get the most flexibility in your options possible. One minor consideration is usually SM optics are stronger, so don't forget attenuation if it's a short distance or you might burn out your pricey new optics! Leslie From tkapela at gmail.com Thu Dec 10 22:52:02 2009 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 10 Dec 2009 17:52:02 -0500 Subject: Optical fiber question In-Reply-To: <4B216849.3040804@craigslist.org> References: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> <4B216849.3040804@craigslist.org> Message-ID: <2e9d8ae50912101452m3a947673s9bb715b572d9d3d@mail.gmail.com> Wanted to add something to this and clarify/correct a few points: > Plus, while I'm sure someone in a lab has done it, you really don't run DWDM > over multimode fiber - I'd second the opinion of it's cheap enough, go for > the single mode and get the most flexibility in your options possible. In fact, already being done - this is how 10GB-LX4 operates. The point here is that each of the four channels operates at less than 10 gigabits/sec, and that MMF didn't prevent it, in fact, it was done entirely to make 10 gig work over MMF. Caveats include mode-adapter cables and other funk to interface LX4 to mmf. Long-reach single-carrier (ie. single optical channel/frequency) 10 gig over MMF salso has a 'spec' (10G-LRM), but I'm not personally familiar enough with vendors to offer anything useful or practical. > One minor consideration is usually SM optics are stronger, so don't forget > attenuation if it's a short distance or you might burn out your pricey new > optics! I would invite folks to examine the various gradations of gig and 10 gig LR/ER/ZR devices. Pulled from a handy table at http://www.andovercg.com/datasheets/juniper-ethernet-pics.pdf, I submit for your consideration a summary of the powers across the various flavors of xenpak. Note the modest increases in launch power, while there are considerable and huge increases in sensitivity. 10-Gbps Gigabit Ethernet XENPAK, 1-port ? XENPAK pluggable optics (SR, LR, ER, ZR types) ? SR optical interface (IEEE 802.3ae compliant) ? Average launch power: -4.5 through -1 dBm ? Receiver saturation: -1.0 dBm ? Receiver sensitivity: -7.5 dBm ? LR optical interface (IEEE 802.3ae compliant) ? Average launch power: -4 through 0.5 dBm ? Receiver saturation: 0.5 dBm ? Receiver sensitivity: -10.3 dBm ? ER optical interface (IEEE 802.3ae compliant) ? Average launch power: -4.7 through 4 dBm ? Receiver saturation: 1 dBm ? Receiver sensitivity: -11.3 dBm ? ZR optical interface (IEEE 802.3ae compliant) ? Average launch power: 0 through 4 dBm ? Receiver saturation: -7 dBm ? Receiver sensitivity: -24 dBm -tk From bicknell at ufp.org Thu Dec 10 23:21:19 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 10 Dec 2009 15:21:19 -0800 Subject: More ASN collissions In-Reply-To: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> Message-ID: <20091210232119.GA9697@ussenterprise.ufp.org> In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote: > As always, good research by renesys. > > http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml As already commented on the blog... ISC had a data entry error on an ASN for our site in Fiji. There was no RIR mixup, it was purely an error on our part. This was then further propogated when scripts we had generated routing registry objects and pushed them out. We're already down the path of fixing it, and the error will be corrected soon. We would like to thank Renesys for bringing it to our attention. While the ARIN / RIPE mixup in the 17xx range has caused a lot of people to go looking for a smoking gun I think Renesys has proved there is in fact no cause for alarm. 40,000+ ASN's in use and only two for which there is even a question. 0.005's of a percent error rate in a global system is quite good. To also answer one of the questions posed in the blog. It is only recently (I think about 4 months ago) ISC fully scripted it's routing registry updates, which is what caused the AS35686 to ISC entry in the RIPE DB. Prior to that there would have been no ISC entry anywhere, as it was not assigned to ISC; thus no other party would have checked it. I can't comment on if ISC checked if the ASN was in the APNIC database properly when they received it or not, but noting it was a data entry typo it is entirely likely the database was checked with the proper ASN, and then the data was miss-entered into internal systems. I would be very interested to know if something similar happened with AS3745. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mloftis at wgops.com Fri Dec 11 00:56:59 2009 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 10 Dec 2009 17:56:59 -0700 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> Message-ID: --On Wednesday, December 02, 2009 6:23 PM -0800 Mehmet Akcin wrote: > Would you consider Juniper SSG5 as a Consumer Grade router? > > They do IPv6 and they are pretty good in general, and cheap as well. > Not as usable in the consumer space due to lack of UPnP (and Juniper is NOT interested in implementing it). They also lack some other customer friendly features. Price point is also probably 3x-5x what most are willing to pay for CPE. From johnl at iecc.com Fri Dec 11 01:21:02 2009 From: johnl at iecc.com (John Levine) Date: 11 Dec 2009 01:21:02 -0000 Subject: Arrogant RBL list maintainers In-Reply-To: Message-ID: <20091211012102.13968.qmail@simone.iecc.com> >thing is that it's illegal to maintain a database with "personal details" >which ip addresses according to various german courts are (don't ask.. I've actually looked at some of the German decisions, and I didn't see anything that would be a problem for DNSBLs But if you're getting legal advice from the same wizard who told you to do this: >Confidential: Please be advised that the information contained in this >email message, including all attached documents or files, is privileged >and confidential and is intended only for the use of the individual or >individuals addressed. Any other use, dissemination, distribution or >copying of this communication is strictly prohibited. I can understand why your impressions of the law would be so mistaken. R's, John From kmedcalf at dessus.com Fri Dec 11 02:16:57 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 10 Dec 2009 21:16:57 -0500 Subject: Linux shaping packet loss In-Reply-To: Message-ID: <93a11f02f768f54e8d78395fc17e20a1@mail.dessus.com> > Autoneg is a required part of the gig E specification so you'd only be > causing yourself trouble by turning it off. (I don't know if > it'll also break automatic MDI/MDI-X (crossover) configuration, for > an example of something that's nice to have.) At least on 450x series enhanced linecards, disabling autonegotiation disables auto MDI/MDI-X. You have to enable autonegotiation but you can provide specified offered and acceptable parameters, eg: "speed auto 100" to enable autonegotiation but only allow negotiation of 100 mb. (speed auto 10 100 / speed auto 1000 / etc) -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From wilhelm at ripe.net Fri Dec 11 02:42:52 2009 From: wilhelm at ripe.net (Rene Wilhelm) Date: Fri, 11 Dec 2009 03:42:52 +0100 Subject: More ASN collissions In-Reply-To: <20091210232119.GA9697@ussenterprise.ufp.org> References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> <20091210232119.GA9697@ussenterprise.ufp.org> Message-ID: <4B21B1AC.60908@ripe.net> Leo Bicknell wrote: > In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote: >> As always, good research by renesys. >> >> http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml > [...] > I would be very interested to know if something similar happened > with AS3745. > AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at whois.ripe.net is a user created object in the RIPE routing registry, not an assignment by RIPE NCC. The record in the ARIN database states: OrgName: Perot Systems OrgID: PEROTS-16 Address: 3800 Hamlin Road City: Auburn Hills StateProv: MI PostalCode: 48326 Country: US ASNumber: 3745 ASName: VWAG-AS ASHandle: AS3745 Comment: RegDate: 1994-08-01 Updated: 2001-03-29 RTechHandle: AP105-ARIN RTechName: Accounts Payable, Mr. E. Zeltzer RTechPhone: +1-248-754-5803 RTechEmail: domainmaster at vw.com Both the ASName and RTechEmail already point to Volkswagen (VW). Querying whois.arin.net for AP105-ARIN shows the full contact info: Name: Accounts Payable, Mr. E. Zeltzer Handle: AP105-ARIN Company: Volkswagen of America Address: Volkswagen of America Address: 3800 Hamlin Road City: Auburn Hills StateProv: MI PostalCode: 48326 Country: US Comment: RegDate: 1998-11-25 Updated: 2001-03-29 Phone: +1-248-754-5803 (Office) Email: domainmaster at vw.com So Perot Systems seems to have received this AS in 1994 for Volkswagen America. REX, RIPE NCC's prototype Resource EXplainer, shows AS3745 has been advertising 193.23.96.0/24 and 193.23.104.0/24 (both assigned to Volkswagen AG, Germany) as long as we have routing history from RIS. In 2001 and later years parts of 194.114/17 followed. See http://albatross.ripe.net/cgi-bin/rex.pl?res=AS3745&stime=2000-01-01&etime=2009-12-09&type=all The RIPE DB lists AS3745 as "Volkswagen AG, Wolfsburg, Germany". Although not consistent with the registration info in ARIN, you can at least see how, in the 1990s, the German parent company started to use the assignment made to its American subsidiary. The odd one in the current set of prefixes advertised by AS3745 appears to be 148.9.64.0/18 If you click on this prefix in the REX listing for AS3745 you see this announcement is in the routing tables since June 2008. The encompassing 148.9/16 was originated by AS5089 from January 2003 to January 2004 and by AS1294 for some short periods in 2000 and 2001. A next click on the "Resource Holder" (near the top of the page) shows the matching record in the ARIN database to be 148.9.0.0 - 148.9.255.255 a direct assignment to Perot Systems, Plano, TX Finally, a click on the "DNS and Reverse DNS" in REX removes any doubt the /18 is somehow related to Volkswagen: for November 2009 we found one reverse DNS entry in the CAIDA IPv4 DNS-names dataset[*] pointing to a domain under .gov In summary, AS3745 is indeed used by two different organizations, but it's the users not the RIRs who created this situation. -- Rene [*] http://www.caida.org/data/active/ipv4_dnsnames_dataset.xml From owen at delong.com Fri Dec 11 02:44:35 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Dec 2009 18:44:35 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> Message-ID: <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> On Dec 10, 2009, at 4:56 PM, Michael Loftis wrote: > > > --On Wednesday, December 02, 2009 6:23 PM -0800 Mehmet Akcin > wrote: > >> Would you consider Juniper SSG5 as a Consumer Grade router? >> >> They do IPv6 and they are pretty good in general, and cheap as well. >> > > Not as usable in the consumer space due to lack of UPnP (and Juniper > is NOT interested in implementing it). They also lack some other > customer friendly features. > UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. You don't need UPnP if you'r not doing NAT. > Price point is also probably 3x-5x what most are willing to pay for > CPE. Yep. Side-note, SRX-100 is the new SSG-5 equivalent and it's JunOS instead of ScreenOS. Nice box. Owen From ml at t-b-o-h.net Fri Dec 11 04:00:53 2009 From: ml at t-b-o-h.net (Tuc) Date: Thu, 10 Dec 2009 23:00:53 -0500 (EST) Subject: Looking for MIX/NOTA members Message-ID: <2364.24.161.61.119.1260504053.squirrel@webmail.tucs-beachin-obx-house.com> Hi, I know this is NAnog (Which NOTA may qualify for being in Miami) but I'm in need of help for MIX too. I'm involved with a client that had their range advertised by another AS. We were told by all parties involved that it has stopped, but I still seem to be seeing it on RIPE's MIX and NOTA looking glass. If anyone knows LG's other than RIPE that have access into MIX/NOTA (I did try HE.NET and PCH.NET, they didn't come up with the information I'm looking for) or can do a "sho ip bgp regex _13913$" and email me PRIVATELY, I'd appreciate. Thanks, Tuc From cmadams at hiwaay.net Fri Dec 11 04:08:49 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 10 Dec 2009 22:08:49 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> Message-ID: <20091211040849.GB1145061@hiwaay.net> Once upon a time, Owen DeLong said: > UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. > > You don't need UPnP if you'r not doing NAT. You need UPnP for a stateful firewall, whether it is mangling packets with NAT or not. I have an Xbox 360 behind an SSG-5 with no NAT, and I can't play some on-line games unless I open up the Xbox IP in the SSG. You can debate whether UPnP is the correct solution, but some solution is needed (even with IPv6) as long as stateful firewalls exist. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ops.lists at gmail.com Fri Dec 11 05:37:37 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 11 Dec 2009 11:07:37 +0530 Subject: Qwest mail admin contact? In-Reply-To: References: Message-ID: Related to any of these? http://www.spamhaus.org/sbl/listings.lasso?isp=data102.com Or maybe this - http://www.spamhaus.org/sbl/sbl.lasso?query=SBL51908 $ whois -h whois.cymru.com 128.168.0.0/16 AS | IP | AS Name 33302 | 128.168.0.0 | ONS-COS - Data 102, LLC Whatever the issue is, it might make sense for you to fix it before you contact Qwest - they'd be more likely to respond that way. On Fri, Dec 11, 2009 at 1:06 AM, randal k wrote: > If one is listening, can I get a Qwest mail admin to drop me a line > off-list? Numerous emails to postmaster, abuse, relay, etc all seem to be > deadends. -- Suresh Ramasubramanian (ops.lists at gmail.com) From math at sizone.org Fri Dec 11 06:42:31 2009 From: math at sizone.org (Ken Chase) Date: Fri, 11 Dec 2009 01:42:31 -0500 Subject: news from Google In-Reply-To: <20091203224841.GR8192@sizone.org> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <20091203224841.GR8192@sizone.org> Message-ID: <20091211064231.GB24504@sizone.org> topically related, it's actually news from Mozilla: http://www.computerworld.com/s/article/9142106/Mozilla_exec_suggests_Firefox_users_move_to_Bing_cites_Google_privacy_stance?source=rss_news from the horse's mouth, as it were. So, how bout that DNS. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From surfer at mauigateway.com Fri Dec 11 07:14:59 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 10 Dec 2009 23:14:59 -0800 Subject: news from Google Message-ID: <20091210231459.55C6B038@resin09.mta.everyone.net> --- math at sizone.org wrote: From: Ken Chase topically related, it's actually news from Mozilla: http://www.computerworld.com/s/article/9142106/Mozilla_exec_suggests_Firefox_users_move_to_Bing_cites_Google_privacy_stance?source=rss_news from the horse's mouth, as it were. So, how bout that DNS. -------------------------------------------- Um, yeah. Them there micro$loth folks is WAAAAYYYY more privacy oriented than them google rascals. DBS scott From newton at internode.com.au Fri Dec 11 08:09:36 2009 From: newton at internode.com.au (Mark Newton) Date: Fri, 11 Dec 2009 18:39:36 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> Message-ID: <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> On 11/12/2009, at 1:14 PM, Owen DeLong wrote: > > You don't need UPnP if you'r not doing NAT. You kinda do if you're using a stateful firewall with a "deny everything that shouldn't be accepted" policy. UPnP (or something like it) would have to tell the firewall what should be accepted. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From nenolod at systeminplace.net Fri Dec 11 08:36:59 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 11 Dec 2009 02:36:59 -0600 Subject: Is there anyone from ASPEWS on this list? Message-ID: <1260520619.4148.99.camel@petrie> Hi, ASPEWS is listing 216.83.32.0/20 as being associated with the whole Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being involved, nor the provider that belongs to. So it'd be cool if I could you know, talk to someone who has involvement with that, because frankly, I do not see why it is listed as having any involvement with Atrivo. Also, the fact that Atrivo is *dead* and this stuff is still listed means that anyone who gets those blocks from ARIN next are basically screwed. Which kind of sucks. William From david.iluvatar at gmail.com Fri Dec 11 08:59:22 2009 From: david.iluvatar at gmail.com (=?ISO-8859-1?Q?David_P=E9rez?=) Date: Fri, 11 Dec 2009 09:59:22 +0100 Subject: About IPv6 performance Message-ID: Dear all: I've been searching the web for tests or reports about how performance in current IP boxes (core routers, BRAS, edge routers...) is impacted when enabling IPv6, but haven't been able to find anything useful, but a couple of reports dated in 2002 and 2004: http://www.lightreading.com/document.asp?doc_id=63606 http://www.ipv6-tf.com.pt/documentos/geral/bii_v6_interop.pdf I already assume some impacts in memory for IPv6 prefixes, or CPU usage... but don't clearly see other impacts (number of sessions...). I know performance will mainly depend on which service structure is selected (PPPoE, DHCPv6...), but... could anybody point to a report that deals with all these issues? Thank you, David P?rez. From rdobbins at arbor.net Fri Dec 11 09:08:49 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 11 Dec 2009 09:08:49 +0000 Subject: About IPv6 performance In-Reply-To: References: Message-ID: <50183560-A422-4A63-8094-98FFB3167547@arbor.net> On Dec 11, 2009, at 3:59 PM, David P?rez wrote: > could anybody point to a report that deals with all these issues? Also be sure to pay attention to IPv4/IPv6 feature parity gaps. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From fweimer at bfk.de Fri Dec 11 09:30:02 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 11 Dec 2009 09:30:02 +0000 Subject: More ASN collissions In-Reply-To: <4B21B1AC.60908@ripe.net> (Rene Wilhelm's message of "Fri\, 11 Dec 2009 03\:42\:52 +0100") References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> <20091210232119.GA9697@ussenterprise.ufp.org> <4B21B1AC.60908@ripe.net> Message-ID: <82638dhn8l.fsf@mid.bfk.de> * Rene Wilhelm: > AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at > whois.ripe.net is a user created object in the RIPE routing registry, not > an assignment by RIPE NCC. How can you tell one from the other? Is the lack of an org: attribute reliable? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon.perreault at viagenie.ca Fri Dec 11 12:41:59 2009 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 11 Dec 2009 07:41:59 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> Message-ID: <4B223E17.3040201@viagenie.ca> Mark Newton wrote, on 2009-12-11 03:09: > You kinda do if you're using a stateful firewall with a "deny > everything that shouldn't be accepted" policy. UPnP (or something > like it) would have to tell the firewall what should be accepted. That's putting the firewall at the mercy of viruses, worms, etc. The firewall shouldn't trust anything else to tell it what is good and bad traffic. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From Valdis.Kletnieks at vt.edu Fri Dec 11 13:06:53 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Dec 2009 08:06:53 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: Your message of "Fri, 11 Dec 2009 07:41:59 EST." <4B223E17.3040201@viagenie.ca> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> <4B223E17.3040201@viagenie.ca> Message-ID: <5008.1260536813@localhost> On Fri, 11 Dec 2009 07:41:59 EST, Simon Perreault said: > Mark Newton wrote, on 2009-12-11 03:09: > > You kinda do if you're using a stateful firewall with a "deny > > everything that shouldn't be accepted" policy. UPnP (or something > > like it) would have to tell the firewall what should be accepted. > > That's putting the firewall at the mercy of viruses, worms, etc. The firewall > shouldn't trust anything else to tell it what is good and bad traffic. What you suggest? Manual configuration? We *know* that if a worm puts up a popup that says "Enable port 33493 on your firewall for naked pics of.." that port 33493 will get opened anyhow, so we may as well automate the process and save everybody the effort. Redesigning the security so that human intervention is required isn't worth the effort, because the black hats are much better at convincing people to do something than the white hats are at teaching them why they shouldn't do it. Probably because we don't teach with naked pics of... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From simon.perreault at viagenie.ca Fri Dec 11 13:26:57 2009 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 11 Dec 2009 08:26:57 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <5008.1260536813@localhost> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> <4B223E17.3040201@viagenie.ca> <5008.1260536813@localhost> Message-ID: <4B2248A1.9000607@viagenie.ca> Valdis.Kletnieks at vt.edu wrote, on 2009-12-11 08:06: > On Fri, 11 Dec 2009 07:41:59 EST, Simon Perreault said: >> Mark Newton wrote, on 2009-12-11 03:09: >>> You kinda do if you're using a stateful firewall with a "deny >>> everything that shouldn't be accepted" policy. UPnP (or something >>> like it) would have to tell the firewall what should be accepted. >> >> That's putting the firewall at the mercy of viruses, worms, etc. The firewall >> shouldn't trust anything else to tell it what is good and bad traffic. > > What you suggest? That depends on the circumstances. UPnP is fine in some circumstances and wrong in others. > We *know* that if a worm puts up > a popup that says "Enable port 33493 on your firewall for naked pics of.." > that port 33493 will get opened anyhow, so we may as well automate the > process and save everybody the effort. Not if the victim doesn't have rights on the firewall (e.g. enterprise). Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jgreco at ns.sol.net Fri Dec 11 13:36:39 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 11 Dec 2009 07:36:39 -0600 (CST) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B223E17.3040201@viagenie.ca> from "Simon Perreault" at Dec 11, 2009 07:41:59 AM Message-ID: <200912111336.nBBDadtt073162@aurora.sol.net> > Mark Newton wrote, on 2009-12-11 03:09: > > You kinda do if you're using a stateful firewall with a "deny > > everything that shouldn't be accepted" policy. UPnP (or something > > like it) would have to tell the firewall what should be accepted. > > That's putting the firewall at the mercy of viruses, worms, etc. The firewall > shouldn't trust anything else to tell it what is good and bad traffic. Everyone knows a NAT gateway isn't really a firewall, except more or less accidentally. There's no good way to provide a hardware firewall in an average residential environment that is not a disaster waiting to happen. If you make it "smart" (i.e. UPnP) then it will of course autoconfigure itself for an appropriate virus. However, your average home user often doesn't change their $FOOGEAR password from the default of 1234, and it is reasonable to assume that at some point, viruses will ship with some minimal knowledge of how to "manually" fix their networking environment. Or better yet? Runs a password cracker until it figures it out, since the admin interfaces on these things are rarely hardened. If you actually /do/ a really good firewall, then of course users find it "hard to use" and your company takes a support hit, maybe gets a bad reputation, etc. There's no winning. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From simon.perreault at viagenie.ca Fri Dec 11 13:41:01 2009 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 11 Dec 2009 08:41:01 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <200912111336.nBBDadtt073162@aurora.sol.net> References: <200912111336.nBBDadtt073162@aurora.sol.net> Message-ID: <4B224BED.3070904@viagenie.ca> Joe Greco wrote, on 2009-12-11 08:36: > Everyone knows a NAT gateway isn't really a firewall, except more or less > accidentally. There's no good way to provide a hardware firewall in an > average residential environment that is not a disaster waiting to happen. > > If you make it "smart" (i.e. UPnP) then it will of course autoconfigure > itself for an appropriate virus. > > However, your average home user often doesn't change their $FOOGEAR > password from the default of 1234, and it is reasonable to assume that > at some point, viruses will ship with some minimal knowledge of how to > "manually" fix their networking environment. Or better yet? Runs a > password cracker until it figures it out, since the admin interfaces > on these things are rarely hardened. > > If you actually /do/ a really good firewall, then of course users find > it "hard to use" and your company takes a support hit, maybe gets a > bad reputation, etc. > > There's no winning. Agreed. We have thus come to the conclusion that there shouldn't be a NAT-like firewall in IPv6 home routers. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jmamodio at gmail.com Fri Dec 11 14:01:24 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 08:01:24 -0600 Subject: news from Google In-Reply-To: <20091210231459.55C6B038@resin09.mta.everyone.net> References: <20091210231459.55C6B038@resin09.mta.everyone.net> Message-ID: <202705b0912110601o3cc440dftf352a171f6cf5b56@mail.gmail.com> > Um, yeah. ?Them there micro$loth folks is WAAAAYYYY more privacy oriented than them google rascals. Well, we still have hope that bing logs are stored in windows servers making them more difficult to access or even retain after the seasonal color of the screen of death. The article is not worse than some messages being circulated on other lists citing privacy concerns because of Chrome dns-prefetch where evil Google will not only know where you go or what you are looking for, they will also know your intentions when with your mouse you hover over a link (according to Roskind there may be some cases where chrome sends a query when you do so). Ohhh well ... Cheers Jorge From swmike at swm.pp.se Fri Dec 11 14:10:05 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 11 Dec 2009 15:10:05 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B224BED.3070904@viagenie.ca> References: <200912111336.nBBDadtt073162@aurora.sol.net> <4B224BED.3070904@viagenie.ca> Message-ID: On Fri, 11 Dec 2009, Simon Perreault wrote: > We have thus come to the conclusion that there shouldn't be a NAT-like > firewall in IPv6 home routers. No, the conclusion is that for IPv6 there should be something that behaves much like current IPv4 NAT boxes, ie do stateful firewalling and only let internal computers initiate conenctions outgoing, do protocol sniffing for allowing incoming new connections, and use some uPNP like method to do temporary firewall openings. This is the social contract of the current home gateway ecosystem, and intiially IPv6 devices need to replicate this. Last I checked, this was the conclusion of multiple IPv6 related IETF working groups, check out "homegate" and "v6ops" WGs for instance. -- Mikael Abrahamsson email: swmike at swm.pp.se From cmadams at hiwaay.net Fri Dec 11 14:10:57 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 11 Dec 2009 08:10:57 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <200912111336.nBBDadtt073162@aurora.sol.net> References: <4B223E17.3040201@viagenie.ca> <200912111336.nBBDadtt073162@aurora.sol.net> Message-ID: <20091211141057.GB1269284@hiwaay.net> Once upon a time, Joe Greco said: > Everyone knows a NAT gateway isn't really a firewall, except more or less > accidentally. There's no good way to provide a hardware firewall in an > average residential environment that is not a disaster waiting to happen. I don't think hardware vs. software makes a "real" firewall. A NAT gateway has to have all the basic functionality of a stateful firewall, plus packet mangling. Typical home NAT gateways don't have all the configurability of an SSG or such, but the same basic functionality is there. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jgreco at ns.sol.net Fri Dec 11 14:34:08 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 11 Dec 2009 08:34:08 -0600 (CST) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091211141057.GB1269284@hiwaay.net> from "Chris Adams" at Dec 11, 2009 08:10:57 AM Message-ID: <200912111434.nBBEY8TI076684@aurora.sol.net> > Once upon a time, Joe Greco said: > > Everyone knows a NAT gateway isn't really a firewall, except more or less > > accidentally. There's no good way to provide a hardware firewall in an > > average residential environment that is not a disaster waiting to happen. > > I don't think hardware vs. software makes a "real" firewall. A NAT > gateway has to have all the basic functionality of a stateful firewall, > plus packet mangling. Typical home NAT gateways don't have all the > configurability of an SSG or such, but the same basic functionality is > there. You can blow away the firmware of your NAT gateway and load something like DD-WRT. This gives you a hardware firewall (an external hardware device that acts as a deliberate firewall; i.e. you can firewall 1.2.3.4 from 5.6.7.8). It is not filtering packets in silicon, which is an alternate definition for "hardware firewall" that many in this group could use, but in common usage, it is the distinctness from the protected host(s) and the ability to implement typical firewalling rules and methods, with or _without_ NAT, that makes it a "hardware firewall." Your existing NAT gateway firmware may well be based on Linux and may have portions implemented by a Linux firewalling subsystem, but in most cases, you cannot really drill down to any significant level of detail, and quite frequently the main "anti-forwarding" protection offered is simply the difficulty in surmounting the artificial barrier created by the NAT addressing discontinuity. While this might technically count as "the same basic functionality," functionality that cannot be accessed or used might as well not be there for the purposes of this discussion. So I'll pass on considering your average NAT gateway as a "hardware firewall." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jmamodio at gmail.com Fri Dec 11 15:58:44 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 09:58:44 -0600 Subject: news from Google In-Reply-To: <20091211064231.GB24504@sizone.org> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <4B18080E.7090001@rollernet.us> <4B1827F7.2040000@2mbit.com> <20091203220722.GP8192@sizone.org> <5cc1e3d70912031420v1a797bf0t43575a4af6ea2d93@mail.gmail.com> <20091203224841.GR8192@sizone.org> <20091211064231.GB24504@sizone.org> Message-ID: <202705b0912110758i1a5e566bhe5d6a7b93d3edb5b@mail.gmail.com> Another one for the collection http://www.circleid.com/posts/dot_google_before_christmas/ Cheers Jorge From ALanstein at FireEye.com Fri Dec 11 17:55:46 2009 From: ALanstein at FireEye.com (Alex Lanstein) Date: Fri, 11 Dec 2009 09:55:46 -0800 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <1260520619.4148.99.camel@petrie> References: <1260520619.4148.99.camel@petrie> Message-ID: <60B0F2124D07B942988329B5B7CA393D020BE87537@mail2.FireEye.com> >>>Also, the fact that Atrivo is *dead* and this >>>stuff is still listed means that anyone who gets >>>those blocks from ARIN next are basically screwed Why would you say Atrivo is dead? root at localhost --- {~} nslookup www.googleadservices.com 85.255.114.83 Server: 85.255.114.83 Address: 85.255.114.83#53 Name: www.googleadservices.com Address: 67.210.14.113 root at localhost --- {~} root at localhost --- {~} nslookup www.googleadservices.com 8.8.4.4 Server: 8.8.4.4 Address: 8.8.4.4#53 Non-authoritative answer: www.googleadservices.com canonical name = adservices.google.com. adservices.google.com canonical name = adservices.l.google.com. Name: adservices.l.google.com Address: 74.125.19.96 Regards, Alex Lanstein FireEye, Inc. ________________________________________ From: William Pitcock [nenolod at systeminplace.net] Sent: Friday, December 11, 2009 3:36 AM To: nanog at nanog.org Subject: Is there anyone from ASPEWS on this list? Hi, ASPEWS is listing 216.83.32.0/20 as being associated with the whole Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being involved, nor the provider that belongs to. So it'd be cool if I could you know, talk to someone who has involvement with that, because frankly, I do not see why it is listed as having any involvement with Atrivo. Also, the fact that Atrivo is *dead* and this stuff is still listed means that anyone who gets those blocks from ARIN next are basically screwed. Which kind of sucks. William -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From cscora at apnic.net Fri Dec 11 18:36:22 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Dec 2009 04:36:22 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200912111836.nBBIaMaJ002608@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 12 Dec, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 306287 Prefixes after maximum aggregation: 142533 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 150582 Total ASes present in the Internet Routing Table: 32907 Prefixes per ASN: 9.31 Origin-only ASes present in the Internet Routing Table: 28575 Origin ASes announcing only one prefix: 13946 Transit ASes present in the Internet Routing Table: 4332 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 994 Unregistered ASNs in the Routing Table: 135 Number of 32-bit ASNs allocated by the RIRs: 351 Prefixes from 32-bit ASNs in the Routing Table: 301 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 162 Number of addresses announced to Internet: 2160649728 Equivalent to 128 /8s, 200 /16s and 230 /24s Percentage of available address space announced: 58.3 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.3 Total number of prefixes smaller than registry allocations: 147120 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 73696 Total APNIC prefixes after maximum aggregation: 25498 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 70372 Unique aggregates announced from the APNIC address blocks: 31050 APNIC Region origin ASes present in the Internet Routing Table: 3895 APNIC Prefixes per ASN: 18.07 APNIC Region origin ASes announcing only one prefix: 1062 APNIC Region transit ASes present in the Internet Routing Table: 607 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 483880224 Equivalent to 28 /8s, 215 /16s and 109 /24s Percentage of available APNIC address space announced: 80.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 128493 Total ARIN prefixes after maximum aggregation: 67389 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103031 Unique aggregates announced from the ARIN address blocks: 38828 ARIN Region origin ASes present in the Internet Routing Table: 13397 ARIN Prefixes per ASN: 7.69 ARIN Region origin ASes announcing only one prefix: 5182 ARIN Region transit ASes present in the Internet Routing Table: 1322 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 733616416 Equivalent to 43 /8s, 186 /16s and 25 /24s Percentage of available ARIN address space announced: 64.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70531 Total RIPE prefixes after maximum aggregation: 41263 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 63953 Unique aggregates announced from the RIPE address blocks: 42662 RIPE Region origin ASes present in the Internet Routing Table: 13876 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7219 RIPE Region transit ASes present in the Internet Routing Table: 2088 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 406627904 Equivalent to 24 /8s, 60 /16s and 166 /24s Percentage of available RIPE address space announced: 75.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26775 Total LACNIC prefixes after maximum aggregation: 6482 LACNIC Deaggregation factor: 4.13 Prefixes being announced from the LACNIC address blocks: 25094 Unique aggregates announced from the LACNIC address blocks: 13714 LACNIC Region origin ASes present in the Internet Routing Table: 1220 LACNIC Prefixes per ASN: 20.57 LACNIC Region origin ASes announcing only one prefix: 390 LACNIC Region transit ASes present in the Internet Routing Table: 201 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 69110272 Equivalent to 4 /8s, 30 /16s and 138 /24s Percentage of available LACNIC address space announced: 68.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5929 Total AfriNIC prefixes after maximum aggregation: 1581 AfriNIC Deaggregation factor: 3.75 Prefixes being announced from the AfriNIC address blocks: 4339 Unique aggregates announced from the AfriNIC address blocks: 1526 AfriNIC Region origin ASes present in the Internet Routing Table: 335 AfriNIC Prefixes per ASN: 12.95 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 72 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 14305536 Equivalent to 0 /8s, 218 /16s and 73 /24s Percentage of available AfriNIC address space announced: 42.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1780 7509 461 Korea Telecom (KIX) 17488 1459 143 132 Hathway IP Over Cable Interne 4755 1278 295 147 TATA Communications formerly 4134 1012 19458 393 CHINANET-BACKBONE 9583 1007 75 500 Sify Limited 18101 992 204 34 Reliance Infocom Ltd Internet 7545 917 198 98 TPG Internet Pty Ltd 17974 849 270 58 PT TELEKOMUNIKASI INDONESIA 9829 832 674 22 BSNL National Internet Backbo 24560 810 294 176 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4232 3895 311 bellsouth.net, inc. 4323 3770 1068 401 Time Warner Telecom 1785 1791 699 135 PaeTec Communications, Inc. 7018 1588 5807 1031 AT&T WorldNet Services 20115 1525 1483 666 Charter Communications 2386 1293 632 933 AT&T Data Communications Serv 3356 1202 10945 426 Level 3 Communications, LLC 6478 1169 253 330 AT&T Worldnet Services 11492 1145 222 14 Cable One 22773 1123 2600 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 516 98 207 Evolva Telecom 9198 471 138 12 Kazakhtelecom Data Network Ad 35805 465 40 5 United Telecom of Georgia 3292 447 1903 392 TDC Tele Danmark 702 418 1837 336 UUNET - Commercial IP service 8551 377 354 41 Bezeq International 8866 375 110 23 Bulgarian Telecommunication C 3320 361 7068 307 Deutsche Telekom AG 3215 350 3160 112 France Telecom Transpac 3301 347 1411 303 TeliaNet Sweden Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1587 2899 231 UniNet S.A. de C.V. 10620 1002 223 136 TVCABLE BOGOTA 28573 821 669 84 NET Servicos de Comunicao S.A 7303 665 351 96 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 473 308 59 Instituto Costarricense de El 11172 446 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 432 858 29 Telecomunicacoes da Bahia S.A 6503 430 163 181 AVANTEL, S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1032 444 8 TEDATA 24863 709 143 52 LINKdotNET AS number 3741 273 857 233 The Internet Solution 2018 178 196 100 Tertiary Education Network 6713 175 167 12 Itissalat Al-MAGHRIB 29571 152 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 5536 121 8 18 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 33776 112 6 14 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4232 3895 311 bellsouth.net, inc. 4323 3770 1068 401 Time Warner Telecom 1785 1791 699 135 PaeTec Communications, Inc. 4766 1780 7509 461 Korea Telecom (KIX) 7018 1588 5807 1031 AT&T WorldNet Services 8151 1587 2899 231 UniNet S.A. de C.V. 20115 1525 1483 666 Charter Communications 17488 1459 143 132 Hathway IP Over Cable Interne 2386 1293 632 933 AT&T Data Communications Serv 4755 1278 295 147 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3770 3369 Time Warner Telecom 1785 1791 1656 PaeTec Communications, Inc. 8151 1587 1356 UniNet S.A. de C.V. 17488 1459 1327 Hathway IP Over Cable Interne 4766 1780 1319 Korea Telecom (KIX) 4755 1278 1131 TATA Communications formerly 11492 1145 1131 Cable One 22773 1123 1057 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1032 1024 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:65 /12:180 /13:379 /14:645 /15:1228 /16:10813 /17:5022 /18:8568 /19:17677 /20:21536 /21:21484 /22:27765 /23:27724 /24:160197 /25:937 /26:1160 /27:589 /28:235 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2768 4232 bellsouth.net, inc. 4323 2370 3770 Time Warner Telecom 4766 1431 1780 Korea Telecom (KIX) 1785 1256 1791 PaeTec Communications, Inc. 17488 1225 1459 Hathway IP Over Cable Interne 11492 1067 1145 Cable One 18566 1040 1059 Covad Communications 7018 954 1588 AT&T WorldNet Services 8452 928 1032 TEDATA 10620 907 1002 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 2:1 4:13 8:225 12:2057 13:9 15:22 16:3 17:5 20:37 24:1283 32:49 38:629 40:99 41:1830 43:1 44:3 46:1 47:21 52:6 55:2 56:2 57:24 58:648 59:654 60:446 61:1102 62:971 63:2009 64:3769 65:2372 66:4103 67:1779 68:1026 69:2824 70:686 71:232 72:1879 73:2 74:2037 75:190 76:361 77:835 78:599 79:407 80:935 81:811 82:465 83:442 84:535 85:1021 86:381 87:677 88:420 89:1566 90:63 91:2654 92:445 93:1114 94:1343 95:834 96:183 97:285 98:403 99:24 109:186 110:278 111:499 112:157 113:205 114:288 115:478 116:1079 117:592 118:371 119:809 120:144 121:833 122:1311 123:796 124:1018 125:1341 128:212 129:201 130:134 131:460 132:83 133:16 134:183 135:41 136:229 137:168 138:239 139:81 140:456 141:121 142:375 143:340 144:390 145:53 146:390 147:173 148:568 149:192 150:148 151:173 152:219 153:161 154:2 155:270 156:171 157:326 158:97 159:357 160:298 161:174 162:281 163:163 164:308 165:471 166:490 167:392 168:753 169:159 170:563 171:42 172:1 173:391 174:442 180:205 183:162 184:3 186:194 187:166 188:1058 189:654 190:3401 192:5718 193:4321 194:3371 195:2780 196:1196 198:3565 199:3383 200:5247 201:1433 202:7978 203:8286 204:3988 205:2167 206:2407 207:3046 208:3962 209:3383 210:2562 211:1147 212:1645 213:1642 214:247 215:58 216:4423 217:1373 218:480 219:455 220:1146 221:448 222:300 End of report From nenolod at systeminplace.net Fri Dec 11 20:35:20 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 11 Dec 2009 14:35:20 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <60B0F2124D07B942988329B5B7CA393D020BE87537@mail2.FireEye.com> References: <1260520619.4148.99.camel@petrie> <60B0F2124D07B942988329B5B7CA393D020BE87537@mail2.FireEye.com> Message-ID: <1260563720.4148.116.camel@petrie> On Fri, 2009-12-11 at 09:55 -0800, Alex Lanstein wrote: > >>>Also, the fact that Atrivo is *dead* and this > >>>stuff is still listed means that anyone who gets > >>>those blocks from ARIN next are basically screwed > > Why would you say Atrivo is dead? > > root at localhost --- {~} nslookup www.googleadservices.com 85.255.114.83 > Server: 85.255.114.83 > Address: 85.255.114.83#53 > > Name: www.googleadservices.com > Address: 67.210.14.113 That is Cernal, and it is hosted in Russia now. Cernal and Atrivo are two different entities, Atrivo used to host Cernal, but now they have different hosting arrangements. Can people get a clue and understand this very critical difference? Thanks. William From sethm at rollernet.us Fri Dec 11 20:36:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 12:36:49 -0800 Subject: news from Google In-Reply-To: <20091210231459.55C6B038@resin09.mta.everyone.net> References: <20091210231459.55C6B038@resin09.mta.everyone.net> Message-ID: <4B22AD61.8060303@rollernet.us> Scott Weeks wrote: > --- math at sizone.org wrote: > From: Ken Chase > > topically related, it's actually news from Mozilla: > http://www.computerworld.com/s/article/9142106/Mozilla_exec_suggests_Firefox_users_move_to_Bing_cites_Google_privacy_stance?source=rss_news > from the horse's mouth, as it were. > > So, how bout that DNS. > -------------------------------------------- > > > Um, yeah. Them there micro$loth folks is WAAAAYYYY more privacy oriented than them google rascals. > It's better than the "maybe you shouldn't be doing things you don't want people to know about" statement. That right there gives me some insight on where Google wants to go in the future with privacy. ~Seth From richard at bennett.com Fri Dec 11 20:42:42 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 11 Dec 2009 12:42:42 -0800 Subject: news from Google In-Reply-To: <4B22AD61.8060303@rollernet.us> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> Message-ID: <4B22AEC2.8030903@bennett.com> Microsoft just wants your cash, but Google wants your personal information so they can sell it over and over again. The entire Google business model is at odds with notions of personal privacy, so it's not even a question of the occasional excess on their part. Schmidt did what Michael Kinsey calls a gaffe: when a politician accidentally tells the truth. On 12/11/2009 12:36 PM, Seth Mattinen wrote: > Scott Weeks wrote: >> --- math at sizone.org wrote: >> From: Ken Chase >> >> topically related, it's actually news from Mozilla: >> http://www.computerworld.com/s/article/9142106/Mozilla_exec_suggests_Firefox_users_move_to_Bing_cites_Google_privacy_stance?source=rss_news >> >> from the horse's mouth, as it were. >> >> So, how bout that DNS. >> -------------------------------------------- >> >> >> Um, yeah. Them there micro$loth folks is WAAAAYYYY more privacy >> oriented than them google rascals. >> > > > It's better than the "maybe you shouldn't be doing things you don't > want people to know about" statement. That right there gives me some > insight on where Google wants to go in the future with privacy. > > ~Seth > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From sethm at rollernet.us Fri Dec 11 20:51:53 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 12:51:53 -0800 Subject: Google Privacy (was Re: news from Google) Message-ID: <4B22B0E9.40102@rollernet.us> Richard Bennett wrote: > Microsoft just wants your cash, but Google wants your personal > information so they can sell it over and over again. The entire Google > business model is at odds with notions of personal privacy, so it's not > even a question of the occasional excess on their part. Schmidt did what > Michael Kinsey calls a gaffe: when a politician accidentally tells the > truth. > Completely agree. I have always tried to tell people as much with Google, and they'd just point to the privacy policy, but now there's a juicy quote from the top of the food chain to counter with. Policy can (and will) change. ~Seth From beckman at angryox.com Fri Dec 11 20:57:10 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 11 Dec 2009 15:57:10 -0500 Subject: news from Google In-Reply-To: <4B22AD61.8060303@rollernet.us> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> Message-ID: On Fri, 11 Dec 2009, Seth Mattinen wrote: > It's better than the "maybe you shouldn't be doing things you don't want > people to know about" statement. That right there gives me some insight on > where Google wants to go in the future with privacy. At least Google seems to be honest about it. What does Bing say they keep about you when you search, not logged into your Passport account? IP + searches, date and time? And what do they actually do? What about Yahoo, now that they will use Bing? Or even AltaVista? How do we know the difference between the reality of what they do versus their Privacy Policy? If you aren't breaking the law, the government won't be looking for your data, and won't ask Google/Yahoo/Bing/AltaVista or other search companies for your data. If you ARE breaking the law, and you live in the US, you gotta be careful about what you do on the Internet, 'cause it all gets logged differently in different places. I find it REALLY HARD TO BELIEVE that NO OTHER SEARCH ENGINE COMPANY is retaining search data with IP address and maybe even account ID for a period of time. Not even Netflix, who thought they scrubbed the Netflix Prize Dataset, was able to rid the data of your personal information. http://www.cs.utexas.edu/~shmat/netflix-faq.html We're living in a world where every web request writes to a log file. Those log files live for days, weeks, years, even decades, and depend on the admins running the site, not the Privacy Policy. If you've ever visited my site, I've kept those logs for 10 years. Your IP, your browser, all that crap. This is the internet. You are logged at almost every action you take, somewhere. It's easy to archive those logs, and hard to cull them of "personally identifiable information." Because disk is cheap, we tend to horde data, not delete it. I'd like to see an independent source compare Mozilla's Privacy Policy to their actual practices, and see if they are truly leaders in personal privacy or just being hypocritical. And even if they do keep to their Privacy Policy, they provide a useful service, and I'm not breaking the law (that I know of). They can have my IP, what I search, what AddOns I've added, my crash signatures. At least I know what they have and that they will follow US Law and give it to authorities when properly requested. You don't get to have Privacy on the Internet. It's a fallacy. You have to work really hard to truly have privacy on the 'net. And lie a lot. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From sethm at rollernet.us Fri Dec 11 21:07:22 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 13:07:22 -0800 Subject: news from Google In-Reply-To: References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> Message-ID: <4B22B48A.1050008@rollernet.us> Peter Beckman wrote: > On Fri, 11 Dec 2009, Seth Mattinen wrote: > >> It's better than the "maybe you shouldn't be doing things you don't >> want people to know about" statement. That right there gives me some >> insight on where Google wants to go in the future with privacy. > > At least Google seems to be honest about it. > > What does Bing say they keep about you when you search, not logged into > your Passport account? IP + searches, date and time? And what do they > actually do? What about Yahoo, now that they will use Bing? Or even > AltaVista? How do we know the difference between the reality of what they > do versus their Privacy Policy? "We want your money" versus "we want your life". > If you aren't breaking the law, the government won't be looking for your > data, and won't ask Google/Yahoo/Bing/AltaVista or other search companies > for your data. > > If you ARE breaking the law, and you live in the US, you gotta be careful > about what you do on the Internet, 'cause it all gets logged differently > in different places. We are all likely breaking some law on a daily basis. > I find it REALLY HARD TO BELIEVE that NO OTHER SEARCH ENGINE COMPANY is > retaining search data with IP address and maybe even account ID for a > period of time. Not even Netflix, who thought they scrubbed the Netflix > Prize Dataset, was able to rid the data of your personal information. > > http://www.cs.utexas.edu/~shmat/netflix-faq.html > > We're living in a world where every web request writes to a log file. > Those log files live for days, weeks, years, even decades, and depend on > the admins running the site, not the Privacy Policy. If you've ever > visited my site, I've kept those logs for 10 years. Your IP, your > browser, all that crap. This is the internet. You are logged at almost > every action you take, somewhere. It's easy to archive those logs, and > hard to cull them of "personally identifiable information." Because disk > is cheap, we tend to horde data, not delete it. > > I'd like to see an independent source compare Mozilla's Privacy Policy to > their actual practices, and see if they are truly leaders in personal > privacy or just being hypocritical. > > And even if they do keep to their Privacy Policy, they provide a useful > service, and I'm not breaking the law (that I know of). They can have my > IP, what I search, what AddOns I've added, my crash signatures. At least > I know what they have and that they will follow US Law and give it to > authorities when properly requested. > > You don't get to have Privacy on the Internet. It's a fallacy. You have > to work really hard to truly have privacy on the 'net. And lie a lot. > Here's a pretty common line that Microsoft has that Google completely omits (or that I can't find): "We do not sell, rent, or lease our customer lists to third parties." ~Seth From surfer at mauigateway.com Fri Dec 11 21:13:48 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Dec 2009 13:13:48 -0800 Subject: news from Google Message-ID: <20091211131348.47DD15B3@resin14.mta.everyone.net> --- richard at bennett.com wrote: From: Richard Bennett Microsoft just wants your cash, but Google wants your personal information so they can sell it over and over again. The entire Google ------------------------------------------- You need to study up on your corporate competition tactics more... scott From surfer at mauigateway.com Fri Dec 11 21:35:15 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Dec 2009 13:35:15 -0800 Subject: news from Google Message-ID: <20091211133515.47DD1245@resin14.mta.everyone.net> --- beckman at angryox.com wrote: From: Peter Beckman At least Google seems to be honest about it. ---------------------------------------------- Yeah, trust them... --------------------------- What does Bing say they keep about you when you search, not logged into your Passport account? IP + searches, date and time? And what do they actually do? --------------------------- NOW you're getting warm. What IS the difference in what a corp says they do and what they actually do? --------------------------- What about Yahoo, now that they will use Bing? Or even AltaVista? How do we know the difference between the reality of what they do versus their Privacy Policy? ---------------------------- Yahoo and Altavista are one and the same. Excite is owned by www.iac.com who own many other companies that collect and make money from knowing what you do. Webcrawler is owned by InfoSpace (www.infospaceinc.com). They are ALL making money doing the same thing. ---------------------------------- You don't get to have Privacy on the Internet. It's a fallacy. You have to work really hard to truly have privacy on the 'net. And lie a lot. ---------------------------------- Yes, you have to work hard and (one last time :-) DBS. Use your sniffers at home to see what's talking to what; manage your cookies; force your ISPs machinery to change your DHCP-assigned address a lot; use SSH tunnels, blah, blah, blah. In FF goto "Tools", 'Options', 'Privacy', and select: "Accept cookies from sites'; 'Accept third-party cookies'; 'Keep until: just to get a taste. Be sure to click on 'Show Details' when the flood of cookies comes and pay attention to the details. Don't go to sites that bork when you use these settings any longer. Also, look in 'Show cookies' and 'Exceptions'. Funny how M$ won't let you do that in IE AFAICT. scott From beckman at angryox.com Fri Dec 11 21:51:10 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 11 Dec 2009 16:51:10 -0500 Subject: news from Google In-Reply-To: <4B22B48A.1050008@rollernet.us> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> Message-ID: On Fri, 11 Dec 2009, Seth Mattinen wrote: > "We want your money" versus "we want your life". I don't pay any of those search engines -- they make money off of advertising. Huh, just like Google. And to think that none of the search engines are taking that data and trying to build better products or services is naive. > We are all likely breaking some law on a daily basis. Now this I agree with. There are so many laws, so many unenforced, that it is hard to know all of them, and to know which ones (in which state, city, local, or country!) you are breaking. You have the choice to be more private -- pay cash for everything, wear a hood or a mask to avoid being caught on camera, no EZpass, no bank account, no credit card, no cell phone, no phone at all, no Internet access. But that's kinda difficult to do, given that most of us have jobs and income based solely on this medium. The ease of logging and the human justifcation of hording that data pretty much prevents you from having a private life. Trust me, what you search on Google is much less valuable than your cell phone records, credit card statements and EZpass records. Your search records are just icing on the cake to the proscecutor. > Here's a pretty common line that Microsoft has that Google completely omits > (or that I can't find): > > "We do not sell, rent, or lease our customer lists to third parties." Have you opted out of your credit card company from doing so? Do you feel as comfortable with your Credit Card company as you do with Google? Do you feel MORE comfortable with Microsoft managing your Credit Card? C'mon. Your personal information is so easily gotten right now it's silly for anyone to think that knowing Microsoft won't sell their customer lists will somehow protect you. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From michael.holstein at csuohio.edu Fri Dec 11 21:57:38 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 11 Dec 2009 16:57:38 -0500 Subject: news from Google In-Reply-To: <20091211133515.47DD1245@resin14.mta.everyone.net> References: <20091211133515.47DD1245@resin14.mta.everyone.net> Message-ID: <4B22C052.1010501@csuohio.edu> > In FF goto "Tools", 'Options', 'Privacy', and select: "Accept cookies from sites'; 'Accept third-party cookies'; 'Keep until: just to get a taste. Be sure to click on 'Show Details' when the flood of cookies comes and pay attention to the details. Don't go to sites that bork when you use these settings any longer. Also, look in 'Show cookies' and 'Exceptions'. Funny how M$ won't let you do that in IE AFAICT. > Let's not forget about Flash LSOs and the nasty companies that offer "services" to "replace" your cookies if they're deleted. FF has "BetterPrivacy" for that. Only caveat is it drives websites like BoA and eBay bonkers .. they want to "verify" you every time you re-visit. Cheers, Michael Holstein Cleveland State University From weaselkeeper at gmail.com Fri Dec 11 21:59:11 2009 From: weaselkeeper at gmail.com (Jim Richardson) Date: Fri, 11 Dec 2009 13:59:11 -0800 Subject: news from Google In-Reply-To: <4B22B48A.1050008@rollernet.us> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> Message-ID: <7f17308a0912111359u588844f8x81562ed1f0640cb8@mail.gmail.com> On Fri, Dec 11, 2009 at 1:07 PM, Seth Mattinen wrote: > Peter Beckman wrote: > Here's a pretty common line that Microsoft has that Google completely omits > (or that I can't find): > > "We do not sell, rent, or lease our customer lists to third parties." > > ~Seth > > You aren't Bing's customer, you are a user. The line you quote, even if they follow it, would not prohibit them from selling any and all information they get from your searches. *yahoo* is Bing's customer. -- http://neon-buddha.net From cidr-report at potaroo.net Fri Dec 11 22:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Dec 2009 22:00:04 GMT Subject: BGP Update Report Message-ID: <200912112200.nBBM04ob083818@wattle.apnic.net> BGP Update Report Interval: 03-Dec-09 -to- 10-Dec-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 29130 1.0% 24.1 -- TEDATA TEDATA 2 - AS4323 27436 0.9% 6.2 -- TWTC - tw telecom holdings, inc. 3 - AS6389 26286 0.9% 6.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS8151 20654 0.7% 12.9 -- Uninet S.A. de C.V. 5 - AS7643 18283 0.6% 39.5 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - AS35805 17304 0.6% 33.1 -- UTG-AS United Telecom AS 7 - AS17488 15302 0.5% 10.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 8 - AS9198 14136 0.5% 29.9 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - AS20115 14112 0.5% 9.2 -- CHARTER-NET-HKY-NC - Charter Communications 10 - AS5800 13579 0.5% 71.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS29049 13359 0.5% 45.9 -- DELTA-TELECOM-AS Delta Telecom LTD. 12 - AS14420 13323 0.5% 36.3 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 13 - AS17974 12481 0.4% 14.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS9829 12150 0.4% 14.1 -- BSNL-NIB National Internet Backbone 15 - AS7018 12045 0.4% 7.5 -- ATT-INTERNET4 - AT&T WorldNet Services 16 - AS7738 11978 0.4% 27.8 -- Telecomunicacoes da Bahia S.A. 17 - AS1785 11964 0.4% 6.7 -- AS-PAETEC-NET - PaeTec Communications, Inc. 18 - AS4766 11550 0.4% 6.0 -- KIXS-AS-KR Korea Telecom 19 - AS28477 10785 0.4% 1198.3 -- Universidad Autonoma del Esstado de Morelos 20 - AS11492 10696 0.4% 9.3 -- CABLEONE - CABLE ONE, INC. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 2926 0.1% 2926.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS39384 1696 0.1% 1696.0 -- GUILAN-UNIV-AS University of Guilan AS System 3 - AS37035 4186 0.1% 1395.3 -- MIC-AS 4 - AS28477 10785 0.4% 1198.3 -- Universidad Autonoma del Esstado de Morelos 5 - AS36239 1173 0.0% 1173.0 -- EXIGEN-CANADA - Exigen Canada 6 - AS4 1155 0.0% 533.0 -- Konecta, S. de R.L. de C.V. 7 - AS14251 1680 0.1% 840.0 -- MLSLI - Multiple Lising Service of Long Island, Inc. 8 - AS41368 705 0.0% 705.0 -- TVALMANSA-ASN TV ALMANSA, Servicios de Comunicacion 9 - AS22919 1368 0.1% 684.0 -- PCCNET - Portland Community College 10 - AS12732 6412 0.2% 582.9 -- bbTT GmbH 11 - AS33648 984 0.0% 492.0 -- ELEPHANT - ColoFlorida / Elephant Outlook 12 - AS39803 956 0.0% 478.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 13 - AS6009 421 0.0% 421.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS28150 1239 0.0% 413.0 -- 15 - AS37786 688 0.0% 344.0 -- 16 - AS6822 10455 0.4% 316.8 -- SUPERONLINE-AS SuperOnline autonomous system 17 - AS43818 307 0.0% 307.0 -- MELLAT-AS bankmellat 18 - AS28052 303 0.0% 303.0 -- Arte Radiotelevisivo Argentino 19 - AS3944 767 0.0% 255.7 -- PARTAN-LAB - Partan & Partan 20 - AS27563 1245 0.0% 249.0 -- SCANA - SCANA COMMUNICATIONS INC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 10689 0.4% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 212.42.236.0/24 5694 0.2% AS12732 -- bbTT GmbH 3 - 203.162.118.128/ 4515 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 4 - 89.144.140.0/24 4233 0.1% AS39308 -- ASK-AS Andishe Sabz Khazar Autonomous System AS39384 -- GUILAN-UNIV-AS University of Guilan AS System 5 - 41.222.179.0/24 4150 0.1% AS37035 -- MIC-AS 6 - 143.138.107.0/24 3116 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 7 - 91.212.23.0/24 2926 0.1% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 8 - 222.255.186.0/25 2846 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 9 - 202.177.223.0/24 2430 0.1% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 12 - 192.12.120.0/24 2190 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 13 - 202.167.247.0/24 1803 0.1% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 14 - 212.253.13.0/24 1739 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 15 - 212.253.7.0/24 1739 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 16 - 212.253.6.0/24 1738 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 17 - 212.253.0.0/17 1681 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 18 - 212.253.192.0/18 1677 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 19 - 65.223.235.0/24 1674 0.1% AS14251 -- MLSLI - Multiple Lising Service of Long Island, Inc. 20 - 212.253.20.0/24 1665 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 11 22:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Dec 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200912112200.nBBM00Zn083793@wattle.apnic.net> This report has been generated at Fri Dec 11 21:11:26 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 04-12-09 310737 192817 05-12-09 310870 192536 06-12-09 310697 192398 07-12-09 310614 191838 08-12-09 310880 190765 09-12-09 310972 191617 10-12-09 310912 192007 11-12-09 311684 190374 AS Summary 33116 Number of ASes in routing system 14097 Number of ASes announcing only one prefix 4367 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92609472 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 11Dec09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 308693 190327 118366 38.3% All ASes AS6389 4232 318 3914 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4367 1944 2423 55.5% TWTC - tw telecom holdings, inc. AS1785 1791 345 1446 80.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1780 474 1306 73.4% KIXS-AS-KR Korea Telecom AS17488 1458 311 1147 78.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1123 71 1052 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1586 659 927 58.4% Uninet S.A. de C.V. AS4755 1278 391 887 69.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1044 236 808 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 946 263 683 72.2% TEDATA TEDATA AS18101 992 326 666 67.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 1002 338 664 66.3% TV Cable S.A. AS6478 1169 532 637 54.5% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 444 615 58.1% COVAD - Covad Communications Co. AS3356 1203 622 581 48.3% LEVEL3 Level 3 Communications AS24560 809 232 577 71.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 764 196 568 74.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4134 1012 449 563 55.6% CHINANET-BACKBONE No.31,Jin-rong Street AS4804 633 70 563 88.9% MPX-AS Microplex PTY LTD AS7303 665 103 562 84.5% Telecom Argentina S.A. AS7018 1588 1032 556 35.0% ATT-INTERNET4 - AT&T WorldNet Services AS17908 765 240 525 68.6% TCISL Tata Communications AS11492 1145 632 513 44.8% CABLEONE - CABLE ONE, INC. AS4780 634 139 495 78.1% SEEDNET Digital United Inc. AS22047 545 50 495 90.8% VTR BANDA ANCHA S.A. AS28573 821 351 470 57.2% NET Servicos de Comunicao S.A. AS9443 532 79 453 85.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS5668 786 344 442 56.2% AS-5668 - CenturyTel Internet Holdings, Inc. AS17676 564 129 435 77.1% GIGAINFRA Softbank BB Corp. AS35805 465 47 418 89.9% UTG-AS United Telecom AS Total 36758 11367 25391 69.1% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 207.174.132.0/23 AS30715 207.174.152.0/22 AS30715 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From sthaug at nethelp.no Fri Dec 11 22:04:04 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 11 Dec 2009 23:04:04 +0100 (CET) Subject: news from Google In-Reply-To: <4B22B48A.1050008@rollernet.us> References: <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> Message-ID: <20091211.230404.78730545.sthaug@nethelp.no> > If you aren't breaking the law, the government won't be looking for your > data, and won't ask Google/Yahoo/Bing/AltaVista or other search companies > for your data. That's an extremely naive view of how governments operate. To put it mildly. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From beckman at angryox.com Fri Dec 11 22:05:01 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 11 Dec 2009 17:05:01 -0500 Subject: news from Google In-Reply-To: <20091211133515.47DD1245@resin14.mta.everyone.net> References: <20091211133515.47DD1245@resin14.mta.everyone.net> Message-ID: On Fri, 11 Dec 2009, Scott Weeks wrote: > --- beckman at angryox.com wrote: > From: Peter Beckman > > At least Google seems to be honest about it. > ---------------------------------------------- > > Yeah, trust them... I said "seems." It's hard to verify if ANY company follows what is said in their Privacy Policy. > --------------------------- > What does Bing say they keep about you when you search, not logged into > your Passport account? IP + searches, date and time? And what do they > actually do? > --------------------------- > > NOW you're getting warm. What IS the difference in what a corp says they > do and what they actually do? Who knows? Since they won't let you check (then again, I never asked if I could), how do you know what they are really doing with the data you know they might have? > --------------------------- > What about Yahoo, now that they will use Bing? Or even > AltaVista? How do we know the difference between the reality of what they > do versus their Privacy Policy? > ---------------------------- > > Yahoo and Altavista are one and the same. Excite is owned by www.iac.com > who own many other companies that collect and make money from knowing > what you do. Webcrawler is owned by InfoSpace (www.infospaceinc.com). > They are ALL making money doing the same thing. I don't see that trend slowing. So when you search on AltaVista, assuming AltaVista uses Yahoo and Yahoo using Bing, does AV, Yahoo! AND Microsoft (via Bing) all get a copy of that single search request and thusly your data? I'm guessing the 3 companies have different privacy policies that each apply to that data separately... makes your head spin. > ---------------------------------- > You don't get to have Privacy on the Internet. It's a fallacy. You have > to work really hard to truly have privacy on the 'net. And lie a lot. > ---------------------------------- > > Yes, you have to work hard and (one last time :-) DBS. Use your sniffers > at home to see what's talking to what; manage your cookies; force your > ISPs machinery to change your DHCP-assigned address a lot; use SSH > tunnels, blah, blah, blah. That's a lot of work, more overhead than many are willing to put in. Maybe someday I'll eat my words, but I'm just not paranoid enough to work that hard to avoid search engines or other companies to log my use of their service. I'm more worried about all the data at the doctor's office, the federal government, credit card and reporting companies, phone companies, etc. and I'm not doing much about that either. > In FF goto "Tools", 'Options', 'Privacy', and select: "Accept cookies > from sites'; 'Accept third-party cookies'; 'Keep until: time> just to get a taste. Be sure to click on 'Show Details' when the > flood of cookies comes and pay attention to the details. Don't go to > sites that bork when you use these settings any longer. Also, look in > 'Show cookies' and 'Exceptions'. Funny how M$ won't let you do that in > IE AFAICT. Using a combo of Ad Blocker Plus and NoScript in Firefox helps reduce that significantly, without all the popups. But yeah, it's hard to use the Internet and not get tracked by a bunch of different entities you know nothing about. Which gives further proof that my earlier statement rings true: You don't get to have Privacy on the Internet. It's a fallacy. You have to work really hard to truly have privacy on the 'net. And lie a lot. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jmamodio at gmail.com Fri Dec 11 22:23:14 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 16:23:14 -0600 Subject: news from Google In-Reply-To: References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> Message-ID: <202705b0912111423s206bdac4va007b677f44b9a03@mail.gmail.com> > ?If you aren't breaking the law, the government won't be looking for your > ?data, and won't ask Google/Yahoo/Bing/AltaVista or other search companies > ?for your data. Welcome to China, host country of IETF 79, the first IETF meeting that will break the record of VPN tunnels ... Also, what law ? what government ? Ask Yahoo about what happened in France about some collectible items, ask Dow Jones for distributing news in Australia that some guy didn't like, ask Google about providing search results that famous people don't want to see everywhere. On the other hand, name it Google, Yahoo, Bing, or whatever, their biz model is to make money based on information they collect about you (even in an abstract form) or that put through your throat as advertisement, but keep in mind that most of the time there is only one source for such information: You ;-) If you don't like it, get isolated, (I was going to say move to Mars but it won't work since it's already on Google's master plan and Vint's interplanetary network vision) move to Wassila and enjoy fishing alone. My .02 Jorge From beckman at angryox.com Fri Dec 11 22:33:47 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 11 Dec 2009 17:33:47 -0500 Subject: news from Google In-Reply-To: <20091211.230404.78730545.sthaug@nethelp.no> References: <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> <20091211.230404.78730545.sthaug@nethelp.no> Message-ID: On Fri, 11 Dec 2009, sthaug at nethelp.no wrote: >> If you aren't breaking the law, the government won't be looking for your >> data, and won't ask Google/Yahoo/Bing/AltaVista or other search companies >> for your data. > > That's an extremely naive view of how governments operate. To put it > mildly. That may be. But the government has a lot better data than "what did Peter Beckman search for online in the last 12 years?" Could it help them build a case against me? Sure. Should I be more careful about using search engines? Probably. I know there is TORbutton (easily turn on and off TOR) and tor-proxy.net plugins for Firefox, but is there a plugin that will use a user-defined proxy for certain user-defined sites/URLs (such as Google, Bing, etc) and allow one to surf directly on all other URLs? Or even a NoScript (whitelist) type deal that sends everything via a proxy except for those sites you decide to trust? That'd be handy to avoid this privacy stuff. Getting offtopic. You simply need to assume that every company who you reveal even small pieces of your identity or online persona will sell, reveal, badly secure or misuse the information you provide. I think this assumption is realistic, and that you need to be aware of it. Google is simply telling you what all the other companies already do -- archive their data, which you generated, and which can be used to identify you and against you in a court of law. I'm shocked that really smart people like Asa Dotzler are shocked by what Eric Schmidt said, what I assumed was simply common knowledge - that there is no real privacy on the internet. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jmamodio at gmail.com Fri Dec 11 22:41:34 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 16:41:34 -0600 Subject: news from Google In-Reply-To: <4B22B48A.1050008@rollernet.us> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> Message-ID: <202705b0912111441o1243d24fob8120dcc85e743f1@mail.gmail.com> > Here's a pretty common line that Microsoft has that Google completely omits > (or that I can't find): > > "We do not sell, rent, or lease our customer lists to third parties." LRMAO Or they just acquire the third party to keep it in house ... From tvhawaii at shaka.com Fri Dec 11 22:58:31 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 11 Dec 2009 12:58:31 -1000 Subject: news from Google References: <4B22AD61.8060303@rollernet.us><4B22B48A.1050008@rollernet.us><20091211.230404.78730545.sthaug@nethelp.no> Message-ID: <0F446A812C284760948A7FBC3495E14F@DELL16> Peter Beckman wrote: > I'm shocked that really smart people like Asa Dotzler are shocked by what > Eric Schmidt said, what I assumed was simply common knowledge - that there > is no real privacy on the internet. "On the Sprint 3G network... If [the handset uses] the [WAP] Media Access Gateway, we have the URL history for 24 months ... We don't store it because law enforcement asks us to store it, we store it because when we launched 3G in 2001 or so, we thought we were going to bill by the megabyte ... but ultimately, that's why we store the data ... It's because marketing wants to rifle through the data." http://www.infoworld.com/d/adventures-in-it/cell-phone-subterfuge-produces-nation-270-million-spies-090 From johnl at iecc.com Fri Dec 11 23:39:29 2009 From: johnl at iecc.com (John Levine) Date: 11 Dec 2009 23:39:29 -0000 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <1260520619.4148.99.camel@petrie> Message-ID: <20091211233929.39504.qmail@simone.iecc.com> >ASPEWS is listing 216.83.32.0/20 as being associated with the whole >Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being >involved, nor the provider that belongs to. Since nobody but the occasional highly vocal GWL uses ASPEWS, it's hard to see why one would care, but if you want to find ASPEWS, crank up your favorite usenet program, post a question to nanae, and watch the vitriol roll in. There might be a comment from ASPEWS in there. R's, John From sethm at rollernet.us Fri Dec 11 23:54:34 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 15:54:34 -0800 Subject: news from Google In-Reply-To: <202705b0912111441o1243d24fob8120dcc85e743f1@mail.gmail.com> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> <202705b0912111441o1243d24fob8120dcc85e743f1@mail.gmail.com> Message-ID: <4B22DBBA.4030601@rollernet.us> Jorge Amodio wrote: > > LRMAO > Coming from a gmail user... ~Seth From sethm at rollernet.us Sat Dec 12 00:07:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 16:07:47 -0800 Subject: news from Google In-Reply-To: References: <20091211133515.47DD1245@resin14.mta.everyone.net> Message-ID: <4B22DED3.1010203@rollernet.us> Peter Beckman wrote: > > Using a combo of Ad Blocker Plus and NoScript in Firefox helps reduce that > significantly, without all the popups. But yeah, it's hard to use the > Internet and not get tracked by a bunch of different entities you know > nothing about. > > Which gives further proof that my earlier statement rings true: > > You don't get to have Privacy on the Internet. It's a fallacy. You > have > to work really hard to truly have privacy on the 'net. And lie a lot. > I'm not naive enough to think all privacy policies reflect what a company is actually doing, but I'm surprised that people think Google protects their privacy at the same time they practically admitting they're selling your digital soul to whoever will pay for it. Hell, all you gmail users on this list right now are feeding the machine with all our data. The part that gets me: everyone seems happy with this. ~Seth From jmamodio at gmail.com Sat Dec 12 01:21:43 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 19:21:43 -0600 Subject: news from Google In-Reply-To: <4B22DBBA.4030601@rollernet.us> References: <20091210231459.55C6B038@resin09.mta.everyone.net> <4B22AD61.8060303@rollernet.us> <4B22B48A.1050008@rollernet.us> <202705b0912111441o1243d24fob8120dcc85e743f1@mail.gmail.com> <4B22DBBA.4030601@rollernet.us> Message-ID: <202705b0912111721k2fb8b707w636455a0d7612412@mail.gmail.com> >> LRMAO >> > > Coming from a gmail user... Yes, and very satisfied with their service (not happy with the line wraps though and plain text formatting), very convenient to receive messages from e-mail lists and a more efficient way to deal with spam and other nuisances. I've to admit that actually MSFT online privacy notice (which it is not clear if it's equal to their privacy "policy") includes the statement you mentioned in your message, but you forgot to include the rest ... >From http://privacy.microsoft.com/en-us/default.mspx : (short version, if you want all the yada yada you need to click on "Additional Details") Personal Information - When you register for certain Microsoft services, we will ask you to provide personal information. - The information we collect may be combined with information obtained from other Microsoft services and other companies. - We use cookies and other technologies to keep track of your interactions with our sites and services to offer a personalized experience. Uses of Information -We use the information we collect to provide the services you request. Our services may include the display of personalized content and advertising. - We use your information to inform you of other products or services offered by Microsoft and its affiliates, and to send you relevant survey invitations related to Microsoft services. - We do not sell, rent, or lease our customer lists to third parties. In order to help provide our services, we occasionally provide information to other companies that work on our behalf. And then there is another section that is related to "Your Choices", but nowhere (and I'm not saying that others provide this option either) says you opt to keep all the information Microsoft collects about you private and not shared with affiliates (very vague term) or other companies working on their behalf (ie the telemarketers bothering you at home in the middle of your favorite football game to sell something you don't need). Every single provider that collects information about you tries to find the way to monetize it and make some extra bucks. Cheers Jorge From surfer at mauigateway.com Sat Dec 12 01:21:50 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Dec 2009 17:21:50 -0800 Subject: news from Google Message-ID: <20091211172150.47DD6C72@resin14.mta.everyone.net> --- sethm at rollernet.us wrote: The part that gets me: everyone seems happy with this. --------------------------------------- Not everyone. ;-) scott From ALanstein at FireEye.com Sat Dec 12 01:25:33 2009 From: ALanstein at FireEye.com (Alex Lanstein) Date: Fri, 11 Dec 2009 17:25:33 -0800 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <1260563720.4148.116.camel@petrie> References: <1260520619.4148.99.camel@petrie> <60B0F2124D07B942988329B5B7CA393D020BE87537@mail2.FireEye.com>, <1260563720.4148.116.camel@petrie> Message-ID: <60B0F2124D07B942988329B5B7CA393D020BE87546@mail2.FireEye.com> William Pitcock wrote: >>>Cernal and Atrivo are two different entities, Atrivo used to host >>>Cernal, but now they have different hosting arrangements. I now understand the original point you were trying to make about Atrivo. I disagree with your premise that it is actually a different entity than Cernel, but am not trying to debate that on this list for various reasons. Acting under my (incorrect or correct) assumption that they are in fact the same entity, I made my post to show that "the boys were back". That is, for a decent amount of time, parts of 85.255.112.0/20 were not being advertised, and hence the dns hijacking pointing selected http traffic to 67.210.0.0/20 wasn't happening. My point was that it (fairly) recently started being advertised again, and it was the same old song and dance wrt dns/http hijacking/fraud. Regards, Alex Lanstein FireEye, Inc. ________________________________________ From: William Pitcock [nenolod at systeminplace.net] Sent: Friday, December 11, 2009 3:35 PM To: Alex Lanstein Cc: nanog at nanog.org Subject: RE: Is there anyone from ASPEWS on this list? On Fri, 2009-12-11 at 09:55 -0800, Alex Lanstein wrote: > >>>Also, the fact that Atrivo is *dead* and this > >>>stuff is still listed means that anyone who gets > >>>those blocks from ARIN next are basically screwed > > Why would you say Atrivo is dead? > > root at localhost --- {~} nslookup www.googleadservices.com 85.255.114.83 > Server: 85.255.114.83 > Address: 85.255.114.83#53 > > Name: www.googleadservices.com > Address: 67.210.14.113 That is Cernal, and it is hosted in Russia now. Cernal and Atrivo are two different entities, Atrivo used to host Cernal, but now they have different hosting arrangements. Can people get a clue and understand this very critical difference? Thanks. William -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nenolod at systeminplace.net Sat Dec 12 01:35:00 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 11 Dec 2009 19:35:00 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <60B0F2124D07B942988329B5B7CA393D020BE87546@mail2.FireEye.com> References: <1260520619.4148.99.camel@petrie> <60B0F2124D07B942988329B5B7CA393D020BE87537@mail2.FireEye.com> , <1260563720.4148.116.camel@petrie> <60B0F2124D07B942988329B5B7CA393D020BE87546@mail2.FireEye.com> Message-ID: <1260581700.4148.127.camel@petrie> On Fri, 2009-12-11 at 17:25 -0800, Alex Lanstein wrote: > William Pitcock wrote: > >>>Cernal and Atrivo are two different entities, Atrivo used to host > >>>Cernal, but now they have different hosting arrangements. > > I now understand the original point you were trying to make about Atrivo. I disagree with your premise that it is actually a different entity than Cernel, but am not trying to debate that on this list for various reasons. Then why did you make the post? > > Acting under my (incorrect or correct) assumption that they are in fact the same entity, I made my post to show that "the boys were back". They are separate entities, and Cernal hosts with other providers, and did so while Atrivo existed as well. Infact, read below for some poignant analysis on this fact. > > That is, for a decent amount of time, parts of 85.255.112.0/20 were not being advertised, and hence the dns hijacking pointing selected http traffic to 67.210.0.0/20 wasn't happening. > > My point was that it (fairly) recently started being advertised again, and it was the same old song and dance wrt dns/http hijacking/fraud. > That doesn't surprise me, but I see it coming from Amazon EC2. Infact, traceroutes end at 67.210.14.1, which is a router servicing the EC2 cloud. 85.255.112.0/20 appears to be announced by Bandcon / Internet-Path in the NYC area. I believe that Amazon EC2's NYC cloud uses these providers, but not 100% sure on that one. Regardless, Amazon EC2 is not Atrivo, at all, period, and if you believe that it is, you're bloody crazy. William From jcdill.lists at gmail.com Sat Dec 12 01:38:22 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 11 Dec 2009 17:38:22 -0800 Subject: news from Google In-Reply-To: <4B22DED3.1010203@rollernet.us> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> Message-ID: <4B22F40E.7080901@gmail.com> Seth Mattinen wrote: > Hell, all you gmail users on this list right now are feeding the > machine with all our data. > > The part that gets me: everyone seems happy with this. This list has public archives that are already crawled and archived by Google. For example: http://www.merit.edu/mail.archives/nanog/threads.html http://seclists.org/nanog/2009/Dec/434 Subscribing to the list with a gmail account doesn't change anything about what Google knows about the list or list members. The part that gets me is that you don't already understand this. jc From nenolod at systeminplace.net Sat Dec 12 01:43:24 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 11 Dec 2009 19:43:24 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <20091211233929.39504.qmail@simone.iecc.com> References: <20091211233929.39504.qmail@simone.iecc.com> Message-ID: <1260582204.4148.130.camel@petrie> On Fri, 2009-12-11 at 23:39 +0000, John Levine wrote: > >ASPEWS is listing 216.83.32.0/20 as being associated with the whole > >Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being > >involved, nor the provider that belongs to. > > Since nobody but the occasional highly vocal GWL uses ASPEWS, it's > hard to see why one would care, but if you want to find ASPEWS, crank > up your favorite usenet program, post a question to nanae, and watch > the vitriol roll in. There might be a comment from ASPEWS in there. Well, I just want to reach SORBS to clear up some confusion regarding what ranges of mine are dynamic (e.g. none of them, but they seem to think otherwise). Unfortunately, e-mail to SORBS bounces due to ethr.net being listed in ASPEWS as being "part of Atrivo". I think it is kind of fail that RBL people do not have e-mail based contact addresses. Snoozenet is unpleasant to deal with. William From jmamodio at gmail.com Sat Dec 12 01:45:30 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 19:45:30 -0600 Subject: news from Google In-Reply-To: <4B22F40E.7080901@gmail.com> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> Message-ID: <202705b0912111745r7c7d230dl61053188255a2fd8@mail.gmail.com> > This list has public archives that are already crawled and archived by > Google. ?For example: > > http://www.merit.edu/mail.archives/nanog/threads.html > http://seclists.org/nanog/2009/Dec/434 > > Subscribing to the list with a gmail account doesn't change anything about > what Google knows about the list or list members. Indeed. BTW I'm impressed about how fast particularly the messages archived by insecure.org show up on the search results. Jorge From johnl at iecc.com Sat Dec 12 02:06:35 2009 From: johnl at iecc.com (John R. Levine) Date: 11 Dec 2009 21:06:35 -0500 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <1260582204.4148.130.camel@petrie> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> Message-ID: So write to her from a gmail account. APEWS is pretty kooky, and I'm kind of surprised if SORBS is using it. > On Fri, 2009-12-11 at 23:39 +0000, John Levine wrote: >>> ASPEWS is listing 216.83.32.0/20 as being associated with the whole >>> Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being >>> involved, nor the provider that belongs to. >> >> Since nobody but the occasional highly vocal GWL uses ASPEWS, it's >> hard to see why one would care, but if you want to find ASPEWS, crank >> up your favorite usenet program, post a question to nanae, and watch >> the vitriol roll in. There might be a comment from ASPEWS in there. > > Well, I just want to reach SORBS to clear up some confusion regarding > what ranges of mine are dynamic (e.g. none of them, but they seem to > think otherwise). Unfortunately, e-mail to SORBS bounces due to > ethr.net being listed in ASPEWS as being "part of Atrivo". > > I think it is kind of fail that RBL people do not have e-mail based > contact addresses. Snoozenet is unpleasant to deal with. > > William > > Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From sethm at rollernet.us Sat Dec 12 02:37:18 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 18:37:18 -0800 Subject: news from Google In-Reply-To: <4B22F40E.7080901@gmail.com> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> Message-ID: <4B2301DE.7020403@rollernet.us> JC Dill wrote: > > The part that gets me is that you don't already understand this. > Can you please be nice? I didn't throw personal attacks at you. ~Seth From sethm at rollernet.us Sat Dec 12 02:44:09 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 18:44:09 -0800 Subject: news from Google In-Reply-To: <4B22F40E.7080901@gmail.com> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> Message-ID: <4B230379.3050807@rollernet.us> JC Dill wrote: > Seth Mattinen wrote: >> Hell, all you gmail users on this list right now are feeding the >> machine with all our data. >> >> The part that gets me: everyone seems happy with this. > > This list has public archives that are already crawled and archived by > Google. For example: > > http://www.merit.edu/mail.archives/nanog/threads.html > http://seclists.org/nanog/2009/Dec/434 > > Subscribing to the list with a gmail account doesn't change anything > about what Google knows about the list or list members. > Those URL's don't seem to include "google.com" in them. Maybe I'm misreading them. Crawlers can be excluded with robots.txt if so chosen by the site owner so long as google respects said file. Some lists also respect a "no archive" header that some people choose to include with their messages. Preventing my email to gmail from entering their vast database of whatever they track doesn't have any such control features that I'm aware of. If there are, I'll stand corrected. ~Seth From sethm at rollernet.us Sat Dec 12 02:48:35 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 18:48:35 -0800 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <1260582204.4148.130.camel@petrie> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> Message-ID: <4B230483.8070700@rollernet.us> William Pitcock wrote: > On Fri, 2009-12-11 at 23:39 +0000, John Levine wrote: >>> ASPEWS is listing 216.83.32.0/20 as being associated with the whole >>> Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being >>> involved, nor the provider that belongs to. >> Since nobody but the occasional highly vocal GWL uses ASPEWS, it's >> hard to see why one would care, but if you want to find ASPEWS, crank >> up your favorite usenet program, post a question to nanae, and watch >> the vitriol roll in. There might be a comment from ASPEWS in there. > > Well, I just want to reach SORBS to clear up some confusion regarding > what ranges of mine are dynamic (e.g. none of them, but they seem to > think otherwise). Unfortunately, e-mail to SORBS bounces due to > ethr.net being listed in ASPEWS as being "part of Atrivo". > You should still be able to submit a ticket to SORBS, no? I was always under the impression that it was "open a ticket and wait or you are moved to the back of the line" with SORBS. ~Seth From john-nanog at johnpeach.com Sat Dec 12 02:51:31 2009 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 11 Dec 2009 21:51:31 -0500 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B230483.8070700@rollernet.us> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> Message-ID: <20091211215131.3ab3903d@milhouse.peachfamily.net> On Fri, 11 Dec 2009 18:48:35 -0800 Seth Mattinen wrote: > William Pitcock wrote: > > On Fri, 2009-12-11 at 23:39 +0000, John Levine wrote: > >>> ASPEWS is listing 216.83.32.0/20 as being associated with the whole > >>> Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being > >>> involved, nor the provider that belongs to. > >> Since nobody but the occasional highly vocal GWL uses ASPEWS, it's > >> hard to see why one would care, but if you want to find ASPEWS, crank > >> up your favorite usenet program, post a question to nanae, and watch > >> the vitriol roll in. There might be a comment from ASPEWS in there. > > > > Well, I just want to reach SORBS to clear up some confusion regarding > > what ranges of mine are dynamic (e.g. none of them, but they seem to > > think otherwise). Unfortunately, e-mail to SORBS bounces due to > > ethr.net being listed in ASPEWS as being "part of Atrivo". > > > > You should still be able to submit a ticket to SORBS, no? I was always > under the impression that it was "open a ticket and wait or you are > moved to the back of the line" with SORBS. > More like "pay our ransom or FOAD". Why I never use them.... -- John From jmamodio at gmail.com Sat Dec 12 03:18:21 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 11 Dec 2009 21:18:21 -0600 Subject: news from Google In-Reply-To: <4B230379.3050807@rollernet.us> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> <4B230379.3050807@rollernet.us> Message-ID: <202705b0912111918u158cfa15saf8b4dd5dca73dde@mail.gmail.com> >> This list has public archives that are already crawled and archived by >> Google. ?For example: >> >> http://www.merit.edu/mail.archives/nanog/threads.html >> http://seclists.org/nanog/2009/Dec/434 >> >> Subscribing to the list with a gmail account doesn't change anything about >> what Google knows about the list or list members. >> > > Those URL's don't seem to include "google.com" in them. Maybe I'm misreading > them. Crawlers can be excluded with robots.txt if so chosen by the site > owner so long as google respects said file. Some lists also respect a "no > archive" header that some people choose to include with their messages. http://www.google.com/search?hl=en&rlz=1C1CHNU_enUS355US353&q=%22Preventing+my+email+to+gmail+from+entering%22&aq=f&oq=&aqi= From sethm at rollernet.us Sat Dec 12 03:31:36 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 19:31:36 -0800 Subject: news from Google In-Reply-To: <202705b0912111918u158cfa15saf8b4dd5dca73dde@mail.gmail.com> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> <4B230379.3050807@rollernet.us> <202705b0912111918u158cfa15saf8b4dd5dca73dde@mail.gmail.com> Message-ID: <4B230E98.1060209@rollernet.us> Jorge Amodio wrote: > > http://www.google.com/search?hl=en&rlz=1C1CHNU_enUS355US353&q=%22Preventing+my+email+to+gmail+from+entering%22&aq=f&oq=&aqi= I didn't get any results from that link. ~Seth From jcdill.lists at gmail.com Sat Dec 12 03:38:18 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 11 Dec 2009 19:38:18 -0800 Subject: news from Google In-Reply-To: <4B230379.3050807@rollernet.us> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> <4B230379.3050807@rollernet.us> Message-ID: <4B23102A.4060805@gmail.com> Seth Mattinen wrote: > JC Dill wrote: >> Seth Mattinen wrote: >>> Hell, all you gmail users on this list right now are feeding the >>> machine with all our data. >>> >>> The part that gets me: everyone seems happy with this. >> >> This list has public archives that are already crawled and archived >> by Google. For example: >> >> http://www.merit.edu/mail.archives/nanog/threads.html >> http://seclists.org/nanog/2009/Dec/434 >> >> Subscribing to the list with a gmail account doesn't change anything >> about what Google knows about the list or list members. >> > > Those URL's don't seem to include "google.com" in them. Maybe I'm > misreading them. I *found* them by searching with Google. I found the second link by searching for a unique phrase from your email: http://www.google.com/search?q=nanog+%22feeding+the+machine A mere 1 hour after you emailed it to the NANOG list, Google web search has that email archived from the website on seclists.org. > Crawlers can be excluded with robots.txt if so chosen by the site > owner so long as google respects said file. Google does respect that file, but you are counting on other subscribers respecting the site owner's wishes regarding web archives. In my experience, this has become a futile fight. If the list doesn't have a web accessible archive, it's likely one of the list's subscribers might start their own archive or have it archived with one of the many archive sites e.g. gmane. > Some lists also respect a "no archive" header that some people choose > to include with their messages. If you are emailing a publicly archived mailing list that you know is web archived and likely spidered by Google, a "no archive" header is mostly useless. When someone replies to your email (as I'm doing now) your quoted text in the reply will be archived, preserving what you posted to the list. At best, the "no archive" header merely messes up threading. The "no archive" header idea never really worked in the first place - witness all the old usenet server posts that ended up on dejagoogle even when the posts had "no archive" headers. > > Preventing my email to gmail from entering their vast database of > whatever they track doesn't have any such control features that I'm > aware of. Preventing any email you send to anyone from being leaked out to the public is something you have no control of. I.e. the CRU hacked email controversy. If you don't want what you write to be posted on or archived on the internet and findable with web searches, don't use the internet to write or transmit it. Even then, you are at risk of someone scanning and posting what you write. As a NANOG subscriber you should be clueful enough to know all of this already. So what's the big issue here? jc From sethm at rollernet.us Sat Dec 12 04:50:36 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Dec 2009 20:50:36 -0800 Subject: news from Google In-Reply-To: <4B23102A.4060805@gmail.com> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> <4B230379.3050807@rollernet.us> <4B23102A.4060805@gmail.com> Message-ID: <4B23211C.6050102@rollernet.us> JC Dill wrote: > Seth Mattinen wrote: What I mean was that everyone seems happy with the whole "don't do anything you don't want anyone knowing" thing, then this tangent started. There must be things you don't want people to know that have nothing to do with a potential issue with law enforcement, no? Companies that use gmail must not want trade secrets or IP to be considered fair game for everyone to know? ~Seth From marquis at roble.com Sat Dec 12 05:45:15 2009 From: marquis at roble.com (Roger Marquis) Date: Fri, 11 Dec 2009 21:45:15 -0800 (PST) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: Message-ID: <20091212054515.DF5792B2161@mx5.roble.com> Joe Greco wrote: > Everyone knows a NAT gateway isn't really a firewall, except more or less > accidentally. There's no good way to provide a hardware firewall in an > average residential environment that is not a disaster waiting to happen. Gotta love it. A proven technology, successfully implemented on millions of residential firewalls "isn't really a firewall, but rather "a disaster waiting to happen". Make you wonder what disaster and when exactly it's going to happen? Simon Perreault wrote: > We have thus come to the conclusion that there shouldn't be a > NAT-like firewall in IPv6 home routers. And that, in a nutshell, is why IPv6 is not going to become widely feasible any time soon. Whether or not there should be NAT in IPv6 is a purely rhetorical argument. The markets have spoken, and they demand NAT. Is there a natophobe in the house who thinks there shouldn't be stateful inspection in IPv6? If not then could you explain what overhead NAT requires that stateful inspection hasn't already taken care of? Far from the issue some try to make it out to be, NAT is really just a component of stateful inspection. If you're going to implement statefulness there is no technical downside to implementing NAT as well. No downside, plenty of upsides, no brainer... Roger Marquis From jcdill.lists at gmail.com Sat Dec 12 06:36:48 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 11 Dec 2009 22:36:48 -0800 Subject: news from Google In-Reply-To: <4B23211C.6050102@rollernet.us> References: <20091211133515.47DD1245@resin14.mta.everyone.net> <4B22DED3.1010203@rollernet.us> <4B22F40E.7080901@gmail.com> <4B230379.3050807@rollernet.us> <4B23102A.4060805@gmail.com> <4B23211C.6050102@rollernet.us> Message-ID: <4B233A00.2040807@gmail.com> Seth Mattinen wrote: > JC Dill wrote: >> Seth Mattinen wrote: > > > What I mean was that everyone seems happy with the whole "don't do > anything you don't want anyone knowing" thing, then this tangent > started. There must be things you don't want people to know that have > nothing to do with a potential issue with law enforcement, no? > Companies that use gmail must not want trade secrets or IP to be > considered fair game for everyone to know? True. But email isn't secure, no matter what provider you use. I refer you to the CRU "hacked email server" again, as well as wikileaks, as examples of what can happen. If you really don't want the info to potentially leak out, don't put it on the internet, which also means don't even put it on any internet connected computer. Any information that you send from your computer to anyone else can be leaked. It can be leaked by the recipient - intentionally or accidentally (e.g. forwarding it to the wrong address). It can be leaked by their ISP - and not just their mail provider. If they have a virus/trojan infected computer, (an unfortunately highly likely scenario) it can be stolen. If they sell their used computer, it can be recovered from the hard drive that they "thought" they had cleaned. If they put it on a laptop the laptop can be stolen. These things happen every day. Worrying about it being leaked because they use gmail is far down the list of things to worry about. AFAIK there are no actual cases of information being compromised or leaked because someone used gmail. The #1 thing you can do to minimize that theoretical possible leak, if you care, is to use encryption e.g. PGP. Everyone on NANOG should know all of this already. jc From mohacsi at niif.hu Sat Dec 12 06:55:15 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sat, 12 Dec 2009 07:55:15 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091212054515.DF5792B2161@mx5.roble.com> References: <20091212054515.DF5792B2161@mx5.roble.com> Message-ID: On Fri, 11 Dec 2009, Roger Marquis wrote: > Joe Greco wrote: >> Everyone knows a NAT gateway isn't really a firewall, except more or less >> accidentally. There's no good way to provide a hardware firewall in an >> average residential environment that is not a disaster waiting to happen. > > Gotta love it. A proven technology, successfully implemented on millions > of residential firewalls "isn't really a firewall, but rather "a disaster > waiting to happen". Make you wonder what disaster and when exactly it's > going to happen? > > Simon Perreault wrote: >> We have thus come to the conclusion that there shouldn't be a >> NAT-like firewall in IPv6 home routers. > > And that, in a nutshell, is why IPv6 is not going to become widely > feasible any time soon. > > Whether or not there should be NAT in IPv6 is a purely rhetorical > argument. The markets have spoken, and they demand NAT. > > Is there a natophobe in the house who thinks there shouldn't be stateful > inspection in IPv6? If not then could you explain what overhead NAT > requires that stateful inspection hasn't already taken care of? > > Far from the issue some try to make it out to be, NAT is really just a > component of stateful inspection. If you're going to implement > statefulness there is no technical downside to implementing NAT as well. > No downside, plenty of upsides, no brainer... Nobodoy thinks that statefull firewall is not necessary for IPv6. If you want to particiapte the discussion then comment the IETF v6ops document: http://www.ietf.org/id/draft-ietf-v6ops-cpe-simple-security-08.txt Best Regards, Janos Mohacsi From newton at internode.com.au Sat Dec 12 06:55:22 2009 From: newton at internode.com.au (Mark Newton) Date: Sat, 12 Dec 2009 17:25:22 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B2248A1.9000607@viagenie.ca> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> <4B223E17.3040201@viagenie.ca> <5008.1260536813@localhost> <4B2248A1.9000607@viagenie.ca> Message-ID: <9633A86A-FE24-4C02-A6D1-27AEDF8DD8CF@internode.com.au> On 11/12/2009, at 11:56 PM, Simon Perreault wrote: >> We *know* that if a worm puts up >> a popup that says "Enable port 33493 on your firewall for naked pics of.." >> that port 33493 will get opened anyhow, so we may as well automate the >> process and save everybody the effort. > > Not if the victim doesn't have rights on the firewall (e.g. enterprise). Would you be using "Consumer Grade - IPV6 Enabled Router Firewalls" in the enterprise? 'cos if you would, I think I might have entered the wrong thread :) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From newton at internode.com.au Sat Dec 12 07:09:37 2009 From: newton at internode.com.au (Mark Newton) Date: Sat, 12 Dec 2009 17:39:37 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B224BED.3070904@viagenie.ca> References: <200912111336.nBBDadtt073162@aurora.sol.net> <4B224BED.3070904@viagenie.ca> Message-ID: <1DD81912-EEF8-4299-9687-F57E0E260330@internode.com.au> On 12/12/2009, at 12:11 AM, Simon Perreault wrote: > We have thus come to the conclusion that there shouldn't be a NAT-like firewall > in IPv6 home routers. Eh? What does NAT have to do with anything? We already know that IPv6 residential firewalls won't do NAT, so why bring it into this discussion at all? Some of us are trying to formulate and offer real-life IPv6 services to our marketplaces before IPv4 runs out, and the vendors simply aren't interested in being there to help us out. Pointless distractions about orthogonal issues that don't matter (e.g., NAT) don't help at all. FWIW, I asked Fred Baker about this at the IPv6 Forum meeting in Australia this week. He'd just handled another question about the memory requirements required for burgeoning routing table growth by saying that if routers need extra RAM then routers with extra RAM will appear on the market, because "if you're prepared to pay money for it, we'll try to sell it to you." So I asked, "I'm prepared to pay money for IPv6-capable ADSL2+ CPE. Are you prepared to sell it to me?" and he said, "Yes, just not with our firmware." Which I thought was a bit of a cop-out, given that it was one of our customers who developed the IPv6 openwrt support in the first place, with zero support from Fred's employer, after we'd spent two years hassling them about their lack of action. ... and this is in the same week when, in the context of IPv6, someone else asked me how many units of their gear we'd ship ("Zero. You don't have a product with the features we need so we'll use one of your competitors instead. Lets revisit this when you're prepared to have a conversation that doesn't include `lack of market demand' as a reason for not doing it.") Argh. Disillusionment, much? - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From newton at internode.com.au Sat Dec 12 07:13:24 2009 From: newton at internode.com.au (Mark Newton) Date: Sat, 12 Dec 2009 17:43:24 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091212054515.DF5792B2161@mx5.roble.com> References: <20091212054515.DF5792B2161@mx5.roble.com> Message-ID: <6BEBC626-2E06-4F71-8705-3DED2DBBE3B2@internode.com.au> On 12/12/2009, at 4:15 PM, Roger Marquis wrote: > Is there a natophobe in the house who thinks there shouldn't be stateful > inspection in IPv6? If not then could you explain what overhead NAT > requires that stateful inspection hasn't already taken care of? I handwave past all that by pointing out (as you have) that stateful inspection is just a subset of NAT, where the inside address and the outside address happen to be the same. (in the same way that the SHIM6 middleware boxes which were proposed but never built were /also/ just subsets of NAT, with the translation rules controlled by the SHIM6 protocol layers on the hosts... but we weren't allowed to call them NAT gateways, because IPv6 isn't supposed to have any NAT in it :) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From stmagconsulting at gmail.com Sat Dec 12 09:20:02 2009 From: stmagconsulting at gmail.com (Stephane MAGAND) Date: Sat, 12 Dec 2009 10:20:02 +0100 Subject: Information Request Message-ID: Hello, I am in load d' to study the establishment in North America a company specialized in: Mpls Networks Internet Access Housing/Colloc This establishment must this make is by a creation of a new structure at New York or Washington and at Montreal, or by the acquisition of a holding in a small local operator. Then i write in this list since qu' it touches a great number of professional. Except companies, interested by a bringing together with a European operator has human size, I seek has to know how this master key the collection of T1, DSL and other near the carriers in the USA and Canada. If you could give me ideas of how that this master key, I am taking Thank you Stephane Magand From andy at nosignal.org Sat Dec 12 09:35:29 2009 From: andy at nosignal.org (Andy Davidson) Date: Sat, 12 Dec 2009 09:35:29 +0000 Subject: Optical fiber question In-Reply-To: References: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> Message-ID: <1C247724-7FCA-4A05-86FE-0A22485E7E65@nosignal.org> On 10 Dec 2009, at 18:28, Jared Mauch wrote: > The advantages are always in the distance capabilities of the single > mode fiber. You can reach much further on this, but the optics tend > to be more expensive. If you are going a short distance (eg: 2km or > less) multi-mode is the way. If you're going to go any further, or > want to ever go any further, take the extra cost and know you can > swap optics in the future to do gig, 10G and possibly more (in the > future) with less pain. The cost difference is always up-front one-time as well. LONAP hat on: even though almost all of the fibre terminating on our switch is coming from somewhere else in the same building, trying to insist on single mode makes the eventual 10GE upgrade much, much cheaper and faster, and means that we can concentrate on standardising spare stock and achieve better economies despite being a small org because we always order the same item (and lots of it). Andy From andyzweb at gmail.com Sat Dec 12 09:39:18 2009 From: andyzweb at gmail.com (Andrew Euell) Date: Sat, 12 Dec 2009 04:39:18 -0500 Subject: news from Google In-Reply-To: <00b401ca7454$8fe25490$afa6fdb0$@net> References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> Message-ID: So, why do I have a creeping feeling that google is just running software on level3's servers? Isn't 8.0.0.0/8 announced by level3. Wouldn't that suck up 8.8.8.0/24 and 8.8.4.0/24? On Thu, Dec 3, 2009 at 3:09 PM, Scott Berkman wrote: > Also reminds me of the Level 3 DNS servers in the 4.2.2.[1-8++] range. > > ? ? ? ?-Scott > > -----Original Message----- > From: Jonathan Lassoff [mailto:jof at thejof.com] > Sent: Thursday, December 03, 2009 1:51 PM > To: nanog > Subject: Re: news from Google > > Excerpts from Charles Wyble's message of Thu Dec 03 10:44:49 -0800 2009: >> 8.8.8.8 .... 6.6.6.6 would have been really really funny. :) > > Nice IPs from Level 3, huh? > > 6.6.6.6 belongs to the US Army. > > --j > > > > -- Andrew Euell andyzweb [at] gmail [dot] com From mmc at internode.com.au Sat Dec 12 10:13:28 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 12 Dec 2009 20:43:28 +1030 Subject: Optical fiber question In-Reply-To: References: <40d8a95a0912101024s57abcd0bu9405c2f3f95b1018@mail.gmail.com> Message-ID: <1D284461-BF62-4CCB-A497-8EB855CAE498@internode.com.au> On 11/12/2009, at 4:58 AM, Jared Mauch wrote: > You can reach much further on this, but the optics tend to be more expensive. If you are going a short distance (eg: 2km or less) multi-mode is the way. I can buy LH GigE SFPs for AU$67 each, MM GigE SFPs for AU$61. AU$6 difference is really noise. Bring on Vendor equipment with SFP+ optic support for 10G - AU$1199 for 10G-LR SFP+! ($AU = Australian Dollar which is about US 91c) MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile From matthew at sorbs.net Sat Dec 12 10:35:56 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 12 Dec 2009 11:35:56 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> Message-ID: <4B23720C.6040303@sorbs.net> John R. Levine wrote: > So write to her from a gmail account. APEWS is pretty kooky, and I'm > kind of surprised if SORBS is using it. > We use ASPEWS not APEWS (there is a vast cookiness difference). Shells From matthew at sorbs.net Sat Dec 12 10:51:02 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 12 Dec 2009 11:51:02 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B230483.8070700@rollernet.us> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> Message-ID: <4B237596.3010501@sorbs.net> Seth Mattinen wrote: > > You should still be able to submit a ticket to SORBS, no? I was always > under the impression that it was "open a ticket and wait or you are > moved to the back of the line" with SORBS. That is correct on all counts. The ticket engine is web based and has an interface to email, so anyone listed on ASPEWS (or any other DNSbl we use) can still report issues with ASPEWS (for our continual evaluation on whether to use it) as well as log support tickets and issues about SORBS listings. The initial reply from the support ticket will give you an email and password that will allow you to login to the support interface. Regards, Michelle From matthew at sorbs.net Sat Dec 12 10:54:23 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 12 Dec 2009 11:54:23 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <20091211233929.39504.qmail@simone.iecc.com> References: <20091211233929.39504.qmail@simone.iecc.com> Message-ID: <4B23765F.20603@sorbs.net> John Levine wrote: >> ASPEWS is listing 216.83.32.0/20 as being associated with the whole >> Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being >> involved, nor the provider that belongs to. >> > Since nobody but the occasional highly vocal GWL uses ASPEWS, > Guess I'm a highly vocal GWL then .. ;-) (what ever GWL means) Shells From bbillon-ml at splio.fr Sat Dec 12 11:26:48 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Sat, 12 Dec 2009 12:26:48 +0100 Subject: Data Centre - Advice? (Shenzhen, China) In-Reply-To: References: Message-ID: <4B237DF8.3040307@splio.fr> 1) Define "tier one". NTT got some IDC in China (Beijing, Guangzhou, Hong Kong, Shanghai, Suzhou), but not in Shenzhen. Chinanetcenter would be there: http://www.chinanetcenter.com/wangsu/english/co/Shenzhen_Banxuegang_IDC.htm Remember Hong Kong is well served in Datacenters and upstream providers, and well, just next to Shenzhen. 2) Define "technology foot print" =) Couldn't respecting RFC be a foot print already? No joke, please give more details about your "technology". Best, Benjamin Le 10/12/2009 05:57, Scott E. MacKenzie a ?crit : > Hi, > > > > Does anyone have any great websites to share or advice where I can > locate all the tier one Internet Data Centre (IDC) providers in Shenzhen > China? > > > > My second question would be on any advice that anyone can offer about > the problems that can be faced operating your technology foot print > inside the PRC, if there are any? > > > > Warm Regards, > > > > > > Scott > > From kauer at biplane.com.au Sat Dec 12 11:29:43 2009 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 12 Dec 2009 22:29:43 +1100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091212054515.DF5792B2161@mx5.roble.com> References: <20091212054515.DF5792B2161@mx5.roble.com> Message-ID: <1260617383.12598.158.camel@karl> On Fri, 2009-12-11 at 21:45 -0800, Roger Marquis wrote: > If you're going to implement > statefulness there is no technical downside to implementing NAT as well. > No downside, plenty of upsides, no brainer... Of course there are downsides to implementing NAT - adding any feature to a device increases its complexity and affects its expense, time to market, MTBF etc. And there is certainly a downside to *deploying* NAT: NAT removes end-to-end transparency. Gotta keep those SOHO users in their cages, don't want them becoming independent producers of digital value, no sir! Seriously - by all means keep NAT as a technology for those who want to deploy it; we can't uninvent it anyway. It just shouldn't be imposed on others. I would argue that an ISP requiring of a customer that they use a NATted solution with IPv6 *is* imposing it on others. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From simon.perreault at viagenie.ca Sat Dec 12 12:42:47 2009 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Sat, 12 Dec 2009 07:42:47 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9633A86A-FE24-4C02-A6D1-27AEDF8DD8CF@internode.com.au> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <5217BA53-349E-4EDF-BFFA-D3F5395F36CF@internode.com.au> <4B223E17.3040201@viagenie.ca> <5008.1260536813@localhost> <4B2248A1.9000607@viagenie.ca> <9633A86A-FE24-4C02-A6D1-27AEDF8DD8CF@internode.com.au> Message-ID: <4B238FC7.5040208@viagenie.ca> On 12/12/2009 01:55 AM, Mark Newton wrote: > Would you be using "Consumer Grade - IPV6 Enabled Router Firewalls" in the > enterprise? 'cos if you would, I think I might have entered the wrong > thread :) Yeah, I think I did. Sorry for the noise. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From legacyofbob at gmail.com Sat Dec 12 14:41:00 2009 From: legacyofbob at gmail.com (Joshua Smith) Date: Sat, 12 Dec 2009 09:41:00 -0500 Subject: news from Google In-Reply-To: References: <20091203151630.unc75xb274k48kks@fcaglp.fcaglp.unlp.edu.ar> <202705b0912031021h76c12676i75ac1be9a8573f47@mail.gmail.com> <3F9A8E04-1FB1-46D5-9C8F-F22A2E603165@thewybles.com> <1259866224-sup-8275@sfo.thejof.com> <00b401ca7454$8fe25490$afa6fdb0$@net> Message-ID: On Sat, Dec 12, 2009 at 4:39 AM, Andrew Euell wrote: > So, why do I have a creeping feeling that google is just running > software on level3's servers? Isn't 8.0.0.0/8 announced by level3. > Wouldn't that suck up 8.8.8.0/24 and 8.8.4.0/24? > > On Thu, Dec 3, 2009 at 3:09 PM, Scott Berkman wrote: >> Also reminds me of the Level 3 DNS servers in the 4.2.2.[1-8++] range. >> >> ? ? ? ?-Scott >> >> -----Original Message----- >> From: Jonathan Lassoff [mailto:jof at thejof.com] >> Sent: Thursday, December 03, 2009 1:51 PM >> To: nanog >> Subject: Re: news from Google >> >> Excerpts from Charles Wyble's message of Thu Dec 03 10:44:49 -0800 2009: >>> 8.8.8.8 .... 6.6.6.6 would have been really really funny. :) >> >> Nice IPs from Level 3, huh? >> >> 6.6.6.6 belongs to the US Army. >> >> --j >> >> >> >> > > > > -- > Andrew Euell > andyzweb [at] gmail [dot] com > > 8.8.8.0/24 and 8.8.4.0/24 are being announced by AS15169. That is a more specific route than 8.0.0.0/8. inet.0: 309980 destinations, 1777244 routes (309955 active, 17 holddown, 9 hidden) + = Active Route, - = Last Active, * = Both 8.8.8.0/24 *[BGP/170] 8w4d 00:05:54, MED 0, localpref 100 AS path: 3356 15169 I [BGP/170] 5w2d 20:30:42, MED 0, localpref 100 AS path: 3356 15169 I [BGP/170] 3d 04:32:51, localpref 100 AS path: 7843 15169 I [BGP/170] 6w4d 21:27:00, MED 0, localpref 100 AS path: 3549 15169 I [BGP/170] 4w2d 03:31:39, MED 2, localpref 100 AS path: 2828 7018 15169 I [BGP/170] 1w1d 06:31:35, MED 4, localpref 100 AS path: 1239 3356 15169 I inet.0: 309984 destinations, 1777256 routes (309970 active, 6 holddown, 9 hidden) + = Active Route, - = Last Active, * = Both 8.8.4.0/24 *[BGP/170] 4w4d 16:27:35, MED 0, localpref 100 AS path: 3549 15169 I [BGP/170] 4w1d 21:57:42, MED 0, localpref 100 AS path: 3356 15169 I [BGP/170] 3d 04:36:18, localpref 100 AS path: 7843 15169 I [BGP/170] 4w4d 16:27:48, MED 0, localpref 100 AS path: 7922 15169 I [BGP/170] 5d 02:13:20, MED 3, localpref 100 AS path: 2828 3356 15169 I [BGP/170] 1w1d 06:35:02, MED 4, localpref 100 AS path: 1239 3356 15169 I -Josh From alexandru.petrescu at gmail.com Sat Dec 12 14:44:13 2009 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Sat, 12 Dec 2009 15:44:13 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> Message-ID: <4B23AC3D.4010504@gmail.com> Frank Bulk a ?crit : > I think they're (all) listed here: > http://www.getipv6.info/index.php/Broadband_CPE And from an operators perspective (not manufacturer): Free ISP ADSL (and fiber) operator in France does IPv6 natively to the end user with Router Advertisement since 2 years now. I think these "CPE" (Customer Premises Equipment) are called simply "box" in France (freebox, livebox, dartybox, and more). Between the Free box and the core network there is proprietary IPv6-in-IPv4 encapsualtion, not 6to4. No DHCPv6-PD, which I feel as a big restriction. Plans for livebox and 9box IPv6 do exist if not already deployed. Spanish FON Fonera based on openwrt, when I checked 2008, did IPv6 somehow, not sure whether natively. http://boards.fon.com/viewtopic.php?f=1&t=4532&view=previous From memory, at least one Japanese residential operator did IPv6 to the home several years ago, with explicit IPv6 advertisement on TV during prime time. Alex > > Frank > > -----Original Message----- > From: Wade Peacock [mailto:wade.peacock at sunwave.net] > Sent: Wednesday, December 02, 2009 5:16 PM > To: nanog at nanog.org > Subject: Consumer Grade - IPV6 Enabled Router Firewalls. > > We had a discussion today about IPv6 today. During our open thinking the > topic of client equipment came up. > We all commented that we have not seen any consumer grade IPv6 enable > internet gateways (routers/firewalls), a > kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. > > Does anyone have any leads to information about such products (In production > or planned production)? > > We are thinking that most vendors are going to wait until Ma and Pa home > user are screaming for them. > > Thoughts? > > From alexandru.petrescu at gmail.com Sat Dec 12 14:44:26 2009 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Sat, 12 Dec 2009 15:44:26 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <4B177ABA.70203@internode.com.au> Message-ID: <4B23AC4A.5020601@gmail.com> Mohacsi Janos a ?crit : > > > > On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: > >> >> >> Mohacsi Janos wrote: >>> >>> >>> According to Apple the latest Apple Airport Extreme does support >>> DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. >> Airports don't support DHCPv6 PD yet. I'm led to believe that they >> may in the future from my Apple friends but not yet. > > It does in a limited extent: > http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't seem to say so. If it is it would be wonderful. > I will check soon the hardware. Great, please report, thanks, Alex > > > Best Regards, > Janos Mohacsi > > > From matthew at sorbs.net Sat Dec 12 17:02:08 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 12 Dec 2009 18:02:08 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B237596.3010501@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> Message-ID: <4B23CC90.3070702@sorbs.net> Michelle Sullivan wrote: > Seth Mattinen wrote: >> >> You should still be able to submit a ticket to SORBS, no? I was >> always under the impression that it was "open a ticket and wait or >> you are moved to the back of the line" with SORBS. > > That is correct on all counts. Oh and to re-iterate a point made so many times in so many forums and so often ignored. Posting to any of my email personal addresses will not help your case at all.. ever.. in any way... and in fact posting to some of the old and disused ones will likely cause a spamtrap listing. SORBS Support is done through the SORBS support system (which is what it is there fore funnily enough!) Posting on mailing lists, or emailing to me, other SORBS staff, or GFI will result in various responses from completely ignoring you to sending you a PDF that tells you that you can only gain support through the SORBS support system - NO EXCEPTIONS. The only thing my email address is valid for is if the SORBS Support system is down for telling me such (and I have plenty of systems monitoring all components of it so an email is pretty pointless in most cases.) Robot rejection and refusal to delist is not a failure in the support system... Read the response and act upon the contents if you want a review. Sorry if that sounds harsh, but when you had seen even a couple of the idiotic messages I get, you'll understand why. Logging a ticket is simple if a little ownerous (it takes 7 clicks to get a ticket logged, 3 if you use the contact form!) Michelle PS: Here is an example or 5 of tickets logged in the support system (unedited except for the last) and all in the queue that specifically states "do not send listing or delisting requests here"... ---- Name: Yiannos Efthymiou Company: AT Multitech Corporation Type: company Primary OS: windows Skill Level: admin DB: ---- Yes a windows admin logged a support ticket with no IP address or domain, or well.. anything... ---- Name: Andrzej Wojciechowski Type: person Primary OS: windows Skill Level: luser DB: ---- And another .. these are the total contents of the tickets (email addresses are stored in the headers which I haven't reproduced for privacy... ---- Name: german perez Company: roulette partners s.a. Type: company Primary OS: unix Skill Level: admin DB: ---- Number 3.. ok now I'm going to skip down tickets until I find something other than just the auto-inserted stuff... This one logged no less than 3 of the same tickets... ---- Name: Danilo Jaramillo Company: sistemas inalambricos Type: company Primary OS: unix Skill Level: admin DB: Additional Information: why if the ip it's not used, you do not delist automatically??? ---- ... thought: "If it is not used how did it get listed in the first place?...and another... ---- Name: Vladimir Goloshchuk Type: na Primary OS: windows Skill Level: admin DB: Additional Information: Our ip used to be listed in more than 10 blacklists due to the spam breaks. We have cleaned our system and most of email blacklist databases have white listed us. There are only 3 databases left that still have our IP blacklisted. your database is one of them. Please white list our IP as email is a vital part of our customers business and this prevents from sending/receiving legitimate emails with other clients. Regards, Vladimir ---- Each of these have gone to http://www.sorbs.net/cgi-bin/support and clicked "No" to the question "Do you need help or support about a listing, delisting, or blocked IP address?" (it defaults to "Yes")* * They have also clicked through the following text: Please Note: Logging a support ticket about a listing using this form will result in nothing happening; you will not receive a reply from the support staff; nor will the request result in a listing or delisting. This form is for all the requests other than those for listing and delisting addresses, domains or mail servers. We also receive delisting request via the same method.... ----* *Name: Chris ****** Company: ******** Communications Type: company Primary OS: windows Skill Level: admin DB: Additional Information: We currentlym have a router with in our network that has its NAT listed with you. We have recently taken steps to elimanate this probelm. The IPs in question are within this subnet 24.***.***.225/29. Please let me know if we could have these delisted. Best Regards, Chris ******** ***** Communications Inc. ***-***-**** *****@******.ca ---- This one I did edit to remove the identifying details. It's obvious the person speaks English, so there is not the defense that they didn't understand the "STOP" sign or the text I have already posted. NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM! Michelle From rubensk at gmail.com Sat Dec 12 18:26:45 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 12 Dec 2009 16:26:45 -0200 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> Message-ID: <6bb5f5b10912121026y17e1f91ejf5faa3ae757b5439@mail.gmail.com> >> You're correct, out of the box there aren't many. ?The first couple that come to mind are the Apple Airport Express and Airport Extreme, but I don't believe Linksys/Netgear/etc. have support out of the box. > > The Apple products do 6to4 out of the box, but don't support v6 natively. > > Apple seems to have ideological objections to DHCPv6, so at the moment > there's little hope at all that prefix delegation will work on any of their > CPE products. Can Airport relay the DHCPv6 request to the service provider ? Rubens From rubensk at gmail.com Sat Dec 12 18:48:05 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 12 Dec 2009 16:48:05 -0200 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> Message-ID: <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> > I challenge the usual suspects to deliver actual working dual stack IPv6 ADSL CPE rather than feigning interest. ? None of the major CPE vendors appear to have a v6 plan despite your claims. ? We have an IPv6 dual stack trial for ADSL going on and not a single CPE from the _major consumer CPE vendors_. I've saw some ADSL CPEs that could bridge specific frame types. It would be feasible to think of an ADSL CPE that would simply bridge IPv4/ARP and IPv6 ethertypes and have a dual-stack BRAS service the users, or bridge IPv4/ARP to a VC(Virtual Circuit) and IPv6 to another VC, or NAT+Route IPv4 to a VC and bridge IPv6 to other VC. In an IPv6 world where NAT is not a requirement (paranoids are welcome to buy their own IPv6 firewalls), bridging with some L4 intelligence might be all that a CPE needs to do. The IPv6 idea of letting end-nodes have more work and intermediate nodes have less work also applies to CPEs. Rubens From morrowc.lists at gmail.com Sat Dec 12 19:02:03 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 12 Dec 2009 14:02:03 -0500 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <1260563720.4148.116.camel@petrie> References: <1260520619.4148.99.camel@petrie> <60B0F2124D07B942988329B5B7CA393D020BE87537@mail2.FireEye.com> <1260563720.4148.116.camel@petrie> Message-ID: <75cb24520912121102u21b8f72cic28deb170e7d057d@mail.gmail.com> On Fri, Dec 11, 2009 at 3:35 PM, William Pitcock wrote: >> Name: ? www.googleadservices.com >> Address: 67.210.14.113 > > That is Cernal, and it is hosted in Russia now. not unless 'russia' moved a whole lot closer to 'ashburn,va' in the last little while (or wormhole network technology is available) 4 0.xe-4-2-0.BR1.IAD8.ALTER.NET (152.63.32.161) 8 ms 0.xe-7-3-0.BR1.IAD8.ALTER.NET (152.63.32.158) 6 ms 0.xe-4-2-0.BR1.IAD8.ALTER.NET (152.63.32.161) 10 ms 5 194.25.211.17 (194.25.211.17) 7 ms 8 ms 7 ms 6 217.239.40.38 (217.239.40.38) 13 ms 12 ms 24 ms 7 217.6.49.126 (217.6.49.126) 12 ms 15 ms 12 ms 8 67-210-14-113-rev.ineting.net (67.210.14.113) 15 ms 14 ms 15 ms (note upstream here is DT) > Cernal and Atrivo are two different entities, Atrivo used to host > Cernal, but now they have different hosting arrangements. 85.255.114.0/24 today routes: 5 0.xe-9-0-0.BR1.IAD8.ALTER.NET (152.63.41.49) 8 ms 6 ms 0.xe-10-0-0.BR1.IAD8.ALTER.NET (152.63.41.149) 8 ms 6 dcp-brdr-02.inet.qwest.net (63.146.26.105) 9 ms 9 ms 10 ms 7 dcx-core-01.inet.qwest.net (205.171.251.33) 10 ms 14 ms 10 ms 8 cer-core-01.inet.qwest.net (67.14.8.202) 30 ms cer-core-02.inet.qwest.net (67.14.8.22) 28 ms cer-core-01.inet.qwest.net (67.14.8.202) 29 ms 9 chx-edge-02.inet.qwest.net (205.171.139.61) 172 ms 32 ms chx-edge-02.inet.qwest.net (205.171.139.57) 30 ms 10 63.146.238.218 (63.146.238.218) 29 ms 29 ms 30 ms (note QWest is the upstream) Right, two different ASN's originating prefixes, they seem to have different 'locations' (or connections to networks in two different tier-1 cities (chicago based on naming vs nyc-area based upon rtt) The two entities seem to have a very tightly linked business though, and have for quite some time. > Can people get a clue and understand this very critical difference? sure, the difference being the act of changing names on top level entities every period of time ('names will be changed to protect the innocent') and providers as the providers notice sales folk did 'bad' things.. It doesn't help to say things like: "Thats hosted in russia" when clearly it is not... it also doesn't help to try and separate the 2 clearly inseparable entities. -chris From nenolod at systeminplace.net Sat Dec 12 21:10:38 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 12 Dec 2009 15:10:38 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B23CC90.3070702@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> Message-ID: <1260652238.4532.48.camel@petrie> Hi, On Sat, 2009-12-12 at 18:02 +0100, Michelle Sullivan wrote: > Michelle Sullivan wrote: > > Seth Mattinen wrote: > >> > >> You should still be able to submit a ticket to SORBS, no? I was > >> always under the impression that it was "open a ticket and wait or > >> you are moved to the back of the line" with SORBS. > > > > That is correct on all counts. > Oh and to re-iterate a point made so many times in so many forums and so > often ignored. Posting to any of my email personal addresses will not > help your case at all.. ever.. in any way... and in fact posting to some > of the old and disused ones will likely cause a spamtrap listing. SORBS > Support is done through the SORBS support system (which is what it is > there fore funnily enough!) Posting on mailing lists, or emailing to > me, other SORBS staff, or GFI will result in various responses from > completely ignoring you to sending you a PDF that tells you that you can > only gain support through the SORBS support system - NO EXCEPTIONS. The > only thing my email address is valid for is if the SORBS Support system > is down for telling me such (and I have plenty of systems monitoring all > components of it so an email is pretty pointless in most cases.) Robot > rejection and refusal to delist is not a failure in the support > system... Read the response and act upon the contents if you want a review. > > Sorry if that sounds harsh, but when you had seen even a couple of the > idiotic messages I get, you'll understand why. Logging a ticket is > simple if a little ownerous (it takes 7 clicks to get a ticket logged, 3 > if you use the contact form!) Perhaps people wouldn't have to email you if the robot actually did what it said it was going to do. Your website promises that the robot will get things delisted out of the DUHL zone in "3 to 5 hours". It has been more than "3 to 5 hours", and it is costing me money. Considering that you shouldn't have listed the space to begin with, I think it would be fantastic if you updated the website to reflect the reality of the situation. While I am sorry to hear that most of the people you deal with are morons, it does not change the facts that SORBS listed IP address space for no valid reason, other than the first version of the RDNS not having .static. in it. Perhaps if this sort of thing didn't keep happening, on a regular basis, we would never hear about SORBS, MAPS, or any other RBLs on NANOG in a bad light. Personally, I like SORBS. I would like to continue to be able to use SORBS on my mail servers. The fact that my addresses are listed as being dynamic in SORBS when they are not, and it hasn't been fixed in the timeframe that the website promises it would be fixed in, is making me re-evaluate whether or not I should use SORBS and recommend it to people looking for good DNSBLs to use on their mailservers. > NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM! Then you should make your delisting process more streamlined. You already have a robot for most things, make it do the next step and just delist the IP ranges it is given. William From frnkblk at iname.com Sat Dec 12 23:40:23 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 12 Dec 2009 17:40:23 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> Message-ID: Unless I haven't put the full picture together, yet, but for my PPPoA/E environment I would like a DSL CPE that: - on the WAN interface does IPv4 (with NAT support) and IPv6 over PPPoE combined with DHCP-PD (with a stateful firewall). - on the LAN interface does the regular IPv4 stuff, Link-Local only, static IPv6, and stateful and stateless DHCPv6. - allows me to run IPv4, IPv6, or both For my bridged environments (whether that be DSL or FTTH) I would like a CPE that - on the WAN interface does IPv4 (with NAT support), IPv6 with Link-Local only, static IPv6, and IPv6 with DHCP-PD (with a stateful firewall). - on the LAN interface does the regular IPv4 stuff, Link-Local only, static IPv6, and stateful and stateless DHCPv6. - allows me to run IPv4, IPv6, or both While the support burden will be raised, I think the network needs to be dual-stack from end-to-end if SPs want to keep middle-boxes out. But for those who really do run out of IPv4 addresses, I'm not sure how middle-boxes can be avoided. Kind of hard to tell customer n+1 that they can only visit the IPv6 part of the web. Perhaps new customers will have to use a service provider's CGN and share IPv4 addresses until enough of the internet is dual-stack. Frank -----Original Message----- From: Rubens Kuhl [mailto:rubensk at gmail.com] Sent: Saturday, December 12, 2009 12:48 PM To: nanog at nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. > I challenge the usual suspects to deliver actual working dual stack IPv6 ADSL CPE rather than feigning interest. ? None of the major CPE vendors appear to have a v6 plan despite your claims. ? We have an IPv6 dual stack trial for ADSL going on and not a single CPE from the _major consumer CPE vendors_. I've saw some ADSL CPEs that could bridge specific frame types. It would be feasible to think of an ADSL CPE that would simply bridge IPv4/ARP and IPv6 ethertypes and have a dual-stack BRAS service the users, or bridge IPv4/ARP to a VC(Virtual Circuit) and IPv6 to another VC, or NAT+Route IPv4 to a VC and bridge IPv6 to other VC. In an IPv6 world where NAT is not a requirement (paranoids are welcome to buy their own IPv6 firewalls), bridging with some L4 intelligence might be all that a CPE needs to do. The IPv6 idea of letting end-nodes have more work and intermediate nodes have less work also applies to CPEs. Rubens From mohacsi at niif.hu Sun Dec 13 09:22:59 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sun, 13 Dec 2009 10:22:59 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B23AC3D.4010504@gmail.com> References: <4B16F535.70306@sunwave.net> <4B23AC3D.4010504@gmail.com> Message-ID: On Sat, 12 Dec 2009, Alexandru Petrescu wrote: > Frank Bulk a ?crit : >> I think they're (all) listed here: >> http://www.getipv6.info/index.php/Broadband_CPE > > And from an operators perspective (not manufacturer): > > Free ISP ADSL (and fiber) operator in France does IPv6 natively to the end > user with Router Advertisement since 2 years now. I think these "CPE" > (Customer Premises Equipment) are called simply "box" in France (freebox, > livebox, dartybox, and more). Between the Free box and the core network > there is proprietary IPv6-in-IPv4 encapsualtion, not 6to4. No DHCPv6-PD, > which I feel as a big restriction. implementing 6rd (which is used by Free) also a big restriction. > > Plans for livebox and 9box IPv6 do exist if not already deployed. > > Spanish FON Fonera based on openwrt, when I checked 2008, did IPv6 somehow, > not sure whether natively. > http://boards.fon.com/viewtopic.php?f=1&t=4532&view=previous > > From memory, at least one Japanese residential operator did IPv6 to the home > several years ago, with explicit IPv6 advertisement on TV during prime time. > > Alex > >> >> Frank >> >> -----Original Message----- >> From: Wade Peacock [mailto:wade.peacock at sunwave.net] Sent: Wednesday, >> December 02, 2009 5:16 PM >> To: nanog at nanog.org >> Subject: Consumer Grade - IPV6 Enabled Router Firewalls. >> >> We had a discussion today about IPv6 today. During our open thinking the >> topic of client equipment came up. >> We all commented that we have not seen any consumer grade IPv6 enable >> internet gateways (routers/firewalls), a kin to the ever popular Linksys >> 54G series, DLinks , SMCs or Netgears. >> >> Does anyone have any leads to information about such products (In >> production >> or planned production)? >> >> We are thinking that most vendors are going to wait until Ma and Pa home >> user are screaming for them. >> >> Thoughts? >> >> > > > From mohacsi at niif.hu Sun Dec 13 09:24:13 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sun, 13 Dec 2009 10:24:13 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B23AC4A.5020601@gmail.com> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <4B177ABA.70203@internode.com.au> <4B23AC4A.5020601@gmail.com> Message-ID: On Sat, 12 Dec 2009, Alexandru Petrescu wrote: > Mohacsi Janos a ?crit : >> >> >> >> On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: >> >>> >>> >>> Mohacsi Janos wrote: >>>> >>>> >>>> According to Apple the latest Apple Airport Extreme does support DHCPv6 >>>> prefix delegation and native IPv6 uplink not only 6to4. >>> Airports don't support DHCPv6 PD yet. I'm led to believe that they may >>> in the future from my Apple friends but not yet. >> >> It does in a limited extent: >> http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html > > Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't seem > to say so. If it is it would be wonderful. They do: "DHCP6 client requests prefix delegation, advertised on LAN bridge" Best Regards, Janos Mohacsi From joelja at bogus.com Sun Dec 13 17:17:37 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Dec 2009 09:17:37 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> Message-ID: <4B2521B1.7080603@bogus.com> Owen DeLong wrote: > > On Dec 10, 2009, at 4:56 PM, Michael Loftis wrote: > >> >> >> --On Wednesday, December 02, 2009 6:23 PM -0800 Mehmet Akcin >> wrote: >> >>> Would you consider Juniper SSG5 as a Consumer Grade router? >>> >>> They do IPv6 and they are pretty good in general, and cheap as well. >>> >> >> Not as usable in the consumer space due to lack of UPnP (and Juniper >> is NOT interested in implementing it). They also lack some other >> customer friendly features. >> > UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. > > You don't need UPnP if you'r not doing NAT. wishful thinking. you're likely to still have a staeful firewall and in the consumer space someone is likely to want to punch holes in it. >> Price point is also probably 3x-5x what most are willing to pay for CPE. > > Yep. > > Side-note, SRX-100 is the new SSG-5 equivalent and it's JunOS instead of > ScreenOS. Nice box. > > Owen > > From newton at internode.com.au Sun Dec 13 20:16:31 2009 From: newton at internode.com.au (Mark Newton) Date: Mon, 14 Dec 2009 06:46:31 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> Message-ID: On 13/12/2009, at 10:10 AM, Frank Bulk wrote: > While the support burden will be raised, I think the network needs to be > dual-stack from end-to-end if SPs want to keep middle-boxes out. But for > those who really do run out of IPv4 addresses, I'm not sure how middle-boxes > can be avoided. Kind of hard to tell customer n+1 that they can only visit > the IPv6 part of the web. Perhaps new customers will have to use a service > provider's CGN and share IPv4 addresses until enough of the internet is > dual-stack. The most likely outcome I can see is that customers on services which feature dynamic IPv4 addresses (mostly residential) will end up behind a CGN on a dual stack service. I fully expect the CGN to suck mightily, mitigated somewhat by the fact that the customer would also happen to have a non-NATted IPv6 address if they upgrade their CPE to take advantage of it. Despite the suckage, as long as email, web and VoIP keeps working I think most residential customers wouldn't notice the CGN imposition at all. The act of putting those customers behind a CGN would immediately free up enough IPv4 addresses that the ISP concerned would have a virtually limitless supply for fixed-IP business-grade services -- "virtually" limitless in the sense that there'd be enough to feed those services with new addresses for however much time it takes to complete an IPv6 transition. How long will that take? I don't think it'll be anywhere near as long as most people appear to be expecting. Sure, there'll be a large installed base of printers and home entertainment devices running legacy IPv4-only software, but by and large they either don't need Internet access at all or are quite happy talking to the world through NAT, and can be mostly ignored for the purpose of a discussion about transition durations (in the same way that we ignored all the HP JetDirect cards when we talked about how long it took to turn the Internet classless). I reckon CGNs will be so bad, with so many bugs and so much support overhead that service providers and customers alike will want to move past them as quickly as humanly possible, and the whole transition will be all done and dusted in a few years from their implementation. It's going to be a total and absolute disaster, and the only way out of it will be to move forward. Of course, all of this is predicated on the notion that CGNs will actually exist. As far as I can tell they're all vapourware at the moment. If there's one thing I've learned from all of this it's that roadmap announcements aren't worth anything, and that if the vendors ever do actually manage to get around to shipping something it'll be so poorly thought out that it's impractical to use in a service provider environment until version 2 -- which, in the case of CGN, will be too late. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From mloftis at wgops.com Sun Dec 13 20:48:18 2009 From: mloftis at wgops.com (Michael Loftis) Date: Sun, 13 Dec 2009 13:48:18 -0700 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B2521B1.7080603@bogus.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> Message-ID: <6DE8DE9759A7055F2980C797@[192.168.1.44]> --On Sunday, December 13, 2009 9:17 AM -0800 Joel Jaeggli wrote: >> UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. >> >> You don't need UPnP if you'r not doing NAT. > > wishful thinking. > > you're likely to still have a staeful firewall and in the consumer space > someone is likely to want to punch holes in it. Amen indeed. Consumers do not care if its a good idea or not. And honestly in a home network, well, its not as frightening. In a business of any kind (including home based) it is bad. You should have a DMZ with carefully controlled open ports lists. But that's preaching to the choir here. IPv6 doesn't magically negate the need for UPnP, UPnP is not tied to NAT. It's a way for applications to ask the firewall to selectively open ports up to them. Intelligent stateful firewalls can do that for limited applications, perhaps with some sort of policy control even. Though Joe/Jill Gamer (which is what UPnP is for) won't know anything about any of that. They define a gateway as functioning or not. I really am honestly sick of people thinking IPv6 is a panacea. It isn't. UPnP is rather a bit of a hack for sure, protocols should be better designed, but in this modern age of Peer To Peer you need a way for applications to ask the firewall to selectively open incoming ports. From marka at isc.org Sun Dec 13 22:13:57 2009 From: marka at isc.org (Mark Andrews) Date: Mon, 14 Dec 2009 09:13:57 +1100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: Your message of "Mon, 14 Dec 2009 06:46:31 +1030." References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> Message-ID: <200912132213.nBDMDvoF014563@drugs.dv.isc.org> In message , Mark Newton writes: > Of course, all of this is predicated on the notion that CGNs will > actually exist. As far as I can tell they're all vapourware at the > moment. Comcast commissioned ISC to develop a working CGN. We are in the final release stages of our CGN product, AFTR. https://www.isc.org/software/aftr You can go and download it now it you want. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From frnkblk at iname.com Sun Dec 13 22:54:07 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 13 Dec 2009 16:54:07 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <200912132213.nBDMDvoF014563@drugs.dv.isc.org> References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> <200912132213.nBDMDvoF014563@drugs.dv.isc.org> Message-ID: Thanks for the link. The most obvious question to me is scalability. What box is going to be running AFTR to do all this translation? It looks like the B4 part is running on the customer's CPE, but if we need to move hundreds of Mbps, if not Gbps, wouldn't that require some C/J/F class type of box? Frank -----Original Message----- From: marka at isc.org [mailto:marka at isc.org] Sent: Sunday, December 13, 2009 4:14 PM To: Mark Newton Cc: frnkblk at iname.com; nanog at nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. In message , Mark Newton writes: > Of course, all of this is predicated on the notion that CGNs will > actually exist. As far as I can tell they're all vapourware at the > moment. Comcast commissioned ISC to develop a working CGN. We are in the final release stages of our CGN product, AFTR. https://www.isc.org/software/aftr You can go and download it now it you want. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From newton at internode.com.au Sun Dec 13 23:44:25 2009 From: newton at internode.com.au (Mark Newton) Date: Mon, 14 Dec 2009 10:14:25 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4533DA29-186C-4610-AC1B-C0D73BD1B03D@cisco.com> <6bb5f5b10912121048n2c163556kd991d8e775d0597@mail.gmail.com> Message-ID: <85C408D6-B0FB-4A67-A9EA-CB5C93F2583A@internode.com.au> On 14/12/2009, at 9:38 AM, Frank Bulk wrote: > I hope you're right. I really hope that there's this phenomenal transition > in 2011 of content from 0.1% IPv6-accessible to 99% IPv6-accessible. Forget content, they're just along for the ride. When most service providers have eye-wateringly shite CGNs acting as intermediaries between eyeballs and content, the content providers will be motivated to move to v6 even if only as a means of damage control. > And > not even by node count, but by percentage of traffic. And pain is one way > to get there. Every few months I think of the number of truck rolls we'll > need to do to swap out DSL modems and SOHO routers with their IPv6 > equivalents. Ah, that's something we don't have. Our customers own their own (which has its own slew of problems: I can't make them upgrade, and if I tell them they'll have to spend a hundred bucks to restore the functionality I broke for them last week I'll have a revolt on my hands...) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From wilhelm at ripe.net Mon Dec 14 00:26:45 2009 From: wilhelm at ripe.net (Rene Wilhelm) Date: Mon, 14 Dec 2009 01:26:45 +0100 Subject: More ASN collissions In-Reply-To: <82638dhn8l.fsf@mid.bfk.de> References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> <20091210232119.GA9697@ussenterprise.ufp.org> <4B21B1AC.60908@ripe.net> <82638dhn8l.fsf@mid.bfk.de> Message-ID: <4B258645.7000201@ripe.net> Florian Weimer wrote: > * Rene Wilhelm: > >> AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at >> whois.ripe.net is a user created object in the RIPE routing registry, not >> an assignment by RIPE NCC. > > How can you tell one from the other? Is the lack of an org: attribute > reliable? > The info is in the as-block object which whois.ripe.net returns in addition to the aut-num object when you do a default query for an AS number. For example for as43210 you get this: as-block: AS43008 - AS44031 descr: RIPE NCC ASN block remarks: These AS Numbers are further assigned to network remarks: operators in the RIPE NCC service region. AS remarks: assignment policy is documented in: remarks: remarks: RIPE NCC members can request AS Numbers using the remarks: form available in the LIR Portal or at: remarks: org: ORG-NCC1-RIPE admin-c: CREW-RIPE tech-c: RD132-RIPE mnt-by: RIPE-DBM-MNT mnt-lower: RIPE-NCC-HM-MNT source: RIPE # Filtered [...] Only AS numbers which are covered by "RIPE NCC ASN blocks" have been assigned by RIPE NCC or transferred to RIPE NCC (like AS1707). -- Rene From shoshon at shoshon.ro Mon Dec 14 09:30:15 2009 From: shoshon at shoshon.ro (Bogdan) Date: Mon, 14 Dec 2009 11:30:15 +0200 Subject: level3 europe problems Message-ID: <4B2605A7.9090005@shoshon.ro> hello from friday, after a peer reset from level3, we've started to have some issues with the bgp session with level3 1. first they sent us just around 4000 prefixes (instead of ~300k) 2. then nothing, we opened a trouble ticket and they said they rebooted a router, and so on. (we saw an interesting graph in decix http://www.decix.net/content/network.html ) 3. after that, the connection seemed to be ok. all prefixes received but: - some websites, including level3.net were loading very slow sometimes, sometimes not at all. - dns issues with hosts around the world - some ipsec tunnel around the world not working, some did, and same with telnet/snmp. - mtr not working to some hosts, ping always looked ok. 4. the second i shutd the neighbor, all communication was ok. i made several tests, and as soon as the peer was up, the problem begun. peer down - all was ok on the other providers. did anyone else exeprienced this kind of issues? the ticket is still open, but we did't recieved any rfo etr for 2,5 days :) From matthew at sorbs.net Mon Dec 14 10:32:48 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Mon, 14 Dec 2009 11:32:48 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B23CC90.3070702@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> Message-ID: <4B261450.8070704@sorbs.net> William wrote: > Hi, > > > > Perhaps people wouldn't have to email you if the robot actually did what > it said it was going to do. Your website promises that the robot will > get things delisted out of the DUHL zone in "3 to 5 hours". > Please feel free to show me *any* SORBS webpage that says this because the robot cannot delist you, it just approves you for delisting. > It has been more than "3 to 5 hours", and it is costing me money. > Considering that you shouldn't have listed the space to begin with, I > think it would be fantastic if you updated the website to reflect the > reality of the situation. > Then tell me where it says 3-5 hours and I'll correct the text. > While I am sorry to hear that most of the people you deal with are > morons, it does not change the facts that SORBS listed IP address space > for no valid reason, other than the first version of the RDNS not > having .static. in it. > The robot doesn't list or delist so the entry was added at some point because of either spam, or it's an old entry that has not had any requests to update. The robot will reject certain patterns of DNS, you can always reply to the ticket as the whois contact to get delisted outside of what the robot says (as it says in the robot reply) thought it should be noted that I don't care who contacts me, if the rDNS is clearly dynamic (eg: ..dyn..) you're not going to get delisted at all. > Perhaps if this sort of thing didn't keep happening, on a regular basis, > we would never hear about SORBS, MAPS, or any other RBLs on NANOG in a > bad light. > > Personally, I like SORBS. I would like to continue to be able to use > SORBS on my mail servers. The fact that my addresses are listed as > being dynamic in SORBS when they are not, and it hasn't been fixed in > the timeframe that the website promises it would be fixed in, is making > me re-evaluate whether or not I should use SORBS and recommend it to > people looking for good DNSBLs to use on their mailservers. > > > NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM! > > Then you should make your delisting process more streamlined. You > already have a robot for most things, make it do the next step and just > delist the IP ranges it is given. > The process has been more and more streamlined as time has progressed. The support system will ask questions and will allow you to either delist or request delisting very easily. If you are an ISP you can (at the moment) use the mail/contact form to submit a request to the manual queue immediately... and anyone can send requests by email to the support system bypassing the whole "we'll gather the information via a web form" script, but the robot will reply, and if you do not meet the acceptance criteria by the robot you need to read the message and act upon it (eg: it will usually tell you to reply to the ticket after correcting something). In your case I have reviewed the address space and I see the robot will approve it for delisting, no questions (or should do) however it will have replied with something like the following: ---- I'm a robot writing you on behalf of the SORBS' admins. The reason you're getting this automated response, is our desire to provide you with consistent and fast responses. I'm prepared to correctly analyze most of the cases appearing in the DUHL queue. You might want to keep your responses as short as possible (and to trim my own responses) to help humans better serve you should the need arise. I'm glad to report that the IP space will be submitted for delisting from the DUHL. Best regards. SORBS ---- Read the last paragraph again.. "will be submitted for delisting" .. not "has been delisted and it will take 3-5 hours to propagate"... I have to process all removals manually after the robot because the robot does get it wrong, and then you have the likes of JustHost and the spammers there that keep requesting delisting with totally bogus (but static looking) hosts. Michelle From jgreco at ns.sol.net Mon Dec 14 13:13:55 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 14 Dec 2009 07:13:55 -0600 (CST) Subject: news from Google In-Reply-To: from "Peter Beckman" at Dec 11, 2009 03:57:10 PM Message-ID: <200912141313.nBEDDt6n065490@aurora.sol.net> > If you aren't breaking the law, the government won't be looking for your > data, and won't ask Google/Yahoo/Bing/AltaVista or other search companies > for your data. This seems overly optimistic. Remember the whole telecom fiasco? Even if you are breaking the law in some mild way, do you really want the government to be using toll records or traffic-cams to enforce speeding laws, etc? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From owen at delong.com Mon Dec 14 09:08:36 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Dec 2009 01:08:36 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <6DE8DE9759A7055F2980C797@[192.168.1.44]> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <6DE8DE9759A7055F2980C797@[192.168.1.44]> Message-ID: <83F0BAEB-5D9A-4EEE-B275-78AE3C9CCB72@delong.com> > I really am honestly sick of people thinking IPv6 is a panacea. It > isn't. UPnP is rather a bit of a hack for sure, protocols should be > better designed, but in this modern age of Peer To Peer you need a > way for applications to ask the firewall to selectively open > incoming ports. > > If the addresses of your gaming machines are no longer dynamic and their ports are no longer getting dynamically remapped, why do you need that instead of a way to tell the firewall that X machine is allowed to receive packets on Y ports from Z hostlist (where X,Z can be wildcarded, and, Y can be some form of list, range, or list of ranges)? No, IPv6 is not a panacea. However, IPv6 does eliminate the need for rapidly changing addresses on hosts that need to accept inbound connections, which makes it possible to define policy for those hosts rather than just trusting unauthenticated arbitrary applications to amend your security policy at your border. UPnP is the firewall equivalent of having US CBP admit any person who has someone in the US say that they should be admitted. While I do support some level of immigration reform and more open borders than has been the trend of late, even I would not go that far. Owen From owen at delong.com Mon Dec 14 08:58:45 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Dec 2009 00:58:45 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B2521B1.7080603@bogus.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> Message-ID: <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> >> UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. >> >> You don't need UPnP if you'r not doing NAT. > > wishful thinking. > > you're likely to still have a staeful firewall and in the consumer > space > someone is likely to want to punch holes in it. Yes, SI will still be needed. However, UPnP is, at it's heart a way to allow arbitrary unauthenticated applications the power to amend your security policy to their will. Can you possibly explain any way in which such a thing is at all superior to no firewall at all? I would argue that a firewall that can be reconfigured by any applet a user clicks on (whether they know it or not) is actually less useful than no firewall because it creates the illusion in the users mind that there is a firewall protecting them. Owen From gordslater at ieee.org Mon Dec 14 18:35:16 2009 From: gordslater at ieee.org (gordon b slater) Date: Mon, 14 Dec 2009 18:35:16 +0000 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> Message-ID: <1260815716.7436.27.camel@ub-g-d2> On Mon, 2009-12-14 at 00:58 -0800, Owen DeLong wrote: > However, UPnP is, at it's heart a way > to allow > arbitrary unauthenticated applications the power to amend your security > policy to their will. Can you possibly explain any way in which such a > thing is at all superior to no firewall at all? > > I would argue that a firewall that can be reconfigured by any applet a > user > clicks on (whether they know it or not) is actually less useful than no > firewall because it creates the illusion in the users mind that there > is a > firewall protecting them. Well, for many years I've argued (since I read an early draft of the proposal for uPnP ) that it really stood for "Unstoppable-Peek-and-Poke". It scares the hell outta me, full stop, way more than the users themselves - and they scare me a lot anyways. Seems a good time to ask while everyone's thinking about it: I wonder if anyone actually has first-hand experience of any el-cheapo plastic "home user" routers (say sub-50$US) that are worth a look at for low-end system trials? Zyxel maybe? I see Andrews & Arnold (in the UK) sell them and seem to rate them quite highly, yet the price is, frankly, a giveaway. Any thoughts? Ignoring, of course, the sad and embarassing fact that much of the UK's national telco backbone isn't v6 capable - a long (and buggy) story in itself, once you start trying to implement practical v6 end-to-end ) Gord From cmadams at hiwaay.net Mon Dec 14 19:11:53 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 14 Dec 2009 13:11:53 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> Message-ID: <20091214191153.GE1094301@hiwaay.net> Once upon a time, Owen DeLong said: > I would argue that a firewall that can be reconfigured by any applet a > user > clicks on (whether they know it or not) is actually less useful than no > firewall because it creates the illusion in the users mind that there > is a > firewall protecting them. Well, "any applet a user clicks on" should not have permission to talk to random devices on the network (for example, Java applets can't do that), so I don't think it quite as bad as you make it out to be. I also don't really find the "computer is already compromised" case all that interesting, as at that point, all bets are off (since with C&C servers, compromised computers are already accessible to the outside world without UPnP). A firewall protects against unwanted inbound connections to things like file/print sharing, DNS proxies, etc. You also don't get port scans and such (even with a few open ports, the majority being "drop" slows down scanners significantly). You can also configure it to prevent certain outbound connections (e.g. connecting to random mail servers from desktop PCs). I would hope that you can configure firewall rules to override UPnP requests. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nanog at capequilog.com Mon Dec 14 19:35:50 2009 From: nanog at capequilog.com (Jeff Wheelhouse) Date: Mon, 14 Dec 2009 14:35:50 -0500 Subject: Global Crossing IPv6 on hold? Message-ID: Hi All, We recently received our ::/32 allocation from ARIN, and when we went to set up IPv6 BGP with one of our transit providers, Global Crossing, we were told new IPv6 sessions were (direct quote) "not available at this time." Attempts to get an ETA or even an explanation why have so far been fruitless. Can that be right? I've always thought of Global Crossing as an IPv6 leader. Has anyone else heard anything about this? Thanks, Jeff From houdini+nanog at clanspum.net Mon Dec 14 19:39:13 2009 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Mon, 14 Dec 2009 13:39:13 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B261450.8070704@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> Message-ID: <20091214193913.GN22555@clanspum.net> Michelle Sullivan(matthew at sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM +0100: > > William wrote: >> Hi, > >> Perhaps people wouldn't have to email you if the robot actually did what >> it said it was going to do. Your website promises that the robot will >> get things delisted out of the DUHL zone in "3 to 5 hours". > > Please feel free to show me *any* SORBS webpage that says this because > the robot cannot delist you, it just approves you for delisting. > >> It has been more than "3 to 5 hours", and it is costing me money. >> Considering that you shouldn't have listed the space to begin with, I >> think it would be fantastic if you updated the website to reflect the >> reality of the situation. > > Then tell me where it says 3-5 hours and I'll correct the text. On http://www.au.sorbs.net/cgi-bin/support , I read: "This will route any created ticket to the robot handler which will process and delist the netblock (upto /24) within a few hours" That says the robot will delist (not schedule to delist) "within a few hours". -- Bill Weiss From mohacsi at niif.hu Mon Dec 14 20:21:08 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 14 Dec 2009 21:21:08 +0100 (CET) Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> Message-ID: On Mon, 14 Dec 2009, Owen DeLong wrote: >>> UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. >>> >>> You don't need UPnP if you'r not doing NAT. >> >> wishful thinking. >> >> you're likely to still have a stateful firewall and in the consumer space >> someone is likely to want to punch holes in it. > > Yes, SI will still be needed. However, UPnP is, at it's heart a way to allow > arbitrary unauthenticated applications the power to amend your security > policy to their will. Can you possibly explain any way in which such a > thing is at all superior to no firewall at all? Because of the least surprise principle: Users get used to have NAT ~> they expect similar stateful firewall in IPv6. They get used to use UPnP in IPv4 ~> they expect something similar in IPv6. I don't think this is good, but bad engineering decision of UPnP cannot replaced with better ones overnight. Best Regards, Janos Mohacsi From kevin at steadfast.net Mon Dec 14 20:57:58 2009 From: kevin at steadfast.net (Kevin Stange) Date: Mon, 14 Dec 2009 14:57:58 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B261450.8070704@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> Message-ID: <4B26A6D6.1010601@steadfast.net> On 12/14/2009 04:32 AM, Michelle Sullivan wrote: > I'm a robot writing you on behalf of the SORBS' admins. The reason > you're getting this automated response, is our desire to provide you > with consistent and fast responses. I'm prepared to correctly analyze > most of the cases appearing in the DUHL queue. This last sentence seems to be my point of contention here. I am trying to get a /18 removed from the DUHL and every time the robot tells me some arbitrary ranges I did not mention explicitly are being tested and/or not eligible for delisting. Since the ranges not eligible are configured the same as those that are, I can't figure this out. Replying to the robot resulted in no response for a month, so I ended up submitting a ticket via the ISP contact form directly, with all the information requested, but the first time, someone just pushed my request back to the robot and it refused ranges again. I understand you get a lot of traffic to your ticket system, but I have to wonder whether a system which is so complex and large that it is near impossible to support and keep maintained accurately is actually still useful. I assume you love (to some degree) helping kill spammers, but maybe you need to solicit (screened) volunteers to expand your staffing? -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From nenolod at systeminplace.net Mon Dec 14 21:44:13 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 14 Dec 2009 15:44:13 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B261450.8070704@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> Message-ID: <1260827053.6328.15.camel@petrie> On Mon, 2009-12-14 at 11:32 +0100, Michelle Sullivan wrote: > Read the last paragraph again.. "will be submitted for delisting" .. not > "has been delisted and it will take 3-5 hours to propagate"... I have to > process all removals manually after the robot because the robot does get > it wrong, and then you have the likes of JustHost and the spammers there > that keep requesting delisting with totally bogus (but static looking) > hosts. And then you take several days if not several weeks to delist them. You have spent a considerably longer time replying to people on NANOG discussing your policies on NANOG, when you could just delist the IPs in question already. Like I said before, I am sorry that you deal with a lot of morons, but maybe like others have said, you need to add more staff to your project. William From nanog at capequilog.com Tue Dec 15 02:31:25 2009 From: nanog at capequilog.com (Jeff Wheelhouse) Date: Mon, 14 Dec 2009 21:31:25 -0500 Subject: Global Crossing IPv6 on hold? In-Reply-To: References: Message-ID: <403F5B69-6950-47B1-9E1E-499E4D634022@capequilog.com> Thanks to all who responded. Someone at Global Crossing saw my message and they were supremely helpful in identifying the problem. Long story short, we provisioned that circuit through a third party, and there was some propagation error during the IPv6 order processing. Short story shorter: Global Crossing IPv6 on hold? No. Thanks, Jeff From joelja at bogus.com Tue Dec 15 04:47:52 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 14 Dec 2009 20:47:52 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> Message-ID: <4B2714F8.4050701@bogus.com> Owen DeLong wrote: >>> UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. >>> >>> You don't need UPnP if you'r not doing NAT. >> >> wishful thinking. >> >> you're likely to still have a staeful firewall and in the consumer space >> someone is likely to want to punch holes in it. > > Yes, SI will still be needed. However, UPnP is, at it's heart a way to > allow > arbitrary unauthenticated applications the power to amend your security > policy to their will. Can you possibly explain any way in which such a > thing is at all superior to no firewall at all? I'm a consumer, I want to buy something, take it home, turn it on and have it work. I don't have an IT department. How the manufacturers solve that is their problem. As a consumer my preferences for a security posture to the extent that I have one are: don't hose me don't make my life any more complicated than necessary > I would argue that a firewall that can be reconfigured by any applet a user > clicks on (whether they know it or not) is actually less useful than no > firewall because it creates the illusion in the users mind that there is a > firewall protecting them. Stable outgoing connections for p2p apps, messaging, gaming platforms and foo website with java script based rpc mechanisms have similar properties. I don't sleep soundly at night becasuse the $49 buffalo router I bought off an endcap at frys uses iptables, I sleep soundly because I don't care. > Owen > From nenolod at systeminplace.net Tue Dec 15 04:57:58 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 14 Dec 2009 22:57:58 -0600 Subject: IP to authoritative CIDR webservices Message-ID: <1260853078.6328.19.camel@petrie> Hi, Does anyone know of a webservice that converts a given IP into the public CIDR range that belongs to? I am developing a tool where IP to CIDR conversion based on RIR whois data would be useful for implementing filtersets. William From smb at cs.columbia.edu Tue Dec 15 05:10:58 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 15 Dec 2009 00:10:58 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B2714F8.4050701@bogus.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> <4B2714F8.4050701@bogus.com> Message-ID: <2BDE5380-B69F-4068-AF7B-40E0724C9C91@cs.columbia.edu> On Dec 14, 2009, at 11:47 PM, Joel Jaeggli wrote: > > > Owen DeLong wrote: >>>> UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. >>>> >>>> You don't need UPnP if you'r not doing NAT. >>> >>> wishful thinking. >>> >>> you're likely to still have a staeful firewall and in the consumer space >>> someone is likely to want to punch holes in it. >> >> Yes, SI will still be needed. However, UPnP is, at it's heart a way to >> allow >> arbitrary unauthenticated applications the power to amend your security >> policy to their will. Can you possibly explain any way in which such a >> thing is at all superior to no firewall at all? > > I'm a consumer, I want to buy something, take it home, turn it on and > have it work. I don't have an IT department. How the manufacturers solve > that is their problem. > > As a consumer my preferences for a security posture to the extent that I > have one are: > > don't hose me > > don't make my life any more complicated than necessary > >> I would argue that a firewall that can be reconfigured by any applet a user >> clicks on (whether they know it or not) is actually less useful than no >> firewall because it creates the illusion in the users mind that there is a >> firewall protecting them. > > Stable outgoing connections for p2p apps, messaging, gaming platforms > and foo website with java script based rpc mechanisms have similar > properties. I don't sleep soundly at night becasuse the $49 buffalo > router I bought off an endcap at frys uses iptables, I sleep soundly > because I don't care. > Precisely. And if you want to get picky, remember that "availability" is part of the standard definition of security. A firewall that doesn't let me play Chocolate-Sucking Zombie Monsters is an attack on the availability of that gmae, albeit from the purest of motives. No, I'm not saying that this is good. I am saying that in the real world, it *will* happen. --Steve Bellovin, http://www.cs.columbia.edu/~smb From fergdawgster at gmail.com Tue Dec 15 05:12:28 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 14 Dec 2009 21:12:28 -0800 Subject: IP to authoritative CIDR webservices In-Reply-To: <1260853078.6328.19.camel@petrie> References: <1260853078.6328.19.camel@petrie> Message-ID: <6cd462c00912142112l5903b68flaaa23a04e62b69d6@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Dec 14, 2009 at 8:57 PM, William Pitcock wrote: > Hi, > > Does anyone know of a webservice that converts a given IP into the > public CIDR range that belongs to? I am developing a tool where IP to > CIDR conversion based on RIR whois data would be useful for implementing > filtersets. > WHOIS? Alternatively, use the Team Cymru tool to find the AS, then the CIDR Report portal to determine all perfixes originated by the AS in question: http://asn.cymru.com/ http://www.cidr-report.org/ Apologies if you are seeking other magic... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLJxq3q1pz9mNUZTMRArwbAKDDc0cVkSzbFegAR2iaPzyYvE5vGgCdHeZ2 Sq9wnK0xuf9bz4Z+pxprkX8= =a0cv -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nenolod at systeminplace.net Tue Dec 15 05:13:28 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 14 Dec 2009 23:13:28 -0600 Subject: IP to authoritative CIDR webservices In-Reply-To: References: <1260853078.6328.19.camel@petrie> Message-ID: <1260854008.6328.28.camel@petrie> Hi, On Mon, 2009-12-14 at 21:10 -0800, Mehmet Akcin wrote: > Current RIR whois actually does that. > > ie: search for 199.4.29 > it will show you 199.4.28/22 Yes, but it has to be parsed, and RIRs have varying whois formats. ARIN vs RIPE whois output, for example. William From nenolod at systeminplace.net Tue Dec 15 05:18:23 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 14 Dec 2009 23:18:23 -0600 Subject: IP to authoritative CIDR webservices In-Reply-To: <6cd462c00912142112l5903b68flaaa23a04e62b69d6@mail.gmail.com> References: <1260853078.6328.19.camel@petrie> <6cd462c00912142112l5903b68flaaa23a04e62b69d6@mail.gmail.com> Message-ID: <1260854303.6328.36.camel@petrie> Hi, On Mon, 2009-12-14 at 21:12 -0800, Paul Ferguson wrote: > On Mon, Dec 14, 2009 at 8:57 PM, William Pitcock > wrote: > > > Hi, > > > > Does anyone know of a webservice that converts a given IP into the > > public CIDR range that belongs to? I am developing a tool where IP to > > CIDR conversion based on RIR whois data would be useful for implementing > > filtersets. > > > > WHOIS? > > Alternatively, use the Team Cymru tool to find the AS, then the CIDR Report > portal to determine all perfixes originated by the AS in question: > > http://asn.cymru.com/ Looks like their WHOIS server in verbose mode will do the trick for what I want, as it provides predictable output. Thank you. William From reed at reedloden.com Tue Dec 15 05:28:35 2009 From: reed at reedloden.com (Reed Loden) Date: Tue, 15 Dec 2009 00:28:35 -0500 Subject: IP to authoritative CIDR webservices In-Reply-To: <1260854008.6328.28.camel@petrie> References: <1260853078.6328.19.camel@petrie> <1260854008.6328.28.camel@petrie> Message-ID: <20091215002835.46c72c41.reed@reedloden.com> On Mon, 14 Dec 2009 23:13:28 -0600 William Pitcock wrote: > On Mon, 2009-12-14 at 21:10 -0800, Mehmet Akcin wrote: > > Current RIR whois actually does that. > > > > ie: search for 199.4.29 > > it will show you 199.4.28/22 > > Yes, but it has to be parsed, and RIRs have varying whois formats. ARIN > vs RIPE whois output, for example. You might could modify the CyberAbuse Whois (zcw) client[1] to also output CIDR information. It already outputs range information, so shouldn't be hard to add CIDR support to what it displays. I'll contact the author to see if he could add that, as it would be a useful feature for all. ~reed [1] http://www.cyberabuse.org/whois/ -- Reed Loden - -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From james at now.ie Tue Dec 15 12:27:03 2009 From: james at now.ie (James Raftery) Date: Tue, 15 Dec 2009 12:27:03 +0000 Subject: IP to authoritative CIDR webservices In-Reply-To: <1260854008.6328.28.camel@petrie> References: <1260854008.6328.28.camel@petrie> Message-ID: <20091215122703.GA44694@morbo.kerna.ie> On Mon, Dec 14, 2009 at 11:13:28PM -0600, William Pitcock wrote: > Yes, but it has to be parsed, and RIRs have varying whois formats. ARIN > vs RIPE whois output, for example. This is very easy to parse, though not a "web service": ftp://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt james -- ``It's somewhere in the Red Hat district'' -- A network engineer's freudian slip when talking about Amsterdam's nightlife at RIPE 38. From joakim at aronius.com Tue Dec 15 12:49:54 2009 From: joakim at aronius.com (Joakim Aronius) Date: Tue, 15 Dec 2009 13:49:54 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <2BDE5380-B69F-4068-AF7B-40E0724C9C91@cs.columbia.edu> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> <4B2714F8.4050701@bogus.com> <2BDE5380-B69F-4068-AF7B-40E0724C9C91@cs.columbia.edu> Message-ID: <20091215124954.GA22285@maya.aronius.com> * Steven Bellovin (smb at cs.columbia.edu) wrote: > > On Dec 14, 2009, at 11:47 PM, Joel Jaeggli wrote: > > Owen DeLong wrote: > > Stable outgoing connections for p2p apps, messaging, gaming platforms > > and foo website with java script based rpc mechanisms have similar > > properties. I don't sleep soundly at night becasuse the $49 buffalo > > router I bought off an endcap at frys uses iptables, I sleep soundly > > because I don't care. > > > Precisely. And if you want to get picky, remember that "availability" is part > of the standard definition of security. A firewall that doesn't let me play > Chocolate-Sucking Zombie Monsters is an attack on the availability of that > gmae, albeit from the purest of motives. > > No, I'm not saying that this is good. I am saying that in the real world, it > *will* happen. So what you are saying is that ease of use and service availability is priority one. Then what exactly are the responsibilities of the ISP and CPE manufacturer when it comes to security? CPEs with WiFi usually comes with the advice to change password etc. Is it ok to build an infrastructure relying on UPnP, write a disclaimer, and let the end user handle eventual problems? (I assume it is...) /jkm From newton at internode.com.au Tue Dec 15 13:03:04 2009 From: newton at internode.com.au (Mark Newton) Date: Tue, 15 Dec 2009 23:33:04 +1030 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091215124954.GA22285@maya.aronius.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> <4B2714F8.4050701@bogus.com> <2BDE5380-B69F-4068-AF7B-40E0724C9C91@cs.columbia.edu> <20091215124954.GA22285@maya.aronius.com> Message-ID: On 15/12/2009, at 11:19 PM, Joakim Aronius wrote: > So what you are saying is that ease of use and service availability is priority one. Then what exactly are the responsibilities of the ISP and CPE manufacturer when it comes to security? CPEs with WiFi usually comes with the advice to change password etc. Is it ok to build an infrastructure relying on UPnP, write a disclaimer, and let the end user handle eventual problems? (I assume it is...) Hasn't essentially every ISP on the planet been doing that for years, only without the disclaimer? It's not like we're talking about creating UPnP from whole cloth. We're discussing a replacement of like-for-like, updating existing capabilities to support IPv6. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From twilde at cymru.com Tue Dec 15 14:43:47 2009 From: twilde at cymru.com (Tim Wilde) Date: Tue, 15 Dec 2009 09:43:47 -0500 Subject: IP to authoritative CIDR webservices In-Reply-To: <1260854303.6328.36.camel@petrie> References: <1260853078.6328.19.camel@petrie> <6cd462c00912142112l5903b68flaaa23a04e62b69d6@mail.gmail.com> <1260854303.6328.36.camel@petrie> Message-ID: <4B27A0A3.80005@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 12:18 AM, William Pitcock wrote: >> http://asn.cymru.com/ > > Looks like their WHOIS server in verbose mode will do the trick for what > I want, as it provides predictable output. Thank you. For the record, the prefix you find here will be the prefix our BGP view (from peers around the globe) sees that IP announced as, which is not necessarily the same as the RIR allocated prefix. And you can find full details of all of the access methods for this service here: http://www.team-cymru.org/Services/ip-to-asn.html Please make note of the notice at the top of the page regarding use in software, applications, and devices - if we have advance notice we can make sure we're not going to accidentally block you or your users, but only if you get in touch with us first. :) Thanks, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksnoKMACgkQluRbRini9tg5dACePR1UW3eLF4LTQ3BkWIdy1B/+ E3IAnjTeU5TeJQkEHLKE7c+CceFyVPU+ =FmpZ -----END PGP SIGNATURE----- From eesslinger at fpu-tn.com Tue Dec 15 15:17:40 2009 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 15 Dec 2009 09:17:40 -0600 Subject: DNS question, null MX records Message-ID: I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.com IN MX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From mark at streamservice.nl Tue Dec 15 15:31:08 2009 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 15 Dec 2009 16:31:08 +0100 Subject: DNS question, null MX records In-Reply-To: References: Message-ID: <014401ca7d9b$9fb850e0$df28f2a0$@nl> Hello, You could use: Local.example.com. IN A 127.0.0.1 Example.com. IN MX 10 local.example.com. This way systems shouldn't deliver it at your system. What you did mention is something we don't allow our customers to do (if I am correct). With kind regards, Mark Scholten -----Original Message----- From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] Sent: dinsdag 15 december 2009 16:18 To: 'nanog at nanog.org' Subject: DNS question, null MX records I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.com IN MX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From fweimer at bfk.de Tue Dec 15 15:32:23 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 15 Dec 2009 15:32:23 +0000 Subject: DNS question, null MX records In-Reply-To: (Eric J. Esslinger's message of "Tue\, 15 Dec 2009 09\:17\:40 -0600") References: Message-ID: <827hsonth4.fsf@mid.bfk.de> * Eric J. Esslinger: > I found a reference to a null MX proposal, constructed so: > example.com IN MX 0 . I think this is quite controversal. The best approach still seems to be an SMTP rejecter on a dedicated IP address. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From patrick at ianai.net Tue Dec 15 15:33:25 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 15 Dec 2009 10:33:25 -0500 Subject: DNS question, null MX records In-Reply-To: References: Message-ID: <61DEF465-D0FE-41AB-B528-77FD8C341F3B@ianai.net> On Dec 15, 2009, at 10:17 AM, Eric J Esslinger wrote: > I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) > > I found a reference to a null MX proposal, constructed so: > example.com IN MX 0 . > > Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. It's valid. But if you think all spammers will respect it, you're in for a surprise. :( There is also a recommendation to point the MX at somewhere unroutable (192.2.x.x IIRC, but don't quote me on that). This will force the spammer / bot to try to connect to something that does not exist and use up sockets & resources, hopefully slowing it down. I've also heard that pointing the MX at localhost is useful, for reasons that should be obvious. The latter has the slight advantage of not making networks with a default route carry packets to the DFZ. I'm sure some will find errors with all three suggestions. I honestly don't know which is the best / worst. Personally I'd set up a tiny mail server that accepted connections & feed them to /dev/null, or maybe forwarded the whole feed to a spam trap or DCC or the like. -- TTFN, patrick From dsparro at gmail.com Tue Dec 15 15:45:09 2009 From: dsparro at gmail.com (Dave Sparro) Date: Tue, 15 Dec 2009 10:45:09 -0500 Subject: DNS question, null MX records In-Reply-To: References: Message-ID: <4B27AF05.9070001@gmail.com> On 12/15/2009 10:17 AM, Eric J Esslinger wrote: > I found a reference to a null MX proposal, constructed so: > example.com IN MX 0 . > > Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. > Pulling from my often mangled memory: This was proposed in a draft RFC that went nowhere. Parsing the Null MX record was implemented in at least one fairly popular MTA (Postfix?) The null MX record was published by whoever got (some of?) the Excite @Home domain(s) after that company flamed out. This results in the occasional post to various mailing lists by people wondering why they are queuing mail bound for said domain. So to the point of your question, it may reduce some SMTP connection attempts to you, but will not likely eliminate them. -- Dave From eesslinger at fpu-tn.com Tue Dec 15 15:46:06 2009 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 15 Dec 2009 09:46:06 -0600 Subject: DNS question, null MX records In-Reply-To: Message-ID: I've had a couple of off-list comments already about using it as/donating it to a spam trap; That is a good idea and I actually thought of that. However, the address was formerly used for email addresses for our customers and for our business (some 10 years ago it was registered, but has not had any valid dns records set for roughly 6 years), and we still deal from time to time with mail being sent to old addresses on that domain for various reasons (several dns registrations, for example, we've had to help these people go through the fax change system because we don't want to go to the trouble of setting up to receive email on this domain again) So in any case, due to customer privacy concerns we feel we can't do that. Also I have set the spf -all on it, for those that look for these records to auot-reject email from the domain. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 -----Original Message----- From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] Sent: Tuesday, December 15, 2009 9:18 AM To: 'nanog at nanog.org' Subject: DNS question, null MX records I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.com IN MX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From sjk at sleepycatz.com Tue Dec 15 16:00:19 2009 From: sjk at sleepycatz.com (sjk) Date: Tue, 15 Dec 2009 10:00:19 -0600 Subject: Cyclops Down? Message-ID: <4B27B293.3090503@sleepycatz.com> Is anyone else seeing cyclops down -- or is it just me? mtr -c10 -r 131.179.96.253 4. osh-2828-peer.onshore.net 0.0% 10 1.3 1.3 1.2 1.6 0.1 5. ip65-47-181-105.z181-47-65.c 0.0% 10 1.4 2.0 1.3 3.7 0.8 6. ge11-1-4d0.mcr2.chicago-il.u 0.0% 10 2.1 1.7 1.4 2.1 0.3 7. ae1d0.mcr1.chicago-il.us.xo. 0.0% 10 2.7 11.8 1.8 34.9 13.4 8. 216.156.0.161.ptr.us.xo.net 0.0% 10 62.2 62.3 62.0 62.8 0.3 9. te-3-2-0.rar3.dallas-tx.us.x 0.0% 10 61.1 61.8 61.0 64.2 1.0 10. 207.88.12.46.ptr.us.xo.net 0.0% 10 61.6 61.6 60.7 63.8 1.1 11. 207.88.12.158.ptr.us.xo.net 0.0% 10 60.7 61.0 60.7 61.7 0.4 12. lax-px1--xo-ge.cenic.net 0.0% 10 60.5 60.8 60.4 61.4 0.4 13. dc-lax-core1--lax-peer1-ge.c 0.0% 10 61.5 61.5 61.1 62.1 0.4 14. dc-lax-agg1--lax-core1-ge.ce 0.0% 10 61.1 61.6 60.8 63.5 0.9 15. dc-ucla--lax-agg1-ge-2.cenic 0.0% 10 62.0 62.6 61.7 65.1 1.3 16. border-2--core-1-ge.backbone 0.0% 10 62.4 62.4 61.8 63.4 0.5 17. core-1--mathsci-10ge.backbon 0.0% 10 61.9 61.7 61.4 62.1 0.2 18. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 From andy at nosignal.org Tue Dec 15 16:06:15 2009 From: andy at nosignal.org (Andy Davidson) Date: Tue, 15 Dec 2009 16:06:15 +0000 Subject: DNS question, null MX records In-Reply-To: References: Message-ID: <4B27B3F7.7060007@nosignal.org> Eric J Esslinger wrote: > I have a domain that exists solely to cname A records to another domain's websites. [...] > I found a reference to a null MX proposal, constructed so: > example.com IN MX 0 . [...] > Question: Is this a valid dns construct or did the proposal die? It's "valid", but you will probably find people still try to spam to machines on the A records, and all of the other weird and wonderful things that spambots try to do to find a path that will deliver mail... If there is no time that mail should appear *from* this domain name then it's polite to set spf records as such - one of the few things spf is always useful for :-) like this : @ IN TXT "v=spf1 -all" ... all this means in practice though is that spammers who actually bother to check for this, will find someone else to masquerade. But you won't have to deal with the associated attempted bounce delivery connections... Best wishes Andy From matthew at sorbs.net Tue Dec 15 16:17:03 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Tue, 15 Dec 2009 17:17:03 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <20091214193913.GN22555@clanspum.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> <20091214193913.GN22555@clanspum.net> Message-ID: <4B27B67F.5090401@sorbs.net> Bill Weiss wrote: > Michelle Sullivan(matthew at sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM +0100: > >> >> Then tell me where it says 3-5 hours and I'll correct the text. >> > > On http://www.au.sorbs.net/cgi-bin/support , I read: > "This will route any created ticket to the robot handler which will > process and delist the netblock (upto /24) within a few hours" > > That says the robot will delist (not schedule to delist) "within a few > hours". > > Thank you, I wasn't aware, and it will be corrected (doesn't say 3-5hours still so I'd love to find that one). Michelle From jmamodio at gmail.com Tue Dec 15 16:27:49 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 15 Dec 2009 10:27:49 -0600 Subject: Cyclops Down? In-Reply-To: <4B27B293.3090503@sleepycatz.com> References: <4B27B293.3090503@sleepycatz.com> Message-ID: <202705b0912150827r1db9006cn958983fb62adf88d@mail.gmail.com> Looks from from SATX (TWC/RoadRunner) Jorge On Tue, Dec 15, 2009 at 10:00 AM, sjk wrote: > Is anyone else seeing cyclops down -- or is it just me? > > ?mtr -c10 -r 131.179.96.253 From matthew at sorbs.net Tue Dec 15 16:32:45 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Tue, 15 Dec 2009 17:32:45 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B26A6D6.1010601@steadfast.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> <4B26A6D6.1010601@steadfast.net> Message-ID: <4B27BA2D.9040500@sorbs.net> Kevin Stange wrote: > On 12/14/2009 04:32 AM, Michelle Sullivan wrote: > > >> I'm a robot writing you on behalf of the SORBS' admins. The reason >> you're getting this automated response, is our desire to provide you >> with consistent and fast responses. I'm prepared to correctly analyze >> most of the cases appearing in the DUHL queue. >> > > > This last sentence seems to be my point of contention here. I am trying > to get a /18 removed from the DUHL and every time the robot tells me > some arbitrary ranges I did not mention explicitly are being tested > and/or not eligible for delisting. Since the ranges not eligible are > configured the same as those that are, I can't figure this out. > Replying to the robot resulted in no response for a month, so I ended up > submitting a ticket via the ISP contact form directly, with all the > information requested, but the first time, someone just pushed my > request back to the robot and it refused ranges again. > This sometimes happens, particularly if the request doesn't come with an ASN and/or no authoritative contact (ie: not from the email used in the whois records for that netblock). For what it's worth using the following syntax when sending to duhl at support.sorbs.net can force the robot's view: BEGIN SORBS LIST / . . . / END SORBS LIST Will force the robot to only look at the networks within the tags (case is sensitive) Submitting ranges over /16 with this method will result in ticket rejection. rDNS will be scanned in all cases, rDNS is cached locally for a minimum of 48 hours, so if you are rejected because some rDNS appears dynamic, you will need to get a human to manually rescan or approve for delisting, or wait 48 hours for the cache to be ignored. The cache is web viewable and publicly accessible, please email me offlist to michelle at sorbs.net if you want to know where the cache is. > I understand you get a lot of traffic to your ticket system, but I have > to wonder whether a system which is so complex and large that it is near > impossible to support and keep maintained accurately is actually still > useful. I assume you love (to some degree) helping kill spammers, but > maybe you need to solicit (screened) volunteers to expand your staffing? > > We do, and getting technically clueful people who are trustworthy seems to be an issue. We got hit by the 'trustworthy' aspect some time ago, and the clueful aspect is a regular problem. I am hoping that the buy out by GFI will provide some paid 24x7 staff, obviously I cannot comment about where that is going any further, but we all know things take time Currently I am working full time on processing tickets as well as other duties in relation to improving all systems, but I actually need to stop answering tickets completely to complete those other systems... Those other systems will allow approved entities to access the SORBS database directly (and not just for DUHL requests) this system was devised in 2003, initially developed in 2004 and promised in 2005 however with everything that has happened to me in the last 4 years it has been delayed, delayed and delayed yet again. Patience seems to be the key for all concerned as there is currently only one of me. Michelle From scott.wolfe at cybera.net Tue Dec 15 16:50:04 2009 From: scott.wolfe at cybera.net (Scott Wolfe) Date: Tue, 15 Dec 2009 10:50:04 -0600 Subject: Customer issue connecting to TWTelecom Message-ID: <48FAC036AD7B7642BB2944FB9AE674A306666590@EXCHANGE.nashville.cybera.net> Can someone from TW Telecom contact me offlist? I have a customer having issues connecting to a TW Telecom hosted site. Scott Wolfe Cybera, Inc 615-301-2346 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From rveloso at cs.ucla.edu Tue Dec 15 17:42:35 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Tue, 15 Dec 2009 09:42:35 -0800 Subject: Cyclops Down? In-Reply-To: <4B27B293.3090503@sleepycatz.com> References: <4B27B293.3090503@sleepycatz.com> Message-ID: <6E94368B-A144-42AE-851F-B1BE947A4B9D@cs.ucla.edu> Hi all, We're having an issue with an UPS here at UCLA where one of the Cyclops servers is connected to. It should be fixed very soon, will keep you posted.. Thanks, --Ricardo On Dec 15, 2009, at 8:00 AM, sjk wrote: > Is anyone else seeing cyclops down -- or is it just me? > > mtr -c10 -r 131.179.96.253 > > 4. osh-2828-peer.onshore.net 0.0% 10 1.3 1.3 1.2 > 1.6 0.1 > 5. ip65-47-181-105.z181-47-65.c 0.0% 10 1.4 2.0 1.3 > 3.7 0.8 > 6. ge11-1-4d0.mcr2.chicago-il.u 0.0% 10 2.1 1.7 1.4 > 2.1 0.3 > 7. ae1d0.mcr1.chicago-il.us.xo. 0.0% 10 2.7 11.8 1.8 > 34.9 13.4 > 8. 216.156.0.161.ptr.us.xo.net 0.0% 10 62.2 62.3 62.0 > 62.8 0.3 > 9. te-3-2-0.rar3.dallas-tx.us.x 0.0% 10 61.1 61.8 61.0 > 64.2 1.0 > 10. 207.88.12.46.ptr.us.xo.net 0.0% 10 61.6 61.6 60.7 > 63.8 1.1 > 11. 207.88.12.158.ptr.us.xo.net 0.0% 10 60.7 61.0 60.7 > 61.7 0.4 > 12. lax-px1--xo-ge.cenic.net 0.0% 10 60.5 60.8 60.4 > 61.4 0.4 > 13. dc-lax-core1--lax-peer1-ge.c 0.0% 10 61.5 61.5 61.1 > 62.1 0.4 > 14. dc-lax-agg1--lax-core1-ge.ce 0.0% 10 61.1 61.6 60.8 > 63.5 0.9 > 15. dc-ucla--lax-agg1-ge-2.cenic 0.0% 10 62.0 62.6 61.7 > 65.1 1.3 > 16. border-2--core-1-ge.backbone 0.0% 10 62.4 62.4 61.8 > 63.4 0.5 > 17. core-1--mathsci-10ge.backbon 0.0% 10 61.9 61.7 61.4 > 62.1 0.2 > 18. ??? 100.0 10 0.0 0.0 0.0 > 0.0 0.0 > From eesslinger at fpu-tn.com Tue Dec 15 17:51:29 2009 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 15 Dec 2009 11:51:29 -0600 Subject: DNS question, null MX records *summary of on list and off list replies* In-Reply-To: Message-ID: A. Use a valid domain mapped to an unroutable or loopback instead of the . I've decided to use 127.0.0.1 B. Set spf -all, for those who bother to check that to stop inbound mail from your domain. Already had that in place C. Donate the spam to someone who would use it. I can't donate the existing incoming email due to privacy concerns, however, project honeypot uses subdomains (foo at bar.example.com) for it's spam traps and wants unused subdomains so it's traps will be 'clean to start'. I'll see if I can get that done. D. Expect some spammers to detect any MX strangeness you use and bypass it in favor of your A record. Understandable, and none of the referenced records in the DNS files accept mail from outside, connections are silently dropped at the firewall. This is just an attempt to cut the mess coming in because of the A record down in size. E. Set up an actual mail server routing all mail to /dev/null. I'd rather just drop the traffic rather than have another service to maintain/secure/update __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 -----Original Message----- From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] Sent: Tuesday, December 15, 2009 9:18 AM To: 'nanog at nanog.org' Subject: DNS question, null MX records I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.com IN MX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From kevin at steadfast.net Tue Dec 15 18:43:33 2009 From: kevin at steadfast.net (Kevin Stange) Date: Tue, 15 Dec 2009 12:43:33 -0600 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B27B67F.5090401@sorbs.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> <20091214193913.GN22555@clanspum.net> <4B27B67F.5090401@sorbs.net> Message-ID: <4B27D8D5.8060108@steadfast.net> On 12/15/2009 10:17 AM, Michelle Sullivan wrote: > Bill Weiss wrote: >> Michelle Sullivan(matthew at sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM >> +0100: >> >>> >>> Then tell me where it says 3-5 hours and I'll correct the text. >>> >> >> On http://www.au.sorbs.net/cgi-bin/support , I read: >> "This will route any created ticket to the robot handler which will >> process and delist the netblock (upto /24) within a few hours" >> >> That says the robot will delist (not schedule to delist) "within a few >> hours". >> >> > > Thank you, I wasn't aware, and it will be corrected (doesn't say > 3-5hours still so I'd love to find that one). > There is this text I see, which seems to disagree with the robot's behavior in my case (from the Dynamic IP FAQ): "The Regional Internet Registry (RIR) Point of Contact (PoC) can request a listing or delisting of any address in their space. The only time this will be refused is when the netblock information in the RIR or in the reverse DNS naming clearly indicates the addresses are dynamically assigned (e.g. 0.1.pool.example.com). " I'm sending my request from our PoC and it's not taking my word for it like is claimed here (since the reverse DNS certainly doesn't imply the ranges are dynamic). If you don't consider this part of the policy anymore, you might want to clear that up in the FAQ. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From rveloso at cs.ucla.edu Tue Dec 15 18:56:36 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Tue, 15 Dec 2009 10:56:36 -0800 Subject: Cyclops Down? In-Reply-To: <4B27B293.3090503@sleepycatz.com> References: <4B27B293.3090503@sleepycatz.com> Message-ID: <4B8C5AD9-4A94-4CAA-A633-0382A5901900@cs.ucla.edu> Cyclops is online now, apologies for the disruption. Best, --Ricardo On Dec 15, 2009, at 8:00 AM, sjk wrote: > Is anyone else seeing cyclops down -- or is it just me? > > mtr -c10 -r 131.179.96.253 > > 4. osh-2828-peer.onshore.net 0.0% 10 1.3 1.3 1.2 > 1.6 0.1 > 5. ip65-47-181-105.z181-47-65.c 0.0% 10 1.4 2.0 1.3 > 3.7 0.8 > 6. ge11-1-4d0.mcr2.chicago-il.u 0.0% 10 2.1 1.7 1.4 > 2.1 0.3 > 7. ae1d0.mcr1.chicago-il.us.xo. 0.0% 10 2.7 11.8 1.8 > 34.9 13.4 > 8. 216.156.0.161.ptr.us.xo.net 0.0% 10 62.2 62.3 62.0 > 62.8 0.3 > 9. te-3-2-0.rar3.dallas-tx.us.x 0.0% 10 61.1 61.8 61.0 > 64.2 1.0 > 10. 207.88.12.46.ptr.us.xo.net 0.0% 10 61.6 61.6 60.7 > 63.8 1.1 > 11. 207.88.12.158.ptr.us.xo.net 0.0% 10 60.7 61.0 60.7 > 61.7 0.4 > 12. lax-px1--xo-ge.cenic.net 0.0% 10 60.5 60.8 60.4 > 61.4 0.4 > 13. dc-lax-core1--lax-peer1-ge.c 0.0% 10 61.5 61.5 61.1 > 62.1 0.4 > 14. dc-lax-agg1--lax-core1-ge.ce 0.0% 10 61.1 61.6 60.8 > 63.5 0.9 > 15. dc-ucla--lax-agg1-ge-2.cenic 0.0% 10 62.0 62.6 61.7 > 65.1 1.3 > 16. border-2--core-1-ge.backbone 0.0% 10 62.4 62.4 61.8 > 63.4 0.5 > 17. core-1--mathsci-10ge.backbon 0.0% 10 61.9 61.7 61.4 > 62.1 0.2 > 18. ??? 100.0 10 0.0 0.0 0.0 > 0.0 0.0 > From owen at delong.com Tue Dec 15 18:56:08 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Dec 2009 10:56:08 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20091215124954.GA22285@maya.aronius.com> References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> <4B2714F8.4050701@bogus.com> <2BDE5380-B69F-4068-AF7B-40E0724C9C91@cs.columbia.edu> <20091215124954.GA22285@maya.aronius.com> Message-ID: <139DC638-1F85-4A15-9218-34980F51BFA7@delong.com> On Dec 15, 2009, at 4:49 AM, Joakim Aronius wrote: > * Steven Bellovin (smb at cs.columbia.edu) wrote: >> >> On Dec 14, 2009, at 11:47 PM, Joel Jaeggli wrote: >>> Owen DeLong wrote: >>> Stable outgoing connections for p2p apps, messaging, gaming >>> platforms >>> and foo website with java script based rpc mechanisms have similar >>> properties. I don't sleep soundly at night becasuse the $49 buffalo >>> router I bought off an endcap at frys uses iptables, I sleep soundly >>> because I don't care. >>> >> Precisely. And if you want to get picky, remember that >> "availability" is part >> of the standard definition of security. A firewall that doesn't >> let me play >> Chocolate-Sucking Zombie Monsters is an attack on the availability >> of that >> gmae, albeit from the purest of motives. >> >> No, I'm not saying that this is good. I am saying that in the real >> world, it >> *will* happen. > > So what you are saying is that ease of use and service availability > is priority one. Then what exactly are the responsibilities of the > ISP and CPE manufacturer when it comes to security? CPEs with WiFi > usually comes with the advice to change password etc. Is it ok to > build an infrastructure relying on UPnP, write a disclaimer, and let > the end user handle eventual problems? (I assume it is...) > > /jkm Personally, I think that CPE should come up relatively braindead except on the interior wired ethernet interfaces and require creating an SSID and suggesting creating a password (regardless of whether TKIM, WEP, WPA, etc, at least something) before enabling any wireless. It should require the user to create their own administrative password before being able to enable any other features on the box. If CPE manufacturers did this, it would remove a great many vulnerabilities in the world without making it particularly harder for the average end-user. Owen From dot at dotat.at Tue Dec 15 19:09:29 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 15 Dec 2009 19:09:29 +0000 Subject: DNS question, null MX records In-Reply-To: <827hsonth4.fsf@mid.bfk.de> References: <827hsonth4.fsf@mid.bfk.de> Message-ID: On Tue, 15 Dec 2009, Florian Weimer wrote: > * Eric J. Esslinger: > > > I found a reference to a null MX proposal, constructed so: > > example.com IN MX 0 . > > I think this is quite controversal. My impression from discussions on various IETF lists is that most people think it is a good idea, it is already reasonably widely implemented, but no-one has the time and persistence to push a spec through to publication. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From dts at senie.com Tue Dec 15 19:19:28 2009 From: dts at senie.com (Daniel Senie) Date: Tue, 15 Dec 2009 14:19:28 -0500 Subject: DNS question, null MX records In-Reply-To: References: <827hsonth4.fsf@mid.bfk.de> Message-ID: I disagree. There was considerable concern with a misuse of a mechanism and its effect on various systems. That, from discussion on the IETF mailing list I was on when it was discussed there. There was no rough consensus that I could see. On Dec 15, 2009, at 2:09 PM, Tony Finch wrote: > On Tue, 15 Dec 2009, Florian Weimer wrote: >> * Eric J. Esslinger: >> >>> I found a reference to a null MX proposal, constructed so: >>> example.com IN MX 0 . >> >> I think this is quite controversal. > > My impression from discussions on various IETF lists is that most people > think it is a good idea, it is already reasonably widely implemented, but > no-one has the time and persistence to push a spec through to publication. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. From bpasdar at batblue.com Tue Dec 15 20:29:27 2009 From: bpasdar at batblue.com (Babak Pasdar) Date: Tue, 15 Dec 2009 15:29:27 -0500 Subject: Cogent $1500 GigE Message-ID: <20091215202927.b6145232@concur.batblue.com> Dear List, I am getting a big push from Cogent on their full GigE for $1.50 per circuit. What are your experiences with Cogent in general? If on the fence, how would you use their service for this deal to make sense? Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden & Risk - Video | Article From sethm at rollernet.us Tue Dec 15 20:53:02 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 15 Dec 2009 12:53:02 -0800 Subject: Cogent $1500 GigE In-Reply-To: <20091215202927.b6145232@concur.batblue.com> References: <20091215202927.b6145232@concur.batblue.com> Message-ID: <4B27F72E.1000304@rollernet.us> Babak Pasdar wrote: > Dear List, > > I am getting a big push from Cogent on their full GigE for $1.50 per circuit. What are your experiences with Cogent in general? If on the fence, how would you use their service for this deal to make sense? > $1.50 per meg. ;) I'd probably take it just because I could at that price. The downsides with Cogent is that they occasionally get into peering spats that might hurt you if you aren't multihomed, and no usable IPv6 (if that matters to you). I hadn't looked into it any further because I'm not located anywhere Cogent is to give it a serious look. ~Seth From patrick at ianai.net Tue Dec 15 20:59:39 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 15 Dec 2009 15:59:39 -0500 Subject: Cogent $1500 GigE In-Reply-To: <4B27F72E.1000304@rollernet.us> References: <20091215202927.b6145232@concur.batblue.com> <4B27F72E.1000304@rollernet.us> Message-ID: On Dec 15, 2009, at 3:53 PM, Seth Mattinen wrote: > Babak Pasdar wrote: >> Dear List, >> I am getting a big push from Cogent on their full GigE for $1.50 per circuit. What are your experiences with Cogent in general? If on the fence, how would you use their service for this deal to make sense? > > $1.50 per meg. ;) I'd probably take it just because I could at that price. The downsides with Cogent is that they occasionally get into peering spats that might hurt you if you aren't multihomed, and no usable IPv6 (if that matters to you). I hadn't looked into it any further because I'm not located anywhere Cogent is to give it a serious look. I'm pretty sure the system at $DAY_JOB is better at pushing bits near, but not quite over, the hard limit of a link than any other out there. And I am dead certain I could not get 1000 Mbps out of a GigE without serious packet loss. Even assuming 900 Mbps (good luck), you're at $1.66/Mbps. Most people do 50%, so that would be $3/Mbps. Still probably a good price for 500 Mbps. But how much OpEx do you have to spend to ensure that link stays below 1 Gbps 24/7/365? And if you only have 100 Mbps, though, it doesn't look so good. -- TTFN, patrick From mlarson at verisign.com Tue Dec 15 22:49:49 2009 From: mlarson at verisign.com (Matt Larson) Date: Tue, 15 Dec 2009 17:49:49 -0500 Subject: Root zone DNSSEC deployment web site and technical status update Message-ID: <20091215224949.GZ13415@dul1mcmlarson-l1.vcorp.ad.vrsn.com> The root zone DNSSEC deployment team is pleased to announce a new web site with information about the project, http://www.root-dnssec.org. The site serves as a repository for documentation and information about deploying DNSSEC in the root zone, including technical status updates. The first status update is available on the site and is included below, as well. Additional documentation will be posted as it becomes available. Important announcements and future status updates will appear in the site's RSS feed, http://www.root-dnssec.org/rss. The design team welcomes your feedback: you can reach the entire team at rootsign at icann.org. On behalf of the root zone DNSSEC deployment team, Matt Larson -- Status Update, December, 2009 This is the first of a series of technical status updates intended to inform a technical audience on the progress of deploying DNSSEC in the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. DOCUMENTATION This project involves the creation of a large volume of documentation, individual components of which will be released as they have completed internal review. The following documents are expected to be released as drafts before the end of December 2009: * Root Zone DNSSEC Deployment Plan * Root Zone Trust Anchor Publication DEPLOYMENT STATUS Several root server operators have started testing a lightweight packet capture tool designed to provide a full record of priming queries received over the period covering DNSSEC deployment in the root zone. We hope this data collection will be in full production on all root servers before the end of December, providing baseline data which will allow the reaction of the system as a whole to deployment events to be observed. On 2009-12-01, the first pre-production KSR exchange between ICANN and VeriSign and the signing of the root zone within VeriSign's production infrastructure commenced. The signing, validation, measurement and monitoring infrastructure will now be subject to full internal testing. PLANNED DEPLOYMENT SCHEDULE 2009-12-01: KSR exchange, root zone signing begins, internal to VeriSign and ICANN; generation of DURZ Week of 2010-01-11: L starts to serve DURZ Week of 2010-02-08: A starts to serve DURZ Week of 2010-03-01: M, I start to serve DURZ Week of 2010-03-22: D, K, E start to serve DURZ Week of 2010-04-12: B, H, C, G, F start to serve DURZ Week of 2010-05-03: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor. (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) From leen at consolejunkie.net Tue Dec 15 22:56:19 2009 From: leen at consolejunkie.net (leen at consolejunkie.net) Date: Tue, 15 Dec 2009 23:56:19 +0100 Subject: Cogent $1500 GigE In-Reply-To: <4B27F72E.1000304@rollernet.us> References: <20091215202927.b6145232@concur.batblue.com> <4B27F72E.1000304@rollernet.us> Message-ID: <4B281413.3020700@consolejunkie.net> On 12/15/2009 09:53 PM, Seth Mattinen wrote: > Babak Pasdar wrote: >> Dear List, >> >> I am getting a big push from Cogent on their full GigE for $1.50 per >> circuit. What are your experiences with Cogent in general? If on >> the fence, how would you use their service for this deal to make sense? >> > > $1.50 per meg. ;) I'd probably take it just because I could at that > price. The downsides with Cogent is that they occasionally get into > peering spats that might hurt you if you aren't multihomed, and no > usable IPv6 (if that matters to you). I hadn't looked into it any > further because I'm not located anywhere Cogent is to give it a > serious look. > > ~Seth > > Hi Seth/List, Maybe I'm to harsh, but I just don't think of them as a full-transit. That makes it a lot easier to make a decision about adding them. We need atleast 2 full-transits and then possible add them to get the price down on a good part of the traffic. On the IPv6-side they have IPv6 in Amsterdam (where we are fairly close), but they don't even have full-transit in the 'normal' situation (think: HE). We do have peering with HE, so that's atleast something. But I don't yet know what else they are missing. That's how I see them. Have a nice day. From scott at likens.us Tue Dec 15 23:47:57 2009 From: scott at likens.us (Scott M. Likens) Date: Tue, 15 Dec 2009 15:47:57 -0800 Subject: Need to contact someone with Verisign Message-ID: Hi, Long story short I am a customer of 1and1.com for the domain adappsolutions.com, we moved our datacenter roughly 60-days ago and updated our records with 1and1. However it is now December 15th and when I go here, http://registrar.verisign-grs.com/cgi-bin/whois?whois_nic=ns2.adappsolutions.com&x=0&y=0&type=nameserver I see it pointing to the incorrect address, as well as ns1.adappsolutions.com I have updated all the records I can find on 1and1.com and still there does not seem to be a way for this update to occur? So if someone can contact me off list, so I can get this addressed ASAP that would be wonderful. Thanks, Sincerely, Scott M. Likens From simon at darkmere.gen.nz Wed Dec 16 01:14:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Wed, 16 Dec 2009 14:14:01 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From dotis at mail-abuse.org Wed Dec 16 02:18:30 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 15 Dec 2009 18:18:30 -0800 Subject: DNS question, null MX records In-Reply-To: <4B27B3F7.7060007@nosignal.org> References: <4B27B3F7.7060007@nosignal.org> Message-ID: <4B284376.3000800@mail-abuse.org> On 12/15/09 8:06 AM, Andy Davidson wrote: > Eric J Esslinger wrote: >> I have a domain that exists solely to cname A records to another domain's websites. > [...] >> I found a reference to a null MX proposal, constructed so: >> example.com IN MX 0 . > [...] >> Question: Is this a valid dns construct or did the proposal die? > > It's "valid", but you will probably find people still try to spam to > machines on the A records, and all of the other weird and wonderful things > that spambots try to do to find a path that will deliver mail... SRV records documented the hostname "." as representing "no service". However, errors made by non-RFC-compliant clients still generate a fair amount of root traffic attempting to resolve A records for ".". The MX record never defined a hostname "." to mean "no service" so it would be unwise to expect email clients will interpret this as a special case meaning "no service" as well. One might instead consider using: example.com. IN MX 0 192.0.2.0 IN MX 10 192.0.2.1 ... IN MX 90 192.0.2.9 where 192.0.2.0/24 represents a TEST-NET block. This should ensure traffic will not hit the roots or your servers. Assuming a sender tries all of MX addresses listed, they may still attempt to resolve A records for example.com. This MX approach will affect those failing to validate email prior to acceptance, and, of course, spammers. -Doug From scott at likens.us Wed Dec 16 02:49:04 2009 From: scott at likens.us (Scott M. Likens) Date: Tue, 15 Dec 2009 18:49:04 -0800 Subject: Need to contact someone with Verisign In-Reply-To: References: Message-ID: <566EB861-BCBC-4CED-9410-D40475BE4DA4@likens.us> Hi, Thank you for everyone who responded, I have contacted someone and hope to have it resolved. Thanks again, Scott M. Likens From marka at isc.org Wed Dec 16 02:58:56 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 16 Dec 2009 13:58:56 +1100 Subject: DNS question, null MX records In-Reply-To: Your message of "Tue, 15 Dec 2009 18:18:30 -0800." <4B284376.3000800@mail-abuse.org> References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> Message-ID: <200912160258.nBG2wuPa051641@drugs.dv.isc.org> In message <4B284376.3000800 at mail-abuse.org>, Douglas Otis writes: > On 12/15/09 8:06 AM, Andy Davidson wrote: > > Eric J Esslinger wrote: > >> I have a domain that exists solely to cname A records to another domain's > websites. > > [...] > >> I found a reference to a null MX proposal, constructed so: > >> example.com IN MX 0 . > > [...] > >> Question: Is this a valid dns construct or did the proposal die? > > > > It's "valid", but you will probably find people still try to spam to > > machines on the A records, and all of the other weird and wonderful things > > that spambots try to do to find a path that will deliver mail... > > SRV records documented the hostname "." as representing "no service". > However, errors made by non-RFC-compliant clients still generate a fair > amount of root traffic attempting to resolve A records for ".". The MX > record never defined a hostname "." to mean "no service" so it would be > unwise to expect email clients will interpret this as a special case > meaning "no service" as well. One might instead consider using: > > example.com. IN MX 0 192.0.2.0 > IN MX 10 192.0.2.1 > ... > IN MX 90 192.0.2.9 Which will expand to: example.com. IN MX 0 192.0.2.0.example.com. IN MX 10 192.0.2.1.example.com. .... IN MX 90 192.0.2.9.example.com. MX records DO NOT take IP addresses. > where 192.0.2.0/24 represents a TEST-NET block. > > This should ensure traffic will not hit the roots or your servers. > Assuming a sender tries all of MX addresses listed, they may still > attempt to resolve A records for example.com. This MX approach will > affect those failing to validate email prior to acceptance, and, of > course, spammers. > > -Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From vandry at TZoNE.ORG Wed Dec 16 03:14:10 2009 From: vandry at TZoNE.ORG (Phil Vandry) Date: Tue, 15 Dec 2009 22:14:10 -0500 Subject: DNS question, null MX records *summary of on list and off list replies* In-Reply-To: References: Message-ID: <20091215221410.cdaa1c72.vandry@TZoNE.ORG> On Tue, 15 Dec 2009 11:51:29 -0600, Eric J Esslinger wrote: > B. Set spf -all, for those who bother to check that to stop inbound > mail from your domain. You might as well also add a DKIM ADSP policy with "dkim=discardable". Similar to your SPF policy, it announces that no unsigned mail (or no mail at all in your case) should come from this domain. But DKIM does not suffer from the problems SPF causes with email forwarding (see recent NANOG thread on that topic). -Phil From rsk at gsp.org Wed Dec 16 03:33:11 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 15 Dec 2009 22:33:11 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: References: Message-ID: <20091216033311.GA24725@gsp.org> [ Note: you're not talking about the RBL. You're talking about a DNSBL or RHSBL, which are generic terms. The RBL is a specific DNSBL and, as far as I know, does not have a listing policy related to this discussion. ] On Wed, Dec 09, 2009 at 03:18:47PM +0000, Sven Olaf Kamphuis wrote: > because they just assume that working, rfc compliant, reverse dns that > just-so-happens to be automatically generated would indicate dynamic ip > space.. It has long since become a best practice in mail server operations to pre-emptively blacklist all such space on sight. This is common knowledge among everyone who's kept pace with the field, and is an entirely appropriate reaction to what's sometimes called "the rise of the zombies". Real mail servers have non-generic, matching forward and reverse DNS with real hostnames. The farther hostnames move from that, the more problems can be expected. Nobody particularly likes this, as the work necessary in compiling such lists is onerous. But it is one of the most effective (in terms of FP and FN rates as well as resource costs) anti-spam measures available. ---Rsk From lists at memetic.org Wed Dec 16 05:30:55 2009 From: lists at memetic.org (Adam Armstrong) Date: Wed, 16 Dec 2009 05:30:55 +0000 Subject: Arrogant RBL list maintainers In-Reply-To: References: Message-ID: <4B28708F.40709@memetic.org> On 09/12/2009 15:18, Sven Olaf Kamphuis wrote: >> a84-22-xx-xx.cb3rob.net. as it's RFC complient and we cannot be fucked to >> haha. and what precisely did you expect? that's not really what most people would consider valid reverse dns for a mail relay. (operational practice often beats RFC where they exist, and more often than not fills in where they don't). personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. (i also notice that in later replies you claim that they're breaking eu data laws, but you seem to have bleeted on enough about how you think data is something that should be in the public domain, so you can download movies, err i mean, be like totally free man.) adama. From mysidia at gmail.com Wed Dec 16 06:12:22 2009 From: mysidia at gmail.com (James Hess) Date: Wed, 16 Dec 2009 00:12:22 -0600 Subject: Arrogant RBL list maintainers In-Reply-To: <4B28708F.40709@memetic.org> References: <4B28708F.40709@memetic.org> Message-ID: <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong wrote: > personally, i'd recommend not being a dick and setting valid *meaningful* > reverse dns for things relaying mail. Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears "generic" or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only. Some sites might want to avoid certain "meaningful" RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. All reverse DNS information is in the hands of the enemy. For example, when spammers' IP scanning efforts find that an IP address reverses to "mail.example.com" the spammer will know to try @example.com e-mail addresses for their dictionary-based brute-force spamming. On the other hand, if the MTA's IP reverses to something like a152.x.example.net. As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is @example.com inbound (or outbound) mail. Since the RDNS domain is different, and in fact generic, which helps avoid assisting the spammer in identifying the IP as an inbound mail server. -- -J From ops.lists at gmail.com Wed Dec 16 07:30:42 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 16 Dec 2009 13:00:42 +0530 Subject: Arrogant RBL list maintainers In-Reply-To: <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> Message-ID: Security by obscurity, in this day and age? :) On Wed, Dec 16, 2009 at 11:42 AM, James Hess wrote: > As is common for many domains. > Spammers coming in ?by ?scanning ?large ranges of IPs, ?have no > pointer to report ?the ?mailserver they discovered ?is ?@example.com > ?inbound ?(or outbound) mail. > > Since the RDNS domain is different, and in fact generic, ?which ?helps > avoid ?assisting the spammer ?in identifying the IP as an ?inbound > mail server. -- Suresh Ramasubramanian (ops.lists at gmail.com) From jabley at hopcount.ca Wed Dec 16 11:17:43 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 16 Dec 2009 11:17:43 +0000 Subject: DNS question, null MX records In-Reply-To: <4B27AF05.9070001@gmail.com> References: <4B27AF05.9070001@gmail.com> Message-ID: On 2009-12-15, at 15:45, Dave Sparro wrote: > On 12/15/2009 10:17 AM, Eric J Esslinger wrote: >> I found a reference to a null MX proposal, constructed so: >> example.com IN MX 0 . >> >> Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. >> > > Pulling from my often mangled memory: > > This was proposed in a draft RFC that went nowhere. http://tools.ietf.org/html/draft-jabley-sink-arpa-01 One of the imagined purposes of this draft is to be able to write example.com. IN MX 0 SINK.ARPA. and be confident that SINK.ARPA does not exist. Joe From jabley at hopcount.ca Wed Dec 16 11:20:14 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 16 Dec 2009 11:20:14 +0000 Subject: DNS question, null MX records In-Reply-To: References: <827hsonth4.fsf@mid.bfk.de> Message-ID: <167CAB40-71D7-4BF9-988A-1A188B433C37@hopcount.ca> On 2009-12-15, at 19:09, Tony Finch wrote: > On Tue, 15 Dec 2009, Florian Weimer wrote: >> * Eric J. Esslinger: >> >>> I found a reference to a null MX proposal, constructed so: >>> example.com IN MX 0 . >> >> I think this is quite controversal. > > My impression from discussions on various IETF lists is that most people > think it is a good idea, it is already reasonably widely implemented, but > no-one has the time and persistence to push a spec through to publication. When I attempted to document a similar idea (using an empty label in the MNAME field of an SOA record in order to avoid unwanted DNS UPDATE traffic) the consensus of the room was that the idea was both controversial and bad :-) http://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00 Joe From lists at memetic.org Wed Dec 16 11:49:27 2009 From: lists at memetic.org (Adam Armstrong) Date: Wed, 16 Dec 2009 11:49:27 +0000 Subject: Arrogant RBL list maintainers In-Reply-To: <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> Message-ID: <4B28C947.6060804@memetic.org> On 16/12/2009 06:12, James Hess wrote: > On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong wrote: > >> personally, i'd recommend not being a dick and setting valid *meaningful* >> reverse dns for things relaying mail. >> > Many sites don't use names that will necessarily be meaningful to an outsider. > Sometimes the non-meaningful name is the actual hostname and the > _only_ name that machine is known by, even if the name appears > "generic" or contains an IP. Host naming is a matter of local > network policy, and the RFCs that pertain to hostnames specify syntax > requirements only. > > Some sites might want to avoid certain "meaningful" RDNS entries > since spammers, hackers, and other abusive users that scan IP ranges > can utilize the RDNS to facilitate their activities. All > reverse DNS information is in the hands of the enemy. > > For example, when spammers' IP scanning efforts find that an IP > address reverses to "mail.example.com" the spammer will know > to try @example.com e-mail addresses for their dictionary-based > brute-force spamming. > > On the other hand, if the MTA's IP reverses to something like > a152.x.example.net. > > As is common for many domains. > Spammers coming in by scanning large ranges of IPs, have no > pointer to report the mailserver they discovered is @example.com > inbound (or outbound) mail. > The 1970s called and asked for its security policy back :( I would have thought that asking for the MXes for example.com would have told them what the inbound mailserver is... adam. From dot at dotat.at Wed Dec 16 11:59:18 2009 From: dot at dotat.at (Tony Finch) Date: Wed, 16 Dec 2009 11:59:18 +0000 Subject: DNS question, null MX records In-Reply-To: <200912160258.nBG2wuPa051641@drugs.dv.isc.org> References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> Message-ID: On Wed, 16 Dec 2009, Mark Andrews wrote: > Douglas Otis wrote: > > > > One might instead consider using: > > > > example.com. IN MX 0 192.0.2.0 > > IN MX 10 192.0.2.1 > > ... > > IN MX 90 192.0.2.9 > > Which will expand to: > > example.com. IN MX 0 192.0.2.0.example.com. > IN MX 10 192.0.2.1.example.com. > .... > IN MX 90 192.0.2.9.example.com. > > MX records DO NOT take IP addresses. Or if he puts in the trailing dot it'll still cause the root server traffic he was trying to avoid. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From mikelieman at gmail.com Wed Dec 16 12:06:55 2009 From: mikelieman at gmail.com (Mike Lieman) Date: Wed, 16 Dec 2009 07:06:55 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B28C947.6060804@memetic.org> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> Message-ID: <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> Wouldn't SPF ( RFC 4408) tell people more about where the real mailservers are than some half-baked idea of trying to enforce what hostnames should look like? What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here? On Wed, Dec 16, 2009 at 6:49 AM, Adam Armstrong wrote: > On 16/12/2009 06:12, James Hess wrote: > >> On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong >> wrote: >> >> >>> personally, i'd recommend not being a dick and setting valid *meaningful* >>> reverse dns for things relaying mail. >>> >>> >> Many sites don't use names that will necessarily be meaningful to an >> outsider. >> Sometimes the non-meaningful name is the actual hostname and the >> _only_ name that machine is known by, even if the name appears >> "generic" or contains an IP. Host naming is a matter of local >> network policy, and the RFCs that pertain to hostnames specify syntax >> requirements only. >> >> Some sites might want to avoid certain "meaningful" RDNS entries >> since spammers, hackers, and other abusive users that scan IP ranges >> can utilize the RDNS to facilitate their activities. All >> reverse DNS information is in the hands of the enemy. >> >> For example, when spammers' IP scanning efforts find that an IP >> address reverses to "mail.example.com" the spammer will know >> to try @example.com e-mail addresses for their dictionary-based >> brute-force spamming. >> >> On the other hand, if the MTA's IP reverses to something like >> a152.x.example.net. >> >> As is common for many domains. >> Spammers coming in by scanning large ranges of IPs, have no >> pointer to report the mailserver they discovered is @example.com >> inbound (or outbound) mail. >> >> > > The 1970s called and asked for its security policy back :( > > I would have thought that asking for the MXes for example.com would have > told them what the inbound mailserver is... > > adam. > > > > From rsk at gsp.org Wed Dec 16 12:15:46 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 16 Dec 2009 07:15:46 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> Message-ID: <20091216121546.GA29869@gsp.org> On Wed, Dec 16, 2009 at 12:12:22AM -0600, James Hess wrote: > Many sites don't use names that will necessarily be meaningful to an outsider. Then they should expect issues with mail acceptance by outsiders. > Some sites might want to avoid certain "meaningful" RDNS entries > since spammers, hackers, and other abusive users that scan IP ranges > can utilize the RDNS to facilitate their activities. This is nonsense. RDNS/DNS naming choices are a trivial obstacle to spammers et.al. who went over this speed bump at 70 MPH years ago and have been accelerating ever since. This kind of security-by-obscurity tactic is far more likely to draw their attention than evade it, as any site using it has in effect run up a large flag with "we don't understand security basics" written on it and thus made itself an attractive target. ---Rsk From adimino at shadowserver.org Wed Dec 16 13:14:49 2009 From: adimino at shadowserver.org (Andre M. DiMino) Date: Wed, 16 Dec 2009 08:14:49 -0500 Subject: Conficker may be forgotten, but it's not gone.. Message-ID: <4B28DD49.9050307@shadowserver.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shadowserver is happy to announce a new set of statistics and charts highlighting the widespread infection & propagation of Conficker. We thought it would be of interest to illustrate the depth and extent of how Conficker truly affects a worldwide scope of providers. While much public attention has faded since the widely publicized April 1st 2009 "attack date", it's quite evident that Conficker still maintains a huge foothold on many computer systems worldwide. Hopefully this report will again raise public awareness to a 6.5M node botnet and drive remediation efforts from the providers themselves, as well as the average computer user. Shadowserver hopes you find these stats and charts as interesting as we have. This is a dynamic page, so you can watch trends and remediation efforts over time. As always, we're interested in how folks use and benefit from our data and reports. Feel free to drop us a note anytime and give us your feedback. Shadowserver has posted a new blog about this at: http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20091216 The Conficker stats and charts page can be found here: http://www.shadowserver.org/wiki/pmwiki.php/Stats/Conficker - -- Andre' M. Di Mino - SemperSecurus The Shadowserver Foundation http://www.shadowserver.org Skype: sempersecurus AIM: sempersecurus "Make sure that nobody pays back wrong for wrong, but always try to be kind to each other and to everyone else." 1 Thessalonians 5:15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkso3UkACgkQPJaIJoADD66V0gCbBeCQJnf8byeBdyw89aNW/EJR DuYAoL+UNIkwnCTprSqS1D4NtCM2NllS =frkR -----END PGP SIGNATURE----- From herrin-nanog at dirtside.com Wed Dec 16 13:16:23 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 16 Dec 2009 08:16:23 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> Message-ID: <3c3e3fca0912160516j2f48f59fve4a386399d5a9aae@mail.gmail.com> On Wed, Dec 16, 2009 at 7:06 AM, Mike Lieman wrote: > Wouldn't SPF ( RFC 4408) tell people more about where the real mailservers > are than some half-baked idea of trying to enforce what hostnames should > look like? > > What's the word for 'mail server' in Lower Sorbian, and does your algorithm > properly detect it in a hostname? ?See the problem here? Mike, If you really want to know, download the spamassassin code and start reading. You'll find both the answers to how names are checked and rankings of empirical effectiveness. On Wed, Dec 16, 2009 at 7:15 AM, Rich Kulawiec wrote: > This is nonsense. RDNS/DNS naming choices are a trivial obstacle to > spammers et.al. who went over this speed bump at 70 MPH years ago and > have been accelerating ever since. This kind of security-by-obscurity > tactic is far more likely to draw their attention than evade it, as any > site using it has in effect run up a large flag with "we don't understand > security basics" written on it and thus made itself an attractive target. Rich, This depends on the spammer and his methodology. A significant fraction of spam, perhaps the majority, originates from hijacked user PCs. For this subset of spam sources, adjusting the RNDS is an insurmountable obstacle. There's no magic bullet for stopping spam but there are a lot of heuristics which eliminate a useful fraction. Using the RDNS to make an educated guess about whether a particular machine's owners intend it to operate as a mail server is such a heuristic. If you must whine about antispam techniques, whine about something important. Filtering by IP address in a bazillion private block and permit lists makes it very hard for large legitimate mailing list operators to renumber when changing ISPs. The new IP address isn't on any of the permit lists yet and it may be on block lists as a result if its prior user. This pushes list operators towards PI, BGP and consuming expensive real estate in your routers for a protocol which is otherwise relatively trivial to renumber. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Wed Dec 16 13:21:16 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 16 Dec 2009 08:21:16 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: Your message of "Wed, 16 Dec 2009 07:06:55 EST." <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> Message-ID: <813.1260969676@localhost> On Wed, 16 Dec 2009 07:06:55 EST, Mike Lieman said: > What's the word for 'mail server' in Lower Sorbian, and does your algorithm > properly detect it in a hostname? See the problem here? When the hostname at that IP address is exactly one incremented character different than the preceding address, and one decremented character different than the following address, and that pattern holds across a /24, they're probably not mail servers. Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' servers in the same /24 for *anything* user-facing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Wed Dec 16 15:32:37 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 16 Dec 2009 09:32:37 -0600 Subject: Arrogant RBL list maintainers In-Reply-To: <813.1260969676@localhost> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> <813.1260969676@localhost> Message-ID: <4B28FD95.9090602@brightok.net> Valdis.Kletnieks at vt.edu wrote: > When the hostname at that IP address is exactly one incremented character > different than the preceding address, and one decremented character different > than the following address, and that pattern holds across a /24, they're > probably not mail servers. Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' > servers in the same /24 for *anything* user-facing. Mental note, don't setup 253 generic servers in the same /24 for dynamic allocation and usage by the load balancers and proxy servers. Check. Jack From sean at donelan.com Wed Dec 16 15:55:16 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 16 Dec 2009 10:55:16 -0500 (EST) Subject: Arrogant RBL list maintainers In-Reply-To: <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> Message-ID: <200912161043060.6B95064B.27750@clifden.donelan.com> On Wed, 16 Dec 2009, James Hess wrote: > On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong wrote: >> personally, i'd recommend not being a dick and setting valid *meaningful* >> reverse dns for things relaying mail. > > Many sites don't use names that will necessarily be meaningful to an outsider. > Sometimes the non-meaningful name is the actual hostname and the > _only_ name that machine is known by, even if the name appears > "generic" or contains an IP. Host naming is a matter of local > network policy, and the RFCs that pertain to hostnames specify syntax > requirements only. You can implement your local network policies to use mail server hostnames which match "generic" looking strings, and other operators can implemenent their local network policies to refuse mail from hosts which match "generic" looking hostname strings. In the battle of local network policies, you will always lose because there are always more other networks. If you want to interoperate with other operator's networks, you will probably need to follow more than just your local network policies. Folks have said what the problem is, and how to fix it. If the original poster wants to stand on principles, he will continue to have problems getting other networks to accept connections from his mail servers. On the other hand, if he wants to fix this mail acceptance problem, he now knows what he needs to do. The great thing about RFCs is anyone can write one. The bad thing about RFCs is anyone can write one. From matthew at sorbs.net Wed Dec 16 16:40:31 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Wed, 16 Dec 2009 17:40:31 +0100 Subject: Arrogant RBL list maintainers In-Reply-To: <2f1d68350912100559h200c0447s14640f90604d421f@mail.gmail.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> <2f1d68350912100559h200c0447s14640f90604d421f@mail.gmail.com> Message-ID: <4B290D7F.5090008@sorbs.net> Ronald Cotoni wrote: > Very true. At my old place of employment a DUHL listed an ip since > before my previous company existed. For some reason, when we obtained > it, they still listed it. Sounds like a bug in the DUHL bot to me. > Also the standard makes a lot of sense. You may be on Trend Micros > DUHL by following the rules on SORBS DUHL and vica versa. Makes life > a pain. > > If you set non generic rDNS or generic following their suggestions you'd be removed from the SORBS DUHL pretty much automagically (a request initiates the rescan) - there is manual stuff on my behalf but nothing for a requestor to worry about. The only reason you wouldn't be is if you had a listing and too short a TTL for the robot to accept the delisting request... A reply would result in a human (usually me) processing netblocks of /24 or greater (greater as in number of IPs) providing the TTLs were not shorter than 1 hour. That is well documented in many places. Seems according to their rules if you follow the SORBS DUHL rules you'll also be delisted from them. To add my $0.02 I agree with many of the replies... If you have one generic pattern for a /16 you either: Don't care to setup DNS. Don't know how to setup DNS. Don't care what's in the netblock. Don't have the competency to run a network/mailserver/dnsserver/. In all the cases above I would not want your mail as it is 99.999% likely to be abusive in nature (spam, viruses etc.) Oh and many know I don't care if you are Peer1, Level 3 or Joe Blows Backyard VISP in outback Australia, you're all the same to me, you should all have competent people on staff, the only thing that changes between you is the number of *your* customers, and the amount you charge. Similar issues apply when looking at *.edu's vs *.com's, *.au's, and *.mt's. Just because you come from a certain country or certain type of establishment, doesn't make you different, it's only the number of people you service, you should still have competent staff. If you don't have enough staff that's not my problem (nor the rest of the world's) though it usually results in our problem when abuse starts flowing. I know most here are the admins and staff, so sorry if it sounds like I'm having a go at you guys, but really most on this list are the competent admins, a minority being people learning (nothing wrong with that!) but unfortunately there are some who are not and they don't care that they are not. I know that makes me an arrogant w***er, or another one of those "Arrogant RBL list maintainers" but think about it, and think about the following... Would you like to be prioritised down the queue because someone else was supposedly more important? ..... What happens to the poor mum and dad VISP in Somalia that never gets delisted because Telstra is logging 100's of tickets every day because their super size and constant rotating listings? ..... What happens if Telstra have a single IP blocked and Sprint come along and request delisting for a spamming customer's netspace they once hosted? Should we (RBL Maintainers, SORBS or anyone else) push the largest ISP in Australia out of the way for the bigger USA based Sprint? If not should we push the mum and dad operation out of the way for Telstra? ..... The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... ..... my answer to the question above is a very obvious take every issue in order, and if you get a super high priority issue, deal with it if necessary, but size of the ISP (or size of the admin's d***) is _not_ the prioritising factor. Note: Names chosen and mentioned above have no baring on any current abuse level or any logged issue, they are for example only. I don't want answers to the questions, I know some will post to the list or me regardless... it's stuff for *you* to think about when dealing with organisations such as RBLs.. especially when they are volunteer run. A little example about "arrogance" when it comes to ISPs... I know at least one member of this list (an ISP) has posted to every address in GFI in the last few days that they could think of (including the CEOs email) because their spamming netblocks have not been delisted. They have previously stated they would not deal with SORBS, so what changed, well as they found out in an email, nothing, they still need to log a support ticket, and their out of band request just pushed them down the queue. Sad thing based on their ticket ID, had they waited another 2 hours they would have been answered, now they have 112 manual processing tickets before theirs. I'm sure they'll guess who they are, I'd advise them to be patient or they might push themselves down further. ... and then of course there are some RBL Maintainers (and RBLs) that are arrogant, maybe it comes with the territory... Lastly.... No I don't take tickets to here, or my personal email addresses. Those that have already mailed me, following my last post to NANOG, you've been ignored as per my previous post. If you have a problem with a robot response, read the response! Most of the time it will tell you to respond to it for a human review! We will always answer you, however how soon depends on how busy we are. Messaging everyone/anyone in GFI *will* delay any ticket you may have, because the time it wastes will result in your ticket being placed at the back of the queue *without review*. If there is a problem with the support system in itself feel free to message me, but as I indicated before I have various sensors to tell me there is an issue mostly before you'd even notice (examples: the robot occasionally locks up so tickets to the DUHL will not get any auto reply of any kind after a few hours... the sensor for this triggers after 20 hours so, mailing me after 6 hours will speed things up however,,, support website down? I'll be paged within 5 minutes, which means unless it crashed just before you tried to access it, I'll likely already be logging in by the time you have started your email client.) Michelle From matthew at sorbs.net Wed Dec 16 17:01:51 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Wed, 16 Dec 2009 18:01:51 +0100 Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> Message-ID: <4B29127F.1010802@sorbs.net> Mikael Abrahamsson wrote: > On Wed, 9 Dec 2009, Frank Bulk wrote: > >> Two sides of an SP's coin: I want to maximize my e-mail servers' >> deliverability, so I make sure those have appropriately named PTRs >> and make >> sure that outbound messages aren't spammy; I also want to restrict > > The point he was trying to make is that there is no standard for what > those "appropriately named PTRs" should look like. He has > forward/reverse that is perfectly ok according to standard > (forward/reverse matches) and if he had a automatic dictionary for > naming those IPs instead of putting the IPs there, things would be > different. > > If people want to make standards on how to put information into DNS > for RBL use, they should take it to the IETF and make a standard out > of it, not just ad-hoc I did.. a number of people went out of their way to bury it. One of who would do anything to bury anything SORBS does (I think we all know who that was.) > create something of their own and expect everybody else to conform. If > there is an "industry standard" (which the replies here seem to > indicate), that should be written down and standardized by the people > who actually make money out of it, in this case Trend Micro. This > would remove the problem of having to maintain tens or hundred points > of contacts for "what is dynamic dialup space" which is the problem > right now as there are a lot of RBLs to deal with. > > Creating a standard on what to put in WHOIS/DNS for > dynamic/static/infrastructure would make a lot of sense, seems nobody > is doing it though. > 100% with you!!!! ...and if people used "static" and "dynamic" keywords in DNS as I suggested in my previously mentioned draft, there would be *NO NEED* for DUL/DUHL/PBL lists at all because people could create a very simple set of patterns to match and therefore the RBLs would be unneccessary.. (and it would save me about 10 hours a day, every day of the week, every week of the year!) Currently I have a few 100 patterns and I know another on this list has more like the region of 10k patterns to do what in reality one should be able to do in 2 (10 at the most!). At 10k patterns it becomes a lot cheaper to use DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people do? Regards, Michelle From matthew at sorbs.net Wed Dec 16 17:09:05 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Wed, 16 Dec 2009 18:09:05 +0100 Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: <4B291431.2020701@sorbs.net> Please reply to the list, not me and the list! Sven Olaf Kamphuis wrote: > thing is that it's illegal to maintain a database with "personal details" > which ip addresses according to various german courts are (don't ask.. > mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not > persons, but the germans seem to mainain a different view on this, > despite us isps being the owners of the internet and not the german > government ;). > > therefore we are not even -allowed- to cooperate with trend micro *grin* > > sometimes laws really come in handy you know ;) > > Based on what you say there, then the RIPE whois database cannot contain the information either because it to would be maintaining a database of "personal details"... Love to hear the legal battle on that one! Michelle From Ray.Sanders at VillageVoiceMedia.com Wed Dec 16 17:16:29 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 16 Dec 2009 10:16:29 -0700 Subject: L.A Area routing issues? Message-ID: <4B28B37D020000F2000304E3@newtimes.com> Anyone in in the greater L.A area experiencing routing/traffic issues? Some of our remote users in L.A (various ISP's ) are having difficulty reaching some of our systems here in Phoenix. We are on Carpathia and Cogent here. Thanks "Prediction is very difficult, especially about the future." - Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From mpetach at netflight.com Wed Dec 16 17:21:42 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 16 Dec 2009 09:21:42 -0800 Subject: Arrogant RBL list maintainers In-Reply-To: <813.1260969676@localhost> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> <813.1260969676@localhost> Message-ID: <63ac96a50912160921j73d81f88n32f3500c7da7945e@mail.gmail.com> On Wed, Dec 16, 2009 at 5:21 AM, wrote: > On Wed, 16 Dec 2009 07:06:55 EST, Mike Lieman said: > >> What's the word for 'mail server' in Lower Sorbian, and does your algorithm >> properly detect it in a hostname? ?See the problem here? > > When the hostname at that IP address is exactly one incremented character > different than the preceding address, and one decremented character different > than the following address, and that pattern holds across a /24, they're > probably not mail servers. ?Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' > servers in the same /24 ?for *anything* user-facing. > You clearly haven't set up webmail farms to handle half a billion accounts before. ^_^; We name our (many thousands of) webmail front end boxes as webXYYZZ.mail.$site.yahoo.com, so for cluster 3, farm 57, you end up with a string of hosts all in a row like web35701.mail.mud.yahoo.com web35702.mail.mud.yahoo.com web35703.mail.mud.yahoo.com web35704.mail.mud.yahoo.com web35705.mail.mud.yahoo.com web35706.mail.mud.yahoo.com web35707.mail.mud.yahoo.com web35708.mail.mud.yahoo.com ...etc... Take a look at the reverse DNS for the entire 66.163.178.0/23 subnet; you'll find that when you're doing things at large scale, you can't really get away from having sequentially numbered reverse DNS entries all in a row, exactly as you seem to think "Nobody has". :/ Matt From jbates at brightok.net Wed Dec 16 17:26:07 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 16 Dec 2009 11:26:07 -0600 Subject: Arrogant RBL list maintainers In-Reply-To: <63ac96a50912160921j73d81f88n32f3500c7da7945e@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> <813.1260969676@localhost> <63ac96a50912160921j73d81f88n32f3500c7da7945e@mail.gmail.com> Message-ID: <4B29182F.8080003@brightok.net> Matthew Petach wrote: > Take a look at the reverse DNS for the entire 66.163.178.0/23 subnet; > you'll find that when you're doing things at large scale, you can't really > get away from having sequentially numbered reverse DNS entries all > in a row, exactly as you seem to think "Nobody has". :/ > Of course not. Everyone is small like me. Having more than 10 mail servers? How dare you use incremental numbers on such a large scale! Jack From matthew at sorbs.net Wed Dec 16 17:36:33 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Wed, 16 Dec 2009 18:36:33 +0100 Subject: Is there anyone from ASPEWS on this list? In-Reply-To: <4B27D8D5.8060108@steadfast.net> References: <20091211233929.39504.qmail@simone.iecc.com> <1260582204.4148.130.camel@petrie> <4B230483.8070700@rollernet.us> <4B237596.3010501@sorbs.net> <4B23CC90.3070702@sorbs.net> <4B261450.8070704@sorbs.net> <20091214193913.GN22555@clanspum.net> <4B27B67F.5090401@sorbs.net> <4B27D8D5.8060108@steadfast.net> Message-ID: <4B291AA1.9030809@sorbs.net> Kevin Stange wrote: > On 12/15/2009 10:17 AM, Michelle Sullivan wrote: > >> >> Thank you, I wasn't aware, and it will be corrected (doesn't say >> 3-5hours still so I'd love to find that one). >> >> > > There is this text I see, which seems to disagree with the robot's > behavior in my case (from the Dynamic IP FAQ): > > "The Regional Internet Registry (RIR) Point of Contact (PoC) can request > a listing or delisting of any address in their space. The only time this > will be refused is when the netblock information in the RIR or in the > reverse DNS naming clearly indicates the addresses are dynamically > assigned (e.g. 0.1.pool.example.com). " > > I'm sending my request from our PoC and it's not taking my word for it > like is claimed here (since the reverse DNS certainly doesn't imply the > ranges are dynamic). If you don't consider this part of the policy > anymore, you might want to clear that up in the FAQ. > > The robot has code to query whois, but we choose not to activate it (due to the possibility of abuse of the whois servers.) Mailing the ISP-support queue and identifying yourself as the RIR PoC will not result in the robot processing your message (unless supervised by a staff member aka me - sometimes I use it to do the ground work for me, not forgetting that clearly named dynamic rDNS will result in the complete refusal of the delisting request regardless of who it comes from.) ISP-Support queue maybe mailed directly or by using the webform: http://www.sorbs.net/cgi-bin/mail (or if you have a login to the Support website already you can log a ticket directly via the web). Note: blocks of smaller than /29 will not be delisted without appropriate rDNS being set. We do use information in local rwhois servers for authority, but there must be a referral to an authoritative rwhois server at the RIR (otherwise it could be some spammer's or home user's attempt to fool us.) Michelle From niels=nanog at bakker.net Wed Dec 16 17:45:50 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 16 Dec 2009 18:45:50 +0100 Subject: Arrogant RBL list maintainers In-Reply-To: <4B290D7F.5090008@sorbs.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> <2f1d68350912100559h200c0447s14640f90604d421f@mail.gmail.com> <4B290D7F.5090008@sorbs.net> Message-ID: <20091216174550.GC7799@burnout.tpb.net> * matthew at sorbs.net (Michelle Sullivan) [Wed 16 Dec 2009, 17:41 CET]: [..] >..... The obvious answer is if you have signed SLAs then you should >adhere to those SLAs as a minimum and give better service if time >allows... Hands up those who have an SLA (free or not) with an RBL >maintainer... I don't expect to see any hands... How much would you charge a company for it to get taken off immediately after it hits your list? -- Niels. From marka at isc.org Wed Dec 16 20:20:41 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 17 Dec 2009 07:20:41 +1100 Subject: DNS question, null MX records In-Reply-To: Your message of "Wed, 16 Dec 2009 11:20:14 -0000." <167CAB40-71D7-4BF9-988A-1A188B433C37@hopcount.ca> References: <827hsonth4.fsf@mid.bfk.de> <167CAB40-71D7-4BF9-988A-1A188B433C37@hopcount.ca> Message-ID: <200912162020.nBGKKf6u066979@drugs.dv.isc.org> In message <167CAB40-71D7-4BF9-988A-1A188B433C37 at hopcount.ca>, Joe Abley writes : > > On 2009-12-15, at 19:09, Tony Finch wrote: > > > On Tue, 15 Dec 2009, Florian Weimer wrote: > >> * Eric J. Esslinger: > >>=20 > >>> I found a reference to a null MX proposal, constructed so: > >>> example.com IN MX 0 . > >>=20 > >> I think this is quite controversal. > >=20 > > My impression from discussions on various IETF lists is that most = > people > > think it is a good idea, it is already reasonably widely implemented, = > but > > no-one has the time and persistence to push a spec through to = > publication. > > When I attempted to document a similar idea (using an empty label in the = > MNAME field of an SOA record in order to avoid unwanted DNS UPDATE = > traffic) the consensus of the room was that the idea was both = > controversial and bad :-) > > http://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00 Well UPDATE traffic is supposed to go to the nameservers listed in the NS RRset prefering the MNAME if and only if the MNAME is a nameserver. Lots of update clients don't do it quite right but there are some that actually send to all the nameservers. Setting the MNAME to "." does not actually address the problem. Mark > Joe > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Brian.Dickson at concertia.com Wed Dec 16 20:44:54 2009 From: Brian.Dickson at concertia.com (Brian Dickson) Date: Wed, 16 Dec 2009 16:44:54 -0400 Subject: DNS question, null MX records In-Reply-To: <200912162020.nBGKKf6u066979@drugs.dv.isc.org> References: <827hsonth4.fsf@mid.bfk.de> <167CAB40-71D7-4BF9-988A-1A188B433C37@hopcount.ca> <200912162020.nBGKKf6u066979@drugs.dv.isc.org> Message-ID: <21D41A38B8859B4A97B1AE2313922B8A820C60F5E3@concertiabl02.concertia.com> I realize we're a bit off-topic, but to be tangential to the original topic, and thus barely relevant: (Presuming the "sink.arpa." thing succeeds, big presumption I realize...) So, how about using sink.arpa. as a(n) MNAME? Or perhaps, one of the hosts listed in AS112? Maybe a new AS112 entry that resolves to one of the IP addresses mentioned already (127.0.0.1 and friends)? (Too bad there isn't a reserved IP address that definitively goes to /dev/null locally. Or is there?) Does an MNAME really need to be fully qualified? Cute idea: use the "search" of non-fully-qualified names, to direct bad UPDATE traffic to a very local server, e.g. "ns1" (no dot). It would also be nice to have a place-holder in DNS that "resolves" (in the loose sense) to an appropriate pre-defined "thing", like the default nameserver for a client, or "yourself" for a resolver. But I digress. :-) Brian -----Original Message----- > When I attempted to document a similar idea (using an empty label in the = > MNAME field of an SOA record in order to avoid unwanted DNS UPDATE = > traffic) the consensus of the room was that the idea was both = > controversial and bad :-) > > http://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00 Well UPDATE traffic is supposed to go to the nameservers listed in the NS RRset prefering the MNAME if and only if the MNAME is a nameserver. Lots of update clients don't do it quite right but there are some that actually send to all the nameservers. Setting the MNAME to "." does not actually address the problem. Mark > Joe > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jabley at hopcount.ca Wed Dec 16 20:53:20 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 16 Dec 2009 20:53:20 +0000 Subject: DNS question, null MX records In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A820C60F5E3@concertiabl02.concertia.com> References: <827hsonth4.fsf@mid.bfk.de> <167CAB40-71D7-4BF9-988A-1A188B433C37@hopcount.ca> <200912162020.nBGKKf6u066979@drugs.dv.isc.org> <21D41A38B8859B4A97B1AE2313922B8A820C60F5E3@concertiabl02.concertia.com> Message-ID: On 2009-12-16, at 20:44, Brian Dickson wrote: > So, how about using sink.arpa. as a(n) MNAME? That was another imagined use of SINK.ARPA. > Or perhaps, one of the hosts listed in AS112? My personal opinion is that there's an operational need for some people to receive an explicit reply from AS112 servers, or at least that a change in current behaviour will have noticeable consequences. > Does an MNAME really need to be fully qualified? All names in the DNS are fully-qualified on the wire, regardless of what short-cuts are available in the zone file format understood by particular pieces of software. > Cute idea: use the "search" of non-fully-qualified names, to direct bad UPDATE traffic to a very local server, e.g. "ns1" (no dot). All names in the DNS are fully-qualified on the wire. > It would also be nice to have a place-holder in DNS that "resolves" (in the loose sense) to an appropriate pre-defined "thing", like the default nameserver for a client, or "yourself" for a resolver. Beauty is apparently in the eye of the beholder :-) Joe From joakim at aronius.com Wed Dec 16 21:14:53 2009 From: joakim at aronius.com (Joakim Aronius) Date: Wed, 16 Dec 2009 22:14:53 +0100 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <3F8D0935-E714-4103-858C-D6FB30B1E5A2@akcin.net> <9F752F9C-8A43-4467-95A7-A1907E3BFF91@delong.com> <4B2521B1.7080603@bogus.com> <9B702073-059F-4653-A4CA-1DA963164C9A@delong.com> <4B2714F8.4050701@bogus.com> <2BDE5380-B69F-4068-AF7B-40E0724C9C91@cs.columbia.edu> <20091215124954.GA22285@maya.aronius.com> Message-ID: <20091216211452.GA11061@maya.aronius.com> * Mark Newton (newton at internode.com.au) wrote: > > On 15/12/2009, at 11:19 PM, Joakim Aronius wrote: > > > So what you are saying is that ease of use and service availability is priority one. Then what exactly are the responsibilities of the ISP and CPE manufacturer when it comes to security? CPEs with WiFi usually comes with the advice to change password etc. Is it ok to build an infrastructure relying on UPnP, write a disclaimer, and let the end user handle eventual problems? (I assume it is...) > > Hasn't essentially every ISP on the planet been doing that for years, > only without the disclaimer? > > It's not like we're talking about creating UPnP from whole cloth. We're > discussing a replacement of like-for-like, updating existing capabilities > to support IPv6. As was mentioned earlier the end-user is mostly clueless and 'just want things to work'(tm). They do not know/care enough to make wise decissions when it comes to security and they cant identify the absence of security features. Personally I only have rudimentary knowledge of UPnP and UPnP forum but there are real security issues with the protocol and no(?) effort to fix them, current security specs are from 2003. (and varying degree of implementation in products of the security features that actually are in the standard) In the last years the security problems in e.g. Microsoft products have gotten a lot of press and even Joe Sixpack has a hunch that he ought to get an anti-virus program. With the increasingly complex home network environment we will likely see more advanced attacks including UPnP. Then we have a situation with embedded devices with more and more functionality which are hard to patch, that run insecure protocols and it will end up in a real mess. I basically agree with you, adding IPv6 would be a like-for-like replacement. But one difference is that there is an increased attack vector with a higher degree of connectivity (no NAT) and more complex and less mature IP implementations in devices. UPnP might still be the the way to go as it is already there, 'it works' etc. But not working actively with the security issues in the standards is plain stupid. The standard and the functionality of the CPE is the responsibility of the CPE manufacturer. An I guess that the responsibility of the ISP is to provision its customers with as good and secure CPEs that the market provide (and if the s*** hits the fan, point at the CPE manufacturer). Regards, /Joakim From phiber at phiber.org Wed Dec 16 21:43:08 2009 From: phiber at phiber.org (Christopher Rogers) Date: Wed, 16 Dec 2009 13:43:08 -0800 Subject: Issues with level3 in Seattle Message-ID: Hey gang, just curious if anyone else has been having any issues with level3 (as3356) here in Seattle? 4 times today traffic transiting them has been blackholed for 1-2 minutes, and then recovers. No route withdrawals, etc.. just blackholing for a few minutes. Has happened 4 times now today, a few hours apart each time. I'd like to hear if anyone else has been having issues today before I call their noc... Thanks kindly, Christopher Rogers Network Engineer - real networks From clowe at intelius.com Wed Dec 16 21:49:35 2009 From: clowe at intelius.com (Chris Lowe) Date: Wed, 16 Dec 2009 13:49:35 -0800 Subject: Issues with level3 in Seattle In-Reply-To: References: Message-ID: <8E80582D6651CB47BE5B9CE81D63D048046784FB@exchange2.intelius1.intelius.com> It might be associated with some backbone problems that internap reported starting this morning. I got the "all is fixed" email about an hour ago. CL -----Original Message----- From: Christopher Rogers [mailto:phiber at phiber.org] Sent: Wednesday, December 16, 2009 1:43 PM To: nanog at nanog.org Subject: Issues with level3 in Seattle Hey gang, just curious if anyone else has been having any issues with level3 (as3356) here in Seattle? 4 times today traffic transiting them has been blackholed for 1-2 minutes, and then recovers. No route withdrawals, etc.. just blackholing for a few minutes. Has happened 4 times now today, a few hours apart each time. I'd like to hear if anyone else has been having issues today before I call their noc... Thanks kindly, Christopher Rogers Network Engineer - real networks From bryan.welch at digeo.com Wed Dec 16 21:51:46 2009 From: bryan.welch at digeo.com (Welch, Bryan(Digeo)) Date: Wed, 16 Dec 2009 13:51:46 -0800 Subject: Issues with level3 in Seattle In-Reply-To: <8E80582D6651CB47BE5B9CE81D63D048046784FB@exchange2.intelius1.intelius.com> References: <8E80582D6651CB47BE5B9CE81D63D048046784FB@exchange2.intelius1.intelius.com> Message-ID: Could be the AboveNet fiber they are likely using between the facilities. Bryan -----Original Message----- From: Chris Lowe [mailto:clowe at intelius.com] Sent: Wednesday, December 16, 2009 1:50 PM To: Christopher Rogers; nanog at nanog.org Subject: RE: Issues with level3 in Seattle It might be associated with some backbone problems that internap reported starting this morning. I got the "all is fixed" email about an hour ago. CL -----Original Message----- From: Christopher Rogers [mailto:phiber at phiber.org] Sent: Wednesday, December 16, 2009 1:43 PM To: nanog at nanog.org Subject: Issues with level3 in Seattle Hey gang, just curious if anyone else has been having any issues with level3 (as3356) here in Seattle? 4 times today traffic transiting them has been blackholed for 1-2 minutes, and then recovers. No route withdrawals, etc.. just blackholing for a few minutes. Has happened 4 times now today, a few hours apart each time. I'd like to hear if anyone else has been having issues today before I call their noc... Thanks kindly, Christopher Rogers Network Engineer - real networks From andree+nanog at toonk.nl Wed Dec 16 21:57:15 2009 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 16 Dec 2009 22:57:15 +0100 Subject: IP to authoritative CIDR webservices In-Reply-To: <1260853078.6328.19.camel@petrie> References: <1260853078.6328.19.camel@petrie> Message-ID: <20091216215715.GA13683@toonk.nl> Hi William, .-- My secret spy satellite informs me that at Mon, 14 Dec 2009, William Pitcock wrote: > Does anyone know of a webservice that converts a given IP into the > public CIDR range that belongs to? I am developing a tool where IP to > CIDR conversion based on RIR whois data would be useful for implementing > filtersets. Earlier this week, BGPmon.net made their webservices API (using SOAP) available for everyone. There are several functions that you might find useful. One of the functions available is getIpInfo(), which will return the best match prefix for an IPv4 or IPv6 address/prefix. This is based on BGP data (so not IRR data). It will also provide the OriginAS, AS description and country code for the prefix. There's also a whois interface that implements this getIpInfo() webservice. It's similar to rishwois and the Team Cymru IP to AS whois interface. $ whois -h whois.bgpmon.net 142.231.1.1 Prefix: 142.231.1.0/24 Country code: CA Origin AS: 271 Origin AS Name: BCNET-AS - BCnet Or for easy parsing : $ whois -h whois.bgpmon.net " -m 2001::dead:beef" BGP Prefix|CC|Origin AS| Origin AS Name 2001::/32|unknown|12637|SEEWEB Seeweb Srl 2001::/32|unknown|25525|REASONNET-AS Reasonnet IP Networks B.V. number 2001::/32|unknown|6939|HURRICANE - Hurricane Electric, Inc. 2001::/32|unknown|12859|NL-BIT BIT BV 2001::/32|unknown|21155|ASN-PROSERVE ProServe B.V. Networks 2001::/32|unknown|1257|TELE2 2001::/32|unknown|1741|FUNETAS FUNET autonomous system 2001::/32|unknown|29259|DE-IABG-TELEPORT IABG Teleport, DE 2001::/32|unknown|29432|TREX-AS TREX Tampere Region Exchange Oy For more information please see: http://bgpmon.net/blog/?p=213 http://bgpmon.net/bgpmonapi.php Cheers, Andree From matthew at sorbs.net Wed Dec 16 23:14:00 2009 From: matthew at sorbs.net (Michelle Sullivan) Date: Thu, 17 Dec 2009 00:14:00 +0100 Subject: Arrogant RBL list maintainers In-Reply-To: <20091216174550.GC7799@burnout.tpb.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B1FFF0C.4040404@csuohio.edu> <20091209200920.GW19942@sizone.org> <4B20141D.9090906@csuohio.edu> <2f1d68350912100559h200c0447s14640f90604d421f@mail.gmail.com> <4B290D7F.5090008@sorbs.net> <20091216174550.GC7799@burnout.tpb.net> Message-ID: <4B2969B8.7020807@sorbs.net> Niels Bakker wrote: > * matthew at sorbs.net (Michelle Sullivan) [Wed 16 Dec 2009, 17:41 CET]: > [..] >> ..... The obvious answer is if you have signed SLAs then you should >> adhere to those SLAs as a minimum and give better service if time >> allows... Hands up those who have an SLA (free or not) with an RBL >> maintainer... I don't expect to see any hands... > > How much would you charge a company for it to get taken off > immediately after it hits your list? > Nothing. I don't believe in such a practice because it would be fraught with the danger of being accused of pandering to spammers, extortion and blackmail. Its bad enough requiring a donation to charity for expedited delisting of just the spam DB entries. As for an SLA the only type I would consider (hypothetically) is a "we will provide a phone/pager number for you to call" or "we will answer your ticket by email within x hours" type SLA. In either case there would be a clause the states clearly that the SLA does not provide any sort of guaranteed delisting. Michelle PS: Have been asked to take this off list by someone who didn't identify themselves as a list manager, but they did it politely and I respect that, so all future replies from me to this thread will be offlist. Please feel free to reply to me *offlist*. Thanks. From schampeo at hesketh.com Wed Dec 16 23:39:10 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Wed, 16 Dec 2009 18:39:10 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B29127F.1010802@sorbs.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B29127F.1010802@sorbs.net> Message-ID: <20091216233910.GA16016@hesketh.com> on Wed, Dec 16, 2009 at 06:01:51PM +0100, Michelle Sullivan wrote: > ...and if people used "static" and "dynamic" keywords in DNS as I > suggested in my previously mentioned draft, there would be *NO NEED* > for DUL/DUHL/PBL lists at all because people could create a very > simple set of patterns to match and therefore the RBLs would be > unneccessary.. (and it would save me about 10 hours a day, every day > of the week, every week of the year!) Currently I have a few 100 > patterns and I know another on this list has more like the region of > 10k patterns to do what in reality one should be able to do in 2 (10 > at the most!). At 10k patterns it becomes a lot cheaper to use > DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people > do? 10K? Ha! Try 47086, as of the most recent release. Of course, those are all fully-qualified, and we deal with a much broader spectrum of classifications than just 'dynamic/static', because that a host is static doesn't mean much these days. As for the idea that you could make do with 2 patterns, as I've said elsewhere this is incredibly wishful thinking and Anglocentric, to boot, but the principle behind proper labeling is sound in a general sense. It just doesn't happen to be that way in the real world, which is full of non-English speaking netadmins and varieties of assignment beyond a simplistic "dynamic/static" split. For instance, resnets, which are usually statically assigned to a room, but not a given computer from one semester to another. Or my "dynamic" cable modem IP, which I've had for years, through four changes in our "static" office numbering/naming (three moves, four providers). Or NATs, which are static but allow dynamic users behind them to emit and receive traffic. Or Web hosts, which have the shared reputation of dynamics (on shared hosting, anyway). Or cloud computing, which is a dog's breakfast of mixed static ("elastic") and dynamically instantiated entities (though some simple efforts to clarify which are which in the PTRs would help that somewhat). Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From dotis at mail-abuse.org Thu Dec 17 00:02:56 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 16 Dec 2009 16:02:56 -0800 Subject: DNS question, null MX records In-Reply-To: References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> Message-ID: <4B297530.8030302@mail-abuse.org> On 12/16/09 3:59 AM, Tony Finch wrote: > On Wed, 16 Dec 2009, Mark Andrews wrote: >> Douglas Otis wrote: >>> >>> One might instead consider using: >>> >>> example.com. IN MX 0 192.0.2.0 >>> IN MX 10 192.0.2.1 >>> ... >>> IN MX 90 192.0.2.9 >> >> Which will expand to: >> >> example.com. IN MX 0 192.0.2.0.example.com. >> IN MX 10 192.0.2.1.example.com. >> .... >> IN MX 90 192.0.2.9.example.com. >> >> MX records DO NOT take IP addresses. Sorry for embarrassing mistake. To avoid server access and hitting roots: host-1.example.com. IN A 192.0.2.0 ... host-10.example.com. IN A 192.0.2.9 example.com. IN MX 0 host-1.example.com. ... example.com. IN MX 90 host-10.example.com. -Doug From jabley at hopcount.ca Thu Dec 17 00:08:56 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 17 Dec 2009 00:08:56 +0000 Subject: DNS question, null MX records In-Reply-To: <4B297530.8030302@mail-abuse.org> References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> Message-ID: On 2009-12-17, at 00:02, Douglas Otis wrote: > To avoid server access and hitting roots: > > host-1.example.com. IN A 192.0.2.0 > ... > host-10.example.com. IN A 192.0.2.9 > > example.com. IN MX 0 host-1.example.com. > ... > example.com. IN MX 90 host-10.example.com. This will still cause DNS requests to be sent towards 192.0.2.0 and 192.0.2.9, and they may not be dropped at the first router depending on local conditions. There are implications of state in the local resolver. Choosing MX RDATA with a name that is known not to exist ideally will only exercise the local cache for the non-existent name, since it will perhaps not be the first such query and the non-existence will already be cached. SINK.ARPA doesn't exist today. The document I referred to only exists to enforce that non-existence in the future; operationally you could install MX records towards SINK.ARPA today and get the desired effect, regardless of the state of the document. Joe From mark at streamservice.nl Thu Dec 17 00:35:32 2009 From: mark at streamservice.nl (Mark Scholten) Date: Thu, 17 Dec 2009 01:35:32 +0100 Subject: Arrogant RBL list maintainers In-Reply-To: <4B291431.2020701@sorbs.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> <4B291431.2020701@sorbs.net> Message-ID: <01db01ca7eb0$d76f7430$864e5c90$@nl> > -----Original Message----- > From: Michelle Sullivan [mailto:matthew at sorbs.net] > Sent: Wednesday, December 16, 2009 6:09 PM > To: nanog at nanog.org > Subject: Re: Arrogant RBL list maintainers > > Please reply to the list, not me and the list! > > Sven Olaf Kamphuis wrote: > > thing is that it's illegal to maintain a database with "personal > details" > > which ip addresses according to various german courts are (don't > ask.. > > mmk? ;) ofcourse we all know ip addresses identify nodes on a > network, not > > persons, but the germans seem to mainain a different view on this, > > despite us isps being the owners of the internet and not the german > > government ;). > > > > therefore we are not even -allowed- to cooperate with trend micro > *grin* > > > > sometimes laws really come in handy you know ;) > > > > > > Based on what you say there, then the RIPE whois database cannot > contain > the information either because it to would be maintaining a database of > "personal details"... As you probably know RIPE is located in the Netherlands and following Dutch law and not German law (however they are very similar). Publishing persons (done by RIPE in the whois database) is something that could be changed in the future (if I look to the current law in the Netherlands and SIDN did change the policy about whois information). > > Love to hear the legal battle on that one! > > > Michelle From dotis at mail-abuse.org Thu Dec 17 00:41:46 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 16 Dec 2009 16:41:46 -0800 Subject: DNS question, null MX records In-Reply-To: References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> Message-ID: <4B297E4A.4070302@mail-abuse.org> On 12/16/09 4:08 PM, Joe Abley wrote: > > On 2009-12-17, at 00:02, Douglas Otis wrote: > >> To avoid server access and hitting roots: >> >> host-1.example.com. IN A 192.0.2.0 >> ... >> host-10.example.com. IN A 192.0.2.9 >> >> example.com. IN MX 0 host-1.example.com. >> ... >> example.com. IN MX 90 host-10.example.com. > > This will still cause DNS requests to be sent towards 192.0.2.0 and > 192.0.2.9, and they may not be dropped at the first router depending > on local conditions. There are implications of state in the local > resolver. > > Choosing MX RDATA with a name that is known not to exist ideally > will only exercise the local cache for the non-existent name, since > it will perhaps not be the first such query and the non-existence > will already be cached. > > SINK.ARPA doesn't exist today. The document I referred to only > exists to enforce that non-existence in the future; operationally you > could install MX records towards SINK.ARPA today and get the desired > effect, regardless of the state of the document. The ARPA technique, as does pointing to the root, relies upon negative caching of non-existent A records. This allows spammers to quickly determine the inability to resolve addresses for MX hostnames and thereby bypass connection attempts. Offering a sequence in the TEST-NET block was to thwart the alternative of directly using the A record, which is likely to point to a server. If MX TEST-NET became common, legitimate email handlers unable to validate messages prior to acceptance might find their server resource constrained when bouncing a large amount of spam as well. -Doug From vixie at isc.org Thu Dec 17 00:48:00 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 17 Dec 2009 00:48:00 +0000 Subject: DNS question, null MX records In-Reply-To: <4B297E4A.4070302@mail-abuse.org> (Douglas Otis's message of "Wed\, 16 Dec 2009 16\:41\:46 -0800") References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> <4B297E4A.4070302@mail-abuse.org> Message-ID: Douglas Otis writes: > If MX TEST-NET became common, legitimate email handlers unable to > validate messages prior to acceptance might find their server > resource constrained when bouncing a large amount of spam as well. none of this will block spam. spammers do not follow RFC 974 today (since i see a lot of them come to my A RR rather than an MX RR, or in the wrong order). any well known pattern that says "don't try to deliver e-mail here" will only be honoured by friend people who don't want us to get e-mail we don't want to get. -- Paul Vixie KI6YSY From nenolod at systeminplace.net Thu Dec 17 00:57:07 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 16 Dec 2009 18:57:07 -0600 Subject: Arrogant RBL list maintainers In-Reply-To: References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B211728.8050302@dcrocker.net> Message-ID: <1261011427.3661.16.camel@petrie> Hi, On Thu, 2009-12-10 at 16:55 +0000, Sven Olaf Kamphuis wrote: > thing is that it's illegal to maintain a database with "personal details" > which ip addresses according to various german courts are (don't ask.. > mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not > persons, but the germans seem to mainain a different view on this, > despite us isps being the owners of the internet and not the german > government ;). > > therefore we are not even -allowed- to cooperate with trend micro *grin* You're Swedish, not German. So that doesn't really apply to you. I'm pretty sure that if you just update the WHOIS and say it's static assignments, that they will in fact remove you. Your network hosts e-trash anyway (thepiratebay), so I can hardly blame them for assuming everything on your network is rotten. > > sometimes laws really come in handy you know ;) Sometimes *valid* laws come in handy. Citing laws that do not, at all, apply to you, is not handy. In fact if you are citing it in some circumstances, it is fraud. William From dotis at mail-abuse.org Thu Dec 17 01:20:16 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 16 Dec 2009 17:20:16 -0800 Subject: DNS question, null MX records In-Reply-To: References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> <4B297E4A.4070302@mail-abuse.org> Message-ID: <4B298750.3010208@mail-abuse.org> On 12/16/09 4:48 PM, Paul Vixie wrote: > Douglas Otis writes: > >> If MX TEST-NET became common, legitimate email handlers unable to >> validate messages prior to acceptance might find their server >> resource constrained when bouncing a large amount of spam as well. > > none of this will block spam. spammers do not follow RFC 974 today > (since i see a lot of them come to my A RR rather than an MX RR, or > in the wrong order). any well known pattern that says "don't try > to deliver e-mail here" will only be honoured by friend people who > don't want us to get e-mail we don't want to get. Agreed. But it will impact providers generating a large amount of bounce traffic, and some portion of spam sources that often start at lower priority MX records in an attempt to find backup servers without valid recipient information. In either case, this will not cause extraneous traffic to hit roots or ARPA. -Doug From mikelieman at gmail.com Thu Dec 17 02:27:06 2009 From: mikelieman at gmail.com (Mike Lieman) Date: Wed, 16 Dec 2009 21:27:06 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <4B29127F.1010802@sorbs.net> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B29127F.1010802@sorbs.net> Message-ID: <43661d390912161827v4551d2aaha59a5126988ce3a2@mail.gmail.com> > > ...and if people used "static" and "dynamic" keywords in DNS as I suggested > in my previously mentioned draft, > > What are the words for "static" and "dynamic" in Lower Sorbian? From morrowc.lists at gmail.com Thu Dec 17 04:25:56 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 16 Dec 2009 23:25:56 -0500 Subject: IP to authoritative CIDR webservices In-Reply-To: <1260854303.6328.36.camel@petrie> References: <1260853078.6328.19.camel@petrie> <6cd462c00912142112l5903b68flaaa23a04e62b69d6@mail.gmail.com> <1260854303.6328.36.camel@petrie> Message-ID: <75cb24520912162025h6f8949ddn92de6299094bbdc5@mail.gmail.com> On Tue, Dec 15, 2009 at 12:18 AM, William Pitcock wrote: > Hi, > > On Mon, 2009-12-14 at 21:12 -0800, Paul Ferguson wrote: >> On Mon, Dec 14, 2009 at 8:57 PM, William Pitcock >> wrote: >> >> > Hi, >> > >> > Does anyone know of a webservice that converts a given IP into the >> > public CIDR range that belongs to? ?I am developing a tool where IP to >> > CIDR conversion based on RIR whois data would be useful for implementing >> > filtersets. >> > >> >> WHOIS? >> >> Alternatively, use the Team Cymru tool to find the AS, then the CIDR Report >> portal to determine all perfixes originated by the AS in question: >> >> http://asn.cymru.com/ > > Looks like their WHOIS server in verbose mode will do the trick for what > I want, as it provides predictable output. ?Thank you. there's also the lightish weight routeviews DNS zone data: $ host -W 6 -R 10 -t txt 50.35.2.128.asn.routeviews.org 50.35.2.128.asn.routeviews.org descriptive text "9" "128.2.0.0" "16" 128.2.35.50 lives in 128.2.0.0/16 from ASN9 -chris (thanks to joe/joel/dmm and capitan kemp) From Valdis.Kletnieks at vt.edu Thu Dec 17 05:07:22 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Dec 2009 00:07:22 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: Your message of "Wed, 16 Dec 2009 09:21:42 PST." <63ac96a50912160921j73d81f88n32f3500c7da7945e@mail.gmail.com> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> <813.1260969676@localhost> <63ac96a50912160921j73d81f88n32f3500c7da7945e@mail.gmail.com> Message-ID: <16710.1261026442@localhost> On Wed, 16 Dec 2009 09:21:42 PST, Matthew Petach said: > You clearly haven't set up webmail farms to handle half a billion accounts > before. ^_^; Yes, but we all already know who those 800 pound gorillas are. If you're doing automagic handling of this sort of DNS data, and not using a regexp to prevent auto-blocking any of the 800 pound gorillas... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From vixie at isc.org Thu Dec 17 05:36:01 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 17 Dec 2009 05:36:01 +0000 Subject: DNS question, null MX records In-Reply-To: <4B298750.3010208@mail-abuse.org> (Douglas Otis's message of "Wed\, 16 Dec 2009 17\:20\:16 -0800") References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> <4B297E4A.4070302@mail-abuse.org> <4B298750.3010208@mail-abuse.org> Message-ID: Douglas Otis writes: > Agreed. But it will impact providers generating a large amount of bounce > traffic, and some portion of spam sources that often start at lower > priority MX records in an attempt to find backup servers without valid > recipient information. In either case, this will not cause extraneous > traffic to hit roots or ARPA. if you're just trying to stop blowback from forged-source spam, and not trying to stop the spam itself, then some mechanism like an unreachable MX does seem called for. note that those approaches will cause queuing on the blowerbackers, rather than outright reject/die. other approaches that could cause outright reject/die would likely direct the blowback to the blowback postmasters, who are as innocent as the spam victims. i'm not sure there's a right way to do this in current SMTP. i used to think we could offer to verify that a piece of e-mail had come from us using some kind of semi-opaque H(message-id) scheme, but in studying it i found that as usual with spam the economic incentives are all backwards. -- Paul Vixie KI6YSY From mpetach at netflight.com Thu Dec 17 06:58:38 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 16 Dec 2009 22:58:38 -0800 Subject: Arrogant RBL list maintainers In-Reply-To: <16710.1261026442@localhost> References: <4B28708F.40709@memetic.org> <6eb799ab0912152212l793f2fd7jeabfb841c7b3b72f@mail.gmail.com> <4B28C947.6060804@memetic.org> <43661d390912160406w1bb31efcyb9c5df0a15493d22@mail.gmail.com> <813.1260969676@localhost> <63ac96a50912160921j73d81f88n32f3500c7da7945e@mail.gmail.com> <16710.1261026442@localhost> Message-ID: <63ac96a50912162258v778e27bcm2245cddb2c12cae6@mail.gmail.com> On Wed, Dec 16, 2009 at 9:07 PM, wrote: > On Wed, 16 Dec 2009 09:21:42 PST, Matthew Petach said: >> You clearly haven't set up webmail farms to handle half a billion accounts >> before. ?^_^; > > Yes, but we all already know who those 800 pound gorillas are. If you're > doing automagic handling of this sort of DNS data, and not using a regexp > to prevent auto-blocking any of the 800 pound gorillas... :) > So, it's uncool to do as long as you're small, but once you're big enough, it's OK to do. I wonder what the crossover point is? If you're an up-and-coming gorilla, but you're only 400 pounds, do you get a regexp and a waiver? What about if you're only 200 pounds? 100 pounds? Are we putting an artificial barrier in place, blocking new entrants into the space by grandfathering existing mail providers, but steadfastly keeping the gate closed against new providers trying to enter the marketplace? Are we guilty of collusion, gathering in virtual spaces like this to agree on how we can put rules in place to prevent any would-be mail hosting companies from being able to compete on a level playing field? At what point does the FTC decide that we've crossed a line in cooperating to keep these newcomers from doing business in our territory? No, I don't think we've crossed the line yet--but it does make me sit up and think about the various permutations and combinations that might arise out of conversations like this, and how they could be misinterpreted by government regulators. I suppose it's best if I make it very abundantly clear that I'm not speaking for my employer in any way, shape, or form here; I'm just ruminating after dinner with a full stomach and an empty head on my own time, just as me, nothing more. Matt From mehmet at akcin.net Thu Dec 17 10:47:18 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 17 Dec 2009 02:47:18 -0800 Subject: is there anything special about zz.com? Message-ID: Hello, [ insert decent apology here if this is unrelated. ] I am trying to find out whether there is anything special regarding zz.com that anyone who has seen attacks against their hosted dns servers. If there is anything you can think of please feel free to reply me offlist. thanks Mehmet From dot at dotat.at Thu Dec 17 12:54:39 2009 From: dot at dotat.at (Tony Finch) Date: Thu, 17 Dec 2009 12:54:39 +0000 Subject: DNS question, null MX records In-Reply-To: <4B297530.8030302@mail-abuse.org> References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> Message-ID: On Wed, 16 Dec 2009, Douglas Otis wrote: > > To avoid server access and hitting roots: > > host-1.example.com. IN A 192.0.2.0 > host-10.example.com. IN A 192.0.2.9 > > example.com. IN MX 0 host-1.example.com. > example.com. IN MX 90 host-10.example.com. This is not very good from the point of view of a legitimate but mistaken sender, because their messages will be queued and retried. The advantage of pointing MX records at nonexistent hosts is most MTAs (and all common ones) will stop trying to deliver the message immediately. It is perhaps more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups, unlike the nullmx or sink.arpa ideas. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From schampeo at hesketh.com Thu Dec 17 21:18:37 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 17 Dec 2009 16:18:37 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <43661d390912161827v4551d2aaha59a5126988ce3a2@mail.gmail.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B29127F.1010802@sorbs.net> <43661d390912161827v4551d2aaha59a5126988ce3a2@mail.gmail.com> Message-ID: <20091217211837.GA4374@hesketh.com> on Wed, Dec 16, 2009 at 09:27:06PM -0500, Mike Lieman wrote: > > > > ...and if people used "static" and "dynamic" keywords in DNS as I suggested > > in my previously mentioned draft, > > What are the words for "static" and "dynamic" in Lower Sorbian? I was bored so I looked them up. :-) dynamic: dynamika static: statik Dynamic was easy, translate to German dynamik, then to Lower Sorbian. Static doesn't seem to translate directly (a translation for statische wasn't in the online dictionary I found, but statik was). Either way, it's actually pretty close to English. But the point stands; some synonyms for static tokens from around the world: biz bus client /cliente commercial / commercio corp corporate corporativo cust ded dedicated emp / empresa fija (South America) fix fixee (FR) fixo (PT-BR) fx (JP, often used with bflets) sta / stat / static and some for dynamics: da dhcp dia dial dinamic (South America) dip du / dup dyn dynamic / dynamicip pool res And again, that doesn't even begin to address the mixins like resnets and NATs and other weirdnesses that lie outside this simplistic dichotomy. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From michael.holstein at csuohio.edu Thu Dec 17 21:57:46 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 17 Dec 2009 16:57:46 -0500 Subject: Arrogant RBL list maintainers In-Reply-To: <20091217211837.GA4374@hesketh.com> References: <4B1FE7E3.6000600@csuohio.edu> <4B1FF933.8030200@rollernet.us> <4B29127F.1010802@sorbs.net> <43661d390912161827v4551d2aaha59a5126988ce3a2@mail.gmail.com> <20091217211837.GA4374@hesketh.com> Message-ID: <4B2AA95A.3070809@csuohio.edu> > dynamic: dynamika > static: statik > One wonders how this will be handled when the flood of non-Latin domains starts. Are these RBL maintainers really going to figure out how many different ways there are to say the (English/Latin) equivalent of "static" in Chinese, Cyrillic, Swahili, etc. Cheers, Michael Holstein Cleveland State University From dotis at mail-abuse.org Thu Dec 17 23:02:48 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 17 Dec 2009 15:02:48 -0800 Subject: DNS question, null MX records In-Reply-To: References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> Message-ID: <4B2AB898.30908@mail-abuse.org> On 12/17/09 4:54 AM, Tony Finch wrote: > On Wed, 16 Dec 2009, Douglas Otis wrote: >> >> To avoid server access and hitting roots: >> >> host-1.example.com. IN A 192.0.2.0 >> host-10.example.com. IN A 192.0.2.9 >> >> example.com. IN MX 0 host-1.example.com. >> example.com. IN MX 90 host-10.example.com. > > This is not very good from the point of view of a legitimate but > mistaken sender, because their messages will be queued and retried. > The advantage of pointing MX records at nonexistent hosts is most > MTAs (and all common ones) will stop trying to deliver the message > immediately. It is perhaps more polite to use a nonexistent name that > you control, but that doesn't allow the source MTA to skip further > DNS lookups, unlike the nullmx or sink.arpa ideas. "." or "*.ARPA." are domains that won't resolve A records. Omit the A record in the above example accomplishes the same thing. DNS traffic can be reduced with long TTLs by using the TEST-NET technique. Pointing MX records toward root or ARPA domains exposes shared infrastructure to nuisance traffic from perhaps millions of sources expecting NSEC responses at negative caching rates. Traffic that should be handled by the name server declaring the service hostname. Better operators handling large email volumes reduce bounces and use retry back-off. Those who don't will find themselves disproportionally affected by a TEST-NET scheme. This seems to be a good thing, since there are far too many operators who carelessly accept email and expect others to deal with spoofed DSNs. Often the problem is due to serves being behind a border server lacking a valid recipient list that filters spam. The subsequent server with the valid recipient lists then aggressively attempts to deliver a growing number of DSNs having spoofed addresses holding spam that gets past filters. Why be friendly toward this type of behavior, especially at the expense of shared infrastructure? -Doug From hardie at oakthorn.com Thu Dec 17 23:16:12 2009 From: hardie at oakthorn.com (Ted Hardie) Date: Thu, 17 Dec 2009 15:16:12 -0800 (PST) Subject: sink.arpa question Message-ID: <1261091772.17216@mule.he.net> Silly question: how well would using 1.0.0.257.in-addr.arpa match the need identified in draft-jabley-sink-arpa ? It seems like it would be equally well guaranteed to be non-existant (short of change in the def of IPv4 and in-addr.arpa). Like sink.arpa, it would get you a valid SOA and nothing else. Am I missing something, or is this operationally equivalent? regards, Ted From jabley at hopcount.ca Fri Dec 18 01:54:54 2009 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 18 Dec 2009 01:54:54 +0000 Subject: sink.arpa question In-Reply-To: <1261091772.17216@mule.he.net> References: <1261091772.17216@mule.he.net> Message-ID: <226C2060-8630-429A-998B-3DC78CFECEEC@hopcount.ca> On 2009-12-17, at 23:16, Ted Hardie wrote: > Silly question: how well would using 1.0.0.257.in-addr.arpa match the > need identified in draft-jabley-sink-arpa ? > > It seems like it would be equally well guaranteed to be non-existant > (short of change in the def of IPv4 and in-addr.arpa). Like > sink.arpa, it would get you a valid SOA and nothing else. > > Am I missing something, or is this operationally equivalent? That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist. The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants. Joe From dougb at dougbarton.us Fri Dec 18 02:43:36 2009 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 17 Dec 2009 18:43:36 -0800 Subject: sink.arpa question In-Reply-To: <226C2060-8630-429A-998B-3DC78CFECEEC@hopcount.ca> References: <1261091772.17216@mule.he.net> <226C2060-8630-429A-998B-3DC78CFECEEC@hopcount.ca> Message-ID: <4B2AEC58.6050500@dougbarton.us> Joe Abley wrote: > On 2009-12-17, at 23:16, Ted Hardie wrote: > >> Silly question: how well would using 1.0.0.257.in-addr.arpa match the >> need identified in draft-jabley-sink-arpa ? >> >> It seems like it would be equally well guaranteed to be non-existant >> (short of change in the def of IPv4 and in-addr.arpa). Like >> sink.arpa, it would get you a valid SOA and nothing else. >> >> Am I missing something, or is this operationally equivalent? > > That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist. > > The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants. I was actually thinking that what could be useful would be a generic way to signal that a service is not available. Something like "noservice" (actual label is not important) as the first label of any hostname. Then if you are a person of good will and see that MNAME or the RHS of an MX record is assigned to "noservice.example.com" you would know not to bother to try doing whatever you were trying to do (dynamic dns updates, deliver mail, etc.). I would think that further specifying that any hostname with "noservice" as the first/only label MUST resolve to 127.0.0.1, etc. I'm sure there are also some other rough edges I'm not thinking of from off the top of my head. If this is interesting I would volunteer to write a draft for it, hopefully with Joe's help? (Both since I'm poaching his idea and because he's really good at writing drafts.) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From bmanning at vacation.karoshi.com Fri Dec 18 03:31:50 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 18 Dec 2009 03:31:50 +0000 Subject: sink.arpa question In-Reply-To: <1261091772.17216@mule.he.net> References: <1261091772.17216@mule.he.net> Message-ID: <20091218033150.GA2471@vacation.karoshi.com.> On Thu, Dec 17, 2009 at 03:16:12PM -0800, Ted Hardie wrote: > Silly question: how well would using 1.0.0.257.in-addr.arpa match the > need identified in draft-jabley-sink-arpa ? > > It seems like it would be equally well guaranteed to be non-existant > (short of change in the def of IPv4 and in-addr.arpa). Like > sink.arpa, it would get you a valid SOA and nothing else. > > Am I missing something, or is this operationally equivalent? > > regards, > > Ted which is likely to be a more persistent as a non-existant delegation? the forward space is almost entirely controlled by simple policy - while the reverse tree has some more structure around its non-existant state... imho of course. --bill From bmanning at vacation.karoshi.com Fri Dec 18 03:38:17 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 18 Dec 2009 03:38:17 +0000 Subject: sink.arpa question In-Reply-To: <4B2AEC58.6050500@dougbarton.us> References: <1261091772.17216@mule.he.net> <226C2060-8630-429A-998B-3DC78CFECEEC@hopcount.ca> <4B2AEC58.6050500@dougbarton.us> Message-ID: <20091218033817.GB2471@vacation.karoshi.com.> On Thu, Dec 17, 2009 at 06:43:36PM -0800, Doug Barton wrote: > Joe Abley wrote: > > On 2009-12-17, at 23:16, Ted Hardie wrote: > > > >> Silly question: how well would using 1.0.0.257.in-addr.arpa match the > >> need identified in draft-jabley-sink-arpa ? > >> > >> It seems like it would be equally well guaranteed to be non-existant > >> (short of change in the def of IPv4 and in-addr.arpa). Like > >> sink.arpa, it would get you a valid SOA and nothing else. > >> > >> Am I missing something, or is this operationally equivalent? > > > > That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist. > > > > The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants. > > I was actually thinking that what could be useful would be a generic > way to signal that a service is not available. Something like > "noservice" (actual label is not important) as the first label of any > hostname. Then if you are a person of good will and see that MNAME or > the RHS of an MX record is assigned to "noservice.example.com" you > would know not to bother to try doing whatever you were trying to do > (dynamic dns updates, deliver mail, etc.). > > I would think that further specifying that any hostname with > "noservice" as the first/only label MUST resolve to 127.0.0.1, etc. > I'm sure there are also some other rough edges I'm not thinking of > from off the top of my head. > > If this is interesting I would volunteer to write a draft for it, > hopefully with Joe's help? (Both since I'm poaching his idea and > because he's really good at writing drafts.) > > > Doug > > -- > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > I don't think we really want to see the return of the HINFO record do we? --bill From itservices88 at gmail.com Fri Dec 18 04:37:36 2009 From: itservices88 at gmail.com (itservices88) Date: Thu, 17 Dec 2009 20:37:36 -0800 Subject: OT: Voice Equipment Message-ID: <4b7c31fa0912172037r52a196c8u4dfd9f290a77ac3c@mail.gmail.com> Hi Nanogers, I am preparing for my CCIE Voice lab, which needs voice equipment hands on practice, and i don't have enough money to pursue that. Would it be possible if someone has spare phones like Cisco 7960g, PVDM modules, fxo/fxs VICs, mc3810 voice gateway, Digium T1/E1 card, 2621/3640 router or any other related equipment. I am in Pasadena, CA and can pick if available locally, or i would be happy to pay the shipping cost via paypal. Please send me any email off list. Thanks and appreciated. -aam From mysidia at gmail.com Fri Dec 18 05:26:25 2009 From: mysidia at gmail.com (James Hess) Date: Thu, 17 Dec 2009 23:26:25 -0600 Subject: DNS question, null MX records In-Reply-To: References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> Message-ID: <6eb799ab0912172126g1eac7e49ve8f803552f6dbd82@mail.gmail.com> On Thu, Dec 17, 2009 at 6:54 AM, Tony Finch wrote: > On Wed, 16 Dec 2009, Douglas Otis wrote: > more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups If you want to be kind, point the MX to an A record that resolves to 127.0.0.1. Common MX'es should immediately reject, and report a "configuration error"/MX loop with the domain. Your intent will also be clear, to just about everyone, it will be obvious the MX is intentionally broken. Other tricks may be more obscure, will be less obvious that you don't want mail, and may look like a mistake -- you might even get visitors to your domain contacting you to report the broken MX record. An alternative to resolving MX to an invalid IP might be to cut to the chase and just make further DNS lookups impossible altogether... @ 604800 IN MX MX.BOGUSMX BOGUSNS 604800 IN A 0.0.0.0 BOGUSMX 604800 IN NS BOGUSNS Or for that matter delegate the subdomain to 255.255.255.255. The recursive resolvers already have to immediately reject DNS delegation to broadcast addresses and the like. Though i'd be afraid of finding that some obscure resolver didn't...... [EG] "Gee thanks... some spammer exploited my open relay, and your broadcast NS delegation, caused my LAN to get swamped by my mail servers' DNS lookups while it was trying to send the 10 million spams to you...." -- -J From marka at isc.org Fri Dec 18 05:44:39 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Dec 2009 16:44:39 +1100 Subject: DNS question, null MX records In-Reply-To: Your message of "Thu, 17 Dec 2009 23:26:25 MDT." <6eb799ab0912172126g1eac7e49ve8f803552f6dbd82@mail.gmail.com> References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> <6eb799ab0912172126g1eac7e49ve8f803552f6dbd82@mail.gmail.com> Message-ID: <200912180544.nBI5idXH027997@drugs.dv.isc.org> In message <6eb799ab0912172126g1eac7e49ve8f803552f6dbd82 at mail.gmail.com>, James Hess writes: > On Thu, Dec 17, 2009 at 6:54 AM, Tony Finch wrote: > > On Wed, 16 Dec 2009, Douglas Otis wrote: > more polite to use a nonexisten > t name that you control, but that doesn't allow the source MTA to skip furt > her DNS lookups > If you want to be kind, point the MX to an A record that resolves to > 127.0.0.1. > Common MX'es should immediately reject, and report a "configuration > error"/MX loop with the domain. > > Your intent will also be clear, to just about everyone, it will be > obvious the MX is intentionally broken. Other tricks may be more > obscure, will be less obvious that you don't want mail, and may look > like a mistake -- you might even get visitors to your domain > contacting you to report the broken MX record. > > An alternative to resolving MX to an invalid IP might be to cut to the > chase and just make further DNS lookups impossible altogether... > > @ 604800 IN MX MX.BOGUSMX > BOGUSNS 604800 IN A 0.0.0.0 > BOGUSMX 604800 IN NS BOGUSNS > > Or for that matter delegate the subdomain to 255.255.255.255. > The recursive resolvers already have to immediately reject DNS > delegation to broadcast addresses and the like. > > Though i'd be afraid of finding that some obscure resolver didn't...... > > [EG] "Gee thanks... some spammer exploited my open relay, and your > broadcast NS delegation, caused my LAN to get swamped by my mail > servers' DNS lookups while it was trying to send the 10 million > spams to you...." > > -- > -J Just document "MX 0 ." and be done with it. MTA and MUA vendors will update their products. Most caching nameserver negatively cache the non-existance of address records so the traffic is mostly between the non-updated MTA and the recursive server. 2 queries (A and AAAA) every 3 hours won't kill the roots. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dane.newman at gmail.com Fri Dec 18 06:36:02 2009 From: dane.newman at gmail.com (Dane Newman) Date: Fri, 18 Dec 2009 01:36:02 -0500 Subject: OT: Voice Equipment In-Reply-To: <4b7c31fa0912172037r52a196c8u4dfd9f290a77ac3c@mail.gmail.com> References: <4b7c31fa0912172037r52a196c8u4dfd9f290a77ac3c@mail.gmail.com> Message-ID: I would suggest renting the gear with rack time.... On Thu, Dec 17, 2009 at 11:37 PM, itservices88 wrote: > Hi Nanogers, > > I am preparing for my CCIE Voice lab, which needs voice equipment hands on > practice, and i don't have enough money to pursue that. Would it be > possible > if someone has spare phones like Cisco 7960g, PVDM modules, fxo/fxs VICs, > mc3810 voice gateway, Digium T1/E1 card, 2621/3640 router or any other > related equipment. > > I am in Pasadena, CA and can pick if available locally, or i would be happy > to pay the shipping cost via paypal. > > Please send me any email off list. > > Thanks and appreciated. > -aam > From dot at dotat.at Fri Dec 18 11:46:39 2009 From: dot at dotat.at (Tony Finch) Date: Fri, 18 Dec 2009 11:46:39 +0000 Subject: DNS question, null MX records In-Reply-To: <6eb799ab0912172126g1eac7e49ve8f803552f6dbd82@mail.gmail.com> References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> <6eb799ab0912172126g1eac7e49ve8f803552f6dbd82@mail.gmail.com> Message-ID: On Thu, 17 Dec 2009, James Hess wrote: > Other tricks may be more obscure, will be less obvious that you don't > want mail, and may look like a mistake -- you might even get visitors to > your domain contacting you to report the broken MX record. I think that's true with the suggestions in the rest of your post. > An alternative to resolving MX to an invalid IP might be to cut to the > chase and just make further DNS lookups impossible altogether... > Or for that matter delegate the subdomain to 255.255.255.255. > The recursive resolvers already have to immediately reject DNS > delegation to broadcast addresses and the like. That'll result in a SERVFAIL DNS reply which the MTA will treat as a temporary failure. Remember the aim is to get MTAs to give up on undeliverable mail immediately. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From mehmet at akcin.net Fri Dec 18 12:34:05 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 18 Dec 2009 04:34:05 -0800 Subject: used hardware.. Message-ID: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet From rodrick.brown at gmail.com Fri Dec 18 13:29:07 2009 From: rodrick.brown at gmail.com (rodrick brown) Date: Fri, 18 Dec 2009 08:29:07 -0500 Subject: used hardware.. In-Reply-To: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> References: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> Message-ID: <2785D5F7-6726-4260-8704-E9229636B2AE@gmail.com> Craigslist Sent from my iPhone 3GS. On Dec 18, 2009, at 7:34 AM, Mehmet Akcin wrote: > Hello there.. > > I am looking to sell and buy some used hardware, where is the best > place for this, other than ebay ? > > Mostly juniper stuff > > thanks in advance. > > Mehmet From jay at miscreant.org Fri Dec 18 13:58:15 2009 From: jay at miscreant.org (Jay Mitchell) Date: Sat, 19 Dec 2009 00:58:15 +1100 Subject: DNS question, null MX records In-Reply-To: References: <4B27B3F7.7060007@nosignal.org> <4B284376.3000800@mail-abuse.org> <200912160258.nBG2wuPa051641@drugs.dv.isc.org> <4B297530.8030302@mail-abuse.org> <4B297E4A.4070302@mail-abuse.org> Message-ID: <001201ca7fea$27819900$7684cb00$@org> I concur, in fact I see them come in at precisely the wrong order, lowest preference first in the hopes that we're not running spam filtering on those particular hosts. I have found that putting a bogus mx record at lowest preference slows stuff down though. One of my services is for a company with about 150 mboxes, and I receive no less than 1.5mill spam emails a month for it. -----Original Message----- From: Paul Vixie [mailto:vixie at isc.org] Sent: Thursday, 17 December 2009 11:48 AM To: nanog at merit.edu Subject: Re: DNS question, null MX records Douglas Otis writes: > If MX TEST-NET became common, legitimate email handlers unable to > validate messages prior to acceptance might find their server > resource constrained when bouncing a large amount of spam as well. none of this will block spam. spammers do not follow RFC 974 today (since i see a lot of them come to my A RR rather than an MX RR, or in the wrong order). any well known pattern that says "don't try to deliver e-mail here" will only be honoured by friend people who don't want us to get e-mail we don't want to get. -- Paul Vixie KI6YSY From swmike at swm.pp.se Fri Dec 18 14:19:26 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 18 Dec 2009 15:19:26 +0100 (CET) Subject: used hardware.. In-Reply-To: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> References: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> Message-ID: On Fri, 18 Dec 2009, Mehmet Akcin wrote: > Hello there.. > > I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? > > Mostly juniper stuff network-resell at network-resell.com -- Mikael Abrahamsson email: swmike at swm.pp.se From bfeeny at mac.com Fri Dec 18 14:38:36 2009 From: bfeeny at mac.com (Brian Feeny) Date: Fri, 18 Dec 2009 09:38:36 -0500 Subject: used hardware.. In-Reply-To: References: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> Message-ID: <36B05E56-AF4D-4733-8395-1CD9B46F5DF1@mac.com> just an FYI they are down for a week or so while they relocate that list serv, suppose to be back up in about a week. Brian On Dec 18, 2009, at 9:19 AM, Mikael Abrahamsson wrote: > On Fri, 18 Dec 2009, Mehmet Akcin wrote: > >> Hello there.. >> >> I am looking to sell and buy some used hardware, where is the best >> place for this, other than ebay ? >> >> Mostly juniper stuff > > network-resell at network-resell.com > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From jason at i6ix.com Fri Dec 18 16:12:26 2009 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 18 Dec 2009 11:12:26 -0500 Subject: sink.arpa question In-Reply-To: <1261091772.17216@mule.he.net> References: <1261091772.17216@mule.he.net> Message-ID: <4B2BA9EA.5080504@i6ix.com> Ted Hardie wrote: > Silly question: how well would using 1.0.0.257.in-addr.arpa match the > need identified in draft-jabley-sink-arpa ? > > It seems like it would be equally well guaranteed to be non-existant > (short of change in the def of IPv4 and in-addr.arpa). Like > sink.arpa, it would get you a valid SOA and nothing else. > > Am I missing something, or is this operationally equivalent? > > regards, > > Ted > Isn't the fundamental problem that SMTP can fall back to an implicit MX? None of these solutions will stop spammers from skipping MX records and using direct-to-host connections. Shouldn't we just consider dropping the implicit MX back door as opposed to getting creative with MX records that spammers will surely note and avoid anyway? From dot at dotat.at Fri Dec 18 17:45:14 2009 From: dot at dotat.at (Tony Finch) Date: Fri, 18 Dec 2009 17:45:14 +0000 Subject: sink.arpa question In-Reply-To: <4B2BA9EA.5080504@i6ix.com> References: <1261091772.17216@mule.he.net> <4B2BA9EA.5080504@i6ix.com> Message-ID: On Fri, 18 Dec 2009, Jason Bertoch wrote: > > Isn't the fundamental problem that SMTP can fall back to an implicit MX? > None of these solutions will stop spammers from skipping MX records and > using direct-to-host connections. This has nothing to do with spam. > Shouldn't we just consider dropping the implicit MX back door as opposed > to getting creative with MX records that spammers will surely note and > avoid anyway? It's impossible to make that kind of incompatible change with an installed base of billions of users. It's already impossible to eliminate the AAAA fallback and keep the A fallback. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From jason at i6ix.com Fri Dec 18 18:09:45 2009 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 18 Dec 2009 13:09:45 -0500 Subject: sink.arpa question In-Reply-To: References: <1261091772.17216@mule.he.net> <4B2BA9EA.5080504@i6ix.com> Message-ID: <4B2BC569.2070602@i6ix.com> Tony Finch wrote: > On Fri, 18 Dec 2009, Jason Bertoch wrote: >> Isn't the fundamental problem that SMTP can fall back to an implicit MX? >> None of these solutions will stop spammers from skipping MX records and >> using direct-to-host connections. > > This has nothing to do with spam. > For the OP in the original thread, it dealt with spam. I would also argue that spammers abusing the implicit MX, most often through forgeries, provides the biggest motivation to find a fix. >> Shouldn't we just consider dropping the implicit MX back door as opposed >> to getting creative with MX records that spammers will surely note and >> avoid anyway? > > It's impossible to make that kind of incompatible change with an installed > base of billions of users. > I wouldn't call it impossible...difficult, maybe. Do metrics exist on how many current installs still rely on the implicit MX? Is the abuse of the implicit MX causing more harm than the effort it would take legacy DNS admins to specify an MX? From joly at punkcast.com Fri Dec 18 18:19:59 2009 From: joly at punkcast.com (Joly MacFie) Date: Fri, 18 Dec 2009 13:19:59 -0500 Subject: Chinese bgp metering story Message-ID: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From hardie at oakthorn.com Fri Dec 18 18:25:20 2009 From: hardie at oakthorn.com (Ted Hardie) Date: Fri, 18 Dec 2009 10:25:20 -0800 (PST) Subject: sink.arpa question In-Reply-To: <4B2BC569.2070602@i6ix.com> Message-ID: <1261160720.25842@mule.he.net> > > I wouldn't call it impossible...difficult, maybe. Do metrics exist on > how many current installs still rely on the implicit MX? Is the abuse > of the implicit MX causing more harm than the effort it would take > legacy DNS admins to specify an MX? > > If I understand your question, you're asking how many sites don't bother with an MX record, but count on the fallback to A to get their mail delivered. I have to say I don't know and don't know of anyone who has checked. I'm not sure that's its even possible to know without starting with a full knowledge of the mail-sending entities out there. Given that many entities allow for subdomain-level mail address (research.example.com, cs.example.edu), the number of extant domain names at some level of the hierarchy would only be a predictor. Possibly someone with a very large mail installation could run statistics to show how often they fell back; that wouldn't be perfect, but it would be somewhat useful. But I think the key question is actually different. Look at this text in RFC 2821: If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error. If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than keep seeking for an A/AAAA. Is *that* useful? If so, then sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. regards, Ted Hardie From woody at pch.net Fri Dec 18 18:27:21 2009 From: woody at pch.net (Bill Woodcock) Date: Fri, 18 Dec 2009 10:27:21 -0800 (PST) Subject: Chinese bgp metering story In-Reply-To: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> Message-ID: On Fri, 18 Dec 2009, Joly MacFie wrote: > I have posted sa comment on this from ISOC England on > http://www.isoc-ny.org/p2/?p=134 > Please feel free to add comments there. If anyone has questions about this, the "invited experts" who managed to wedge their feet in the door at the Kampala meeting were myself, Nishal Goburdhan (AfriNIC), and Michuki Mwangi (ISOC). Any of us would be happy to discuss it. We were there by the grace of the U.S. delegation, which fights the good fight on the Internet's behalf in intergovernmental negotiations like this. Note that there's another big fight coming up over whether the ITU should be allowed to screw up IP address allocation and aggregation. They're not just trying to screw up BGP. Badness abounds. -Bill From tme at americafree.tv Fri Dec 18 18:28:03 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 18 Dec 2009 13:28:03 -0500 Subject: Chinese bgp metering story In-Reply-To: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> Message-ID: There is also a discussion of this going on on the IETF discuss list. Regards Marshall On Dec 18, 2009, at 1:19 PM, Joly MacFie wrote: > I have posted sa comment on this from ISOC England on > http://www.isoc-ny.org/p2/?p=134 > > Please feel free to add comments there. > > -- > --------------------------------------------------------------- > Joly MacFie 917 442 8665 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > --------------------------------------------------------------- > > From cscora at apnic.net Fri Dec 18 18:29:41 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Dec 2009 04:29:41 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200912181829.nBIITfh7006321@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Dec, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 307389 Prefixes after maximum aggregation: 142780 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 151105 Total ASes present in the Internet Routing Table: 32965 Prefixes per ASN: 9.32 Origin-only ASes present in the Internet Routing Table: 28621 Origin ASes announcing only one prefix: 13977 Transit ASes present in the Internet Routing Table: 4344 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 694 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 360 Prefixes from 32-bit ASNs in the Routing Table: 334 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 165 Number of addresses announced to Internet: 2164856576 Equivalent to 129 /8s, 9 /16s and 23 /24s Percentage of available address space announced: 58.4 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.5 Total number of prefixes smaller than registry allocations: 148286 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 74394 Total APNIC prefixes after maximum aggregation: 25612 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 71083 Unique aggregates announced from the APNIC address blocks: 31155 APNIC Region origin ASes present in the Internet Routing Table: 3897 APNIC Prefixes per ASN: 18.24 APNIC Region origin ASes announcing only one prefix: 1056 APNIC Region transit ASes present in the Internet Routing Table: 603 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 485240352 Equivalent to 28 /8s, 236 /16s and 46 /24s Percentage of available APNIC address space announced: 80.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 128934 Total ARIN prefixes after maximum aggregation: 67391 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103169 Unique aggregates announced from the ARIN address blocks: 38997 ARIN Region origin ASes present in the Internet Routing Table: 13421 ARIN Prefixes per ASN: 7.69 ARIN Region origin ASes announcing only one prefix: 5191 ARIN Region transit ASes present in the Internet Routing Table: 1330 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 734074144 Equivalent to 43 /8s, 193 /16s and 21 /24s Percentage of available ARIN address space announced: 64.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70684 Total RIPE prefixes after maximum aggregation: 41371 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 64090 Unique aggregates announced from the RIPE address blocks: 42777 RIPE Region origin ASes present in the Internet Routing Table: 13908 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7242 RIPE Region transit ASes present in the Internet Routing Table: 2095 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 408585280 Equivalent to 24 /8s, 90 /16s and 132 /24s Percentage of available RIPE address space announced: 76.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26860 Total LACNIC prefixes after maximum aggregation: 6489 LACNIC Deaggregation factor: 4.14 Prefixes being announced from the LACNIC address blocks: 25206 Unique aggregates announced from the LACNIC address blocks: 13774 LACNIC Region origin ASes present in the Internet Routing Table: 1223 LACNIC Prefixes per ASN: 20.61 LACNIC Region origin ASes announcing only one prefix: 396 LACNIC Region transit ASes present in the Internet Routing Table: 201 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 69579776 Equivalent to 4 /8s, 37 /16s and 180 /24s Percentage of available LACNIC address space announced: 69.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5955 Total AfriNIC prefixes after maximum aggregation: 1588 AfriNIC Deaggregation factor: 3.75 Prefixes being announced from the AfriNIC address blocks: 4346 Unique aggregates announced from the AfriNIC address blocks: 1542 AfriNIC Region origin ASes present in the Internet Routing Table: 336 AfriNIC Prefixes per ASN: 12.93 AfriNIC Region origin ASes announcing only one prefix: 92 AfriNIC Region transit ASes present in the Internet Routing Table: 72 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14326784 Equivalent to 0 /8s, 218 /16s and 156 /24s Percentage of available AfriNIC address space announced: 42.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1776 7509 465 Korea Telecom (KIX) 17488 1458 145 133 Hathway IP Over Cable Interne 4755 1280 291 146 TATA Communications formerly 4134 1016 19444 396 CHINANET-BACKBONE 9583 999 75 502 Sify Limited 18101 993 204 35 Reliance Infocom Ltd Internet 7545 919 198 96 TPG Internet Pty Ltd 17974 846 272 61 PT TELEKOMUNIKASI INDONESIA 9829 844 676 23 BSNL National Internet Backbo 24560 814 295 177 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4191 3892 302 bellsouth.net, inc. 4323 3773 1067 400 Time Warner Telecom 1785 1796 699 134 PaeTec Communications, Inc. 7018 1590 5807 1035 AT&T WorldNet Services 20115 1530 1484 665 Charter Communications 2386 1289 616 930 AT&T Data Communications Serv 3356 1198 10929 423 Level 3 Communications, LLC 11492 1151 222 14 Cable One 22773 1122 2600 66 Cox Communications, Inc. 6478 1109 244 291 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 516 98 207 Evolva Telecom 35805 471 40 5 United Telecom of Georgia 9198 451 202 13 Kazakhtelecom Data Network Ad 3292 446 1903 391 TDC Tele Danmark 702 419 1837 337 UUNET - Commercial IP service 8866 378 110 23 Bulgarian Telecommunication C 8551 376 354 41 Bezeq International 3320 361 7068 307 Deutsche Telekom AG 3301 351 1412 307 TeliaNet Sweden 3215 349 3160 112 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1582 2899 230 UniNet S.A. de C.V. 10620 1003 223 130 TVCABLE BOGOTA 28573 828 673 83 NET Servicos de Comunicao S.A 7303 665 351 96 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 11172 446 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 432 858 29 Telecomunicacoes da Bahia S.A 3816 428 193 71 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1035 444 8 TEDATA 24863 713 142 54 LINKdotNET AS number 3741 273 857 233 The Internet Solution 2018 178 196 100 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 152 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 115 505 67 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4191 3892 302 bellsouth.net, inc. 4323 3773 1067 400 Time Warner Telecom 1785 1796 699 134 PaeTec Communications, Inc. 4766 1776 7509 465 Korea Telecom (KIX) 7018 1590 5807 1035 AT&T WorldNet Services 8151 1582 2899 230 UniNet S.A. de C.V. 20115 1530 1484 665 Charter Communications 17488 1458 145 133 Hathway IP Over Cable Interne 2386 1289 616 930 AT&T Data Communications Serv 4755 1280 291 146 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3773 3373 Time Warner Telecom 1785 1796 1662 PaeTec Communications, Inc. 8151 1582 1352 UniNet S.A. de C.V. 17488 1458 1325 Hathway IP Over Cable Interne 4766 1776 1311 Korea Telecom (KIX) 11492 1151 1137 Cable One 4755 1280 1134 TATA Communications formerly 22773 1122 1056 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1035 1027 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:65 /12:181 /13:381 /14:649 /15:1228 /16:10826 /17:5031 /18:8597 /19:17710 /20:21612 /21:21499 /22:27879 /23:28155 /24:160576 /25:931 /26:1169 /27:585 /28:232 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2731 4191 bellsouth.net, inc. 4323 2368 3773 Time Warner Telecom 4766 1426 1776 Korea Telecom (KIX) 1785 1263 1796 PaeTec Communications, Inc. 17488 1224 1458 Hathway IP Over Cable Interne 11492 1072 1151 Cable One 18566 1040 1059 Covad Communications 7018 956 1590 AT&T WorldNet Services 8452 931 1035 TEDATA 10620 908 1003 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 2:1 4:13 8:239 12:2017 13:9 15:22 16:3 17:8 20:37 24:1286 32:49 38:628 40:99 41:1853 43:1 44:3 46:1 47:21 52:6 55:2 56:2 57:24 58:646 59:660 60:446 61:1099 62:968 63:2020 64:3790 65:2374 66:4102 67:1757 68:1034 69:2840 70:685 71:232 72:1880 73:3 74:2046 75:224 76:366 77:857 78:602 79:402 80:949 81:812 82:467 83:442 84:533 85:1016 86:375 87:690 88:417 89:1559 90:63 91:2668 92:450 93:1131 94:1314 95:830 96:194 97:290 98:430 99:23 109:188 110:280 111:510 112:163 113:218 114:304 115:471 116:1089 117:595 118:366 119:813 120:144 121:833 122:1359 123:797 124:1025 125:1302 128:211 129:201 130:134 131:439 132:81 133:16 134:185 135:41 136:228 137:164 138:234 139:82 140:453 141:122 142:377 143:334 144:390 145:53 146:390 147:171 148:566 149:193 150:148 151:172 152:226 153:161 154:2 155:270 156:171 157:331 158:97 159:355 160:303 161:174 162:281 163:163 164:308 165:471 166:492 167:392 168:760 169:160 170:568 171:42 172:1 173:408 174:448 175:16 180:248 183:169 184:3 186:242 187:219 188:1086 189:620 190:3393 192:5712 193:4349 194:3373 195:2779 196:1197 198:3541 199:3393 200:5226 201:1436 202:7977 203:8308 204:3981 205:2156 206:2400 207:3049 208:3952 209:3404 210:2563 211:1147 212:1648 213:1646 214:233 215:45 216:4430 217:1367 218:478 219:455 220:1151 221:447 222:300 End of report From smb at cs.columbia.edu Fri Dec 18 18:32:02 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 18 Dec 2009 13:32:02 -0500 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> Message-ID: <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> On Dec 18, 2009, at 1:27 PM, Bill Woodcock wrote: > On Fri, 18 Dec 2009, Joly MacFie wrote: >> I have posted sa comment on this from ISOC England on >> http://www.isoc-ny.org/p2/?p=134 >> Please feel free to add comments there. > > If anyone has questions about this, the "invited experts" who managed to > wedge their feet in the door at the Kampala meeting were myself, Nishal > Goburdhan (AfriNIC), and Michuki Mwangi (ISOC). Any of us would be happy > to discuss it. We were there by the grace of the U.S. delegation, which > fights the good fight on the Internet's behalf in intergovernmental > negotiations like this. Could you post a summary, in appropriate technical terms, of precisely what is being requested, and what changes to BGP they want? --Steve Bellovin, http://www.cs.columbia.edu/~smb From r.gelobter at limestonenetworks.com Fri Dec 18 18:38:11 2009 From: r.gelobter at limestonenetworks.com (Ryan Gelobter) Date: Fri, 18 Dec 2009 12:38:11 -0600 Subject: used hardware.. In-Reply-To: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> References: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> Message-ID: <216636937ABE004E8CD94DDB2AD8BAA5017E9A528C61@lsnexchange.limestonenetworks.com> We use Network Hardware Resale every couple of months and they are great. I haven't had experience selling anything to them, only purchasing. http://www.networkhardware.com/ Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelobter at limestonenetworks.com www.limestonenetworks.com Simple.? Solid.? Superior. -----Original Message----- From: Mehmet Akcin [mailto:mehmet at akcin.net] Sent: Friday, December 18, 2009 6:34 AM To: nanog at nanog.org list Subject: used hardware.. Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet From fred at cisco.com Fri Dec 18 18:47:39 2009 From: fred at cisco.com (Fred Baker) Date: Fri, 18 Dec 2009 10:47:39 -0800 Subject: Chinese bgp metering story In-Reply-To: <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> Message-ID: <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> On Dec 18, 2009, at 10:32 AM, Steven Bellovin wrote: > Could you post a summary, in appropriate technical terms, of > precisely what is being requested, and what changes to BGP they want? Really. I can read tea leaves with the best of them, and the tea leaves I see tell me the reporter (in the story the blog points to) doesn't have a clue. What is the substance of the proposal? Depending on objectives, I would expect that this means that China wants to look at routers (which run BGP), and (a) use IPFIX-or-something to measure traffic rates and charge for trans-China transit, (b) use interface statistics to measure traffic rates and charge for trans-China transit, (c) tax Chinese ISPs for transit services they provide, or maybe (d) use IPFIX-or-something to map communication patterns. It would be (d) that the reporter might seriously want to worry about. But what is all this about "is the ITU interested in changing BGP"? If the word "metering" makes any sense in context, BGP doesn't meter anything. From jason at i6ix.com Fri Dec 18 18:49:06 2009 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 18 Dec 2009 13:49:06 -0500 Subject: sink.arpa question In-Reply-To: <1261160720.25842@mule.he.net> References: <1261160720.25842@mule.he.net> Message-ID: <4B2BCEA2.7010402@i6ix.com> Ted Hardie wrote: > > But I think the key question is actually different. Look at this > text in RFC 2821: > > > If one or more MX RRs are found for a given > name, SMTP systems MUST NOT utilize any A RRs associated with that > name unless they are located using the MX RRs; the "implicit MX" rule > above applies only if there are no MX records present. If MX records > are present, but none of them are usable, this situation MUST be > reported as an error. > > If I put in an MX record pointing to a guaranteed non-present > FQDN, someone complying with that text will throw an error rather than > keep seeking for an A/AAAA. Is *that* useful? If so, then > sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. > Yes, I understand the RFC. That section is what allows this topic to be discussed in the first place. sink.arpa may very well be the interim solution, too. It definitely looks better than "0 .". It just seems like an ugly, smelly hack when the fundamental problem lies with allowing the implicit MX. It implies that I should, for the benefit of everyone, create a sink.arpa MX for every A record, where the effort could be better spent dropping the implicit MX rule and requiring an MX record for hosts that really do accept mail. /Jason From smb at cs.columbia.edu Fri Dec 18 18:57:22 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 18 Dec 2009 13:57:22 -0500 Subject: Chinese bgp metering story In-Reply-To: <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> Message-ID: <848723D7-387F-42AE-8E00-22B358D32EC8@cs.columbia.edu> On Dec 18, 2009, at 1:47 PM, Fred Baker wrote: > > On Dec 18, 2009, at 10:32 AM, Steven Bellovin wrote: > >> Could you post a summary, in appropriate technical terms, of precisely what is being requested, and what changes to BGP they want? > > Really. > > I can read tea leaves with the best of them, and the tea leaves I see tell me the reporter (in the story the blog points to) doesn't have a clue. What is the substance of the proposal? > > Depending on objectives, I would expect that this means that China wants to look at routers (which run BGP), and > > (a) use IPFIX-or-something to measure traffic rates and charge for trans-China transit, > (b) use interface statistics to measure traffic rates and charge for trans-China transit, > (c) tax Chinese ISPs for transit services they provide, or maybe > (d) use IPFIX-or-something to map communication patterns. > > It would be (d) that the reporter might seriously want to worry about. > > But what is all this about "is the ITU interested in changing BGP"? If the word "metering" makes any sense in context, BGP doesn't meter anything. > > Or using BGP to carry charging information, so that ISPs could use that in their policies? Or charging end-to-end, rather than for transit? --Steve Bellovin, http://www.cs.columbia.edu/~smb From blewis at hottopic.com Fri Dec 18 19:03:00 2009 From: blewis at hottopic.com (Bill Lewis) Date: Fri, 18 Dec 2009 13:03:00 -0600 Subject: used hardware In-Reply-To: References: Message-ID: <26CF6BC367161D4BAFC39B6ED6F885F301D612E4@TNEXPRD.hottopic.com> http://www.networkhardware.com/ContactNHR/ Mostly Cisco, but I think they'll do Juniper. Bill ---------------------------------------------------------------------- -Date: Fri, 18 Dec 2009 04:34:05 -0800 -From: Mehmet Akcin -Subject: used hardware.. -To: "nanog at nanog.org list" -Message-ID: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B at akcin.net> -Content-Type: text/plain; charset=us-ascii -Hello there.. -I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? -Mostly juniper stuff -thanks in advance. -Mehmet From nick at foobar.org Fri Dec 18 19:03:37 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 18 Dec 2009 19:03:37 +0000 Subject: Chinese bgp metering story In-Reply-To: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> Message-ID: <4B2BD209.1030200@foobar.org> On 18/12/2009 18:19, Joly MacFie wrote: > I have posted sa comment on this from ISOC England on > http://www.isoc-ny.org/p2/?p=134 > > Please feel free to add comments there. I tried to read this article earlier today, but my lolwut meter exploded. It's not really clear whether the confusion in this article is caused by poor understanding on the part of the journalist, the ITU, the European Commission, the UK parliament or China. What is clear is that the article makes very little sense, other than to note that both China and the ITU like the idea of billing for bits at national borders. China, being the sort of state that it is, is perfectly welcome to impose restrictions like metering for traffic and imposing billing regimes on international players. The net result of this will probably be to trash China's network international connectivity, as the rest of the world mouths a collective "whatever, dude..." and then goes back to reading their less spamful inbox. The ITU, for its part, seems to be involved in a desperate bid to make itself relevant to the internet world - an ironic position, considering they did their level best to squat on the internet in the early 90s and ignore it in the late 90s and early noughties. Part of this desperation is manifesting itself as a movement by a number of countries to introduce international tariffing of internet bits and bytes at country borders. For some reason, this peculiar notion appears to make sense to governments and national telcos - presumably because that's how it works in the PSTN world. If all you have is a nail, everything looks like a hammer. This isn't the only irrelevant absurdity being proposed by the ITU just now. If you really want to have a good belly laugh at the level of misunderstanding by the ITU of how the internet actually works, just take a look at this document, which followed ITU Resolution 64: http://www.itu.int/dms_pub/itu-t/oth/3B/02/T3B020000020002PDFE.pdf In the mean-time, I am refilling my lolwut meter with a quadruple supply of "wtf"s, in preparation for the ITU's next move. There's a more serious aspect to this; the ITU is largely irrelevant to the Internet, and their actions indicate that they strongly resent this. And there is nothing more dangerous than a well-funded bureaucracy which realises that it is now - to all intents and purposes - irrelevant. Nick From blyon at blyon.com Fri Dec 18 19:07:50 2009 From: blyon at blyon.com (Barrett Lyon) Date: Fri, 18 Dec 2009 11:07:50 -0800 Subject: used hardware In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F301D612E4@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F301D612E4@TNEXPRD.hottopic.com> Message-ID: I buy a lot of gear from Peter Giberd at Townsend. I have been working with him for a good 7 years. It's budded into a friendship, good people there. -B http://www.townsendassets.com/ On Dec 18, 2009, at 11:03 AM, Bill Lewis wrote: > http://www.networkhardware.com/ContactNHR/ > Mostly Cisco, but I think they'll do Juniper. > > Bill > > ---------------------------------------------------------------------- > > -Date: Fri, 18 Dec 2009 04:34:05 -0800 > -From: Mehmet Akcin > -Subject: used hardware.. > -To: "nanog at nanog.org list" > -Message-ID: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B at akcin.net> > -Content-Type: text/plain; charset=us-ascii > -Hello there.. > -I am looking to sell and buy some used hardware, where is the best > place for this, other than ebay ? > -Mostly juniper stuff > -thanks in advance. > -Mehmet > From marc.williams at neustar.biz Fri Dec 18 19:22:59 2009 From: marc.williams at neustar.biz (Williams, Marc) Date: Fri, 18 Dec 2009 14:22:59 -0500 Subject: Chinese bgp metering story In-Reply-To: <4B2BD209.1030200@foobar.org> Message-ID: SIIA Chair Simon Tay on Clinton's Asia visit (Bloomberg, 20th Feb 2009): Steve Engel (Bloomberg): Speaking of provoking, where do you see Hillary bringing the tact in bringing the issues that Obama wants to raise to the Chinese in her trip this time. Yuan revaluation is one, and also of course human rights is top of the agenda. Is she going to be offending her host here? Simon Tay: Well, I think, China is the most important relationship that America has got across the Pacific. It's vital to them, and it's vital to everyone, and there are a couple of nasty missteps that could be made. I think the currency issue after the Tim Geithner confirmation statement would be one of the trickiest things to do. I think the downturn in China has been understood in America. The Chinese have their own domestic audience, their own domestic concerns, and if I were Clinton's advisor, I would tell Clinton, please don't go there too hard and too fast. I think that the human rights issue is similar. I think the America-China realtionship needs to go beyond these hotspots, whether it's Tibet, or currency, and really start off on something more positive. I mean, the tradition is (that) every (US) President starts off China wrong, and spends the next six years or so trying to get it right. It would be nice to see Clinton do something different and get it right from the start. On 12/18/09 2:03 PM, "Nick Hilliard" wrote: > On 18/12/2009 18:19, Joly MacFie wrote: >> I have posted sa comment on this from ISOC England on >> http://www.isoc-ny.org/p2/?p=134 >> >> Please feel free to add comments there. > > I tried to read this article earlier today, but my lolwut meter exploded. > > It's not really clear whether the confusion in this article is caused by > poor understanding on the part of the journalist, the ITU, the European > Commission, the UK parliament or China. What is clear is that the article > makes very little sense, other than to note that both China and the ITU > like the idea of billing for bits at national borders. > > China, being the sort of state that it is, is perfectly welcome to impose > restrictions like metering for traffic and imposing billing regimes on > international players. The net result of this will probably be to trash > China's network international connectivity, as the rest of the world mouths > a collective "whatever, dude..." and then goes back to reading their less > spamful inbox. > > The ITU, for its part, seems to be involved in a desperate bid to make > itself relevant to the internet world - an ironic position, considering > they did their level best to squat on the internet in the early 90s and > ignore it in the late 90s and early noughties. Part of this desperation is > manifesting itself as a movement by a number of countries to introduce > international tariffing of internet bits and bytes at country borders. For > some reason, this peculiar notion appears to make sense to governments and > national telcos - presumably because that's how it works in the PSTN world. > If all you have is a nail, everything looks like a hammer. > > This isn't the only irrelevant absurdity being proposed by the ITU just > now. If you really want to have a good belly laugh at the level of > misunderstanding by the ITU of how the internet actually works, just take a > look at this document, which followed ITU Resolution 64: > > http://www.itu.int/dms_pub/itu-t/oth/3B/02/T3B020000020002PDFE.pdf > > In the mean-time, I am refilling my lolwut meter with a quadruple supply of > "wtf"s, in preparation for the ITU's next move. > > There's a more serious aspect to this; the ITU is largely irrelevant to the > Internet, and their actions indicate that they strongly resent this. And > there is nothing more dangerous than a well-funded bureaucracy which > realises that it is now - to all intents and purposes - irrelevant. > > Nick > From jonny at pch.net Fri Dec 18 19:24:57 2009 From: jonny at pch.net (Jonny Martin) Date: Sat, 19 Dec 2009 02:24:57 +0700 Subject: Chinese bgp metering story In-Reply-To: <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> Message-ID: <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: > I can read tea leaves with the best of them, and the tea leaves I > see tell me the reporter (in the story the blog points to) doesn't > have a clue. What is the substance of the proposal? The report seemed a reasonably accurate account of what went on in Kampala. > But what is all this about "is the ITU interested in changing BGP"? > If the word "metering" makes any sense in context, BGP doesn't meter > anything. The Chinese delegation presented a dozen pages of formulae involving 20+ variables, infinite sums, and other mathematical goodies. Wowing the audience I guess. The whole way through "using BGP" was mentioned - in the sense of pulling data from, and adding data to BGP for the purposes of evaluating these formulae. It was clear that BGP would be used - and modified if need be - to achieve this. Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. Interesting to note was that nowhere was the intent of all this mentioned, which is presumably to calculate the "value" each and every party's traffic traversing a link generates, and to apportion "costs" accordingly. Misguided, nonsensical, and unworkable ideas often gain traction. It's important that this one doesn't. Cheers, Jonny. From deepak at ai.net Fri Dec 18 19:26:02 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 18 Dec 2009 14:26:02 -0500 Subject: Chinese bgp metering story In-Reply-To: <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> Message-ID: >From the BBC article quoted in the isoc-ny.org link: An ITU spokesman said: "The ITU has no plans to modify the BGP protocol, which is not an ITU-T standard. "A proposal has been made, and is being studied, to use BGP routers to collect traffic flow data, which could be used, by bilateral agreement, by operators for billing purposes." ---- I read this to mean, no news here. If you want to move traffic, you need a bilateral agreement. That already exists. Where/if money flows, we know circuits don't build themselves for free, so the question of using money isn't a question. The only question is whether you are adjusting based on usage, or ports, or total speed, or direction of bits. ITU is already acknowledging that BGP isn't its baby, so it has nothing to say there. Deepak From tme at americafree.tv Fri Dec 18 19:31:36 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 18 Dec 2009 14:31:36 -0500 Subject: Chinese bgp metering story In-Reply-To: <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> Message-ID: <062F7D3C-51B5-49E2-B363-59332864EC2C@americafree.tv> On Dec 18, 2009, at 2:24 PM, Jonny Martin wrote: > On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: >> I can read tea leaves with the best of them, and the tea leaves I >> see tell me the reporter (in the story the blog points to) doesn't >> have a clue. What is the substance of the proposal? > > The report seemed a reasonably accurate account of what went on in > Kampala. > >> But what is all this about "is the ITU interested in changing BGP"? >> If the word "metering" makes any sense in context, BGP doesn't >> meter anything. > > The Chinese delegation presented a dozen pages of formulae involving > 20+ variables, infinite sums, and other mathematical goodies. > Wowing the audience I guess. The whole way through "using BGP" was > mentioned - in the sense of pulling data from, and adding data to > BGP for the purposes of evaluating these formulae. It was clear > that BGP would be used - and modified if need be - to achieve this. > Mixing billing with the reachability information signalled through > BGP just doesn't seem like a good idea. Is this 12+ page presentation available anywhere ? Regards Marshall > > Interesting to note was that nowhere was the intent of all this > mentioned, which is presumably to calculate the "value" each and > every party's traffic traversing a link generates, and to apportion > "costs" accordingly. > > Misguided, nonsensical, and unworkable ideas often gain traction. > It's important that this one doesn't. > > Cheers, > Jonny. > > > From rdobbins at arbor.net Fri Dec 18 19:37:21 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 18 Dec 2009 19:37:21 +0000 Subject: Chinese bgp metering story In-Reply-To: <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> Message-ID: <39C2A739-1260-4840-BEF7-E66209B6C791@arbor.net> On Dec 19, 2009, at 2:24 AM, Jonny Martin wrote: > Mixing billing with > the reachability information signalled through BGP just doesn't seem > like a good idea. This is done all the time via combinatorial BGP/NetFlow analysis, for peering/transit analysis reports, offnet/on-net billing differentials, etc. The merits (or lack thereof) of the 'proposal' in question aside, there's nothing evil or stupid about doing this on one's own network. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Fri Dec 18 19:39:01 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 18 Dec 2009 19:39:01 +0000 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> Message-ID: On Dec 19, 2009, at 2:26 AM, Deepak Jain wrote: > "A proposal has been made, and is being studied, to use BGP routers to collect traffic flow data, which could be used, by bilateral agreement, by operators for billing purposes." Lots of 'BGP routers' are used to collect traffic flow data (NetFlow, cflowd, S/flow, NetStream, IPFIX, et. al.) to do this, ever single second of every single day, all around the world - including in China. It sounds as if the erstwhile proponents of this plan need to catch up to 1997 in terms of their operational clue. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From woody at pch.net Fri Dec 18 19:49:01 2009 From: woody at pch.net (Bill Woodcock) Date: Fri, 18 Dec 2009 11:49:01 -0800 (PST) Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> Message-ID: On Fri, 18 Dec 2009, Deepak Jain wrote: > ITU is already acknowledging that BGP isn't its baby, so it has nothing to say there. Yes, that was the successful (for us) outcome of the meeting, which would not have been the case had we not been prepared and had people there. Just to explain the general danger here... The ITU is the standards body in which international spectrum allocations and satellite lots are negotiated. No industrialized country will withdraw from that. Because it's an international treaty organization, member countries are bound to enforce the outcome of its decisions within their jurisdictions, regardless of whether they agreed with the decision or not. If the ITU had decided to take the BGP spec from the IETF, the IETF could easily have told them to take a hike, but national governments could not have done so, and that would put national governments in the very uncomfortable position of having to try to enact or support that change in law somehow. With the BGP spec, this all seems a bit ridiculous and abstract, but with IP allocation, the danger is a little more immediate. The decision on that will mostly be made in mid-March. -Bill From rdobbins at arbor.net Fri Dec 18 19:50:50 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 18 Dec 2009 19:50:50 +0000 Subject: Chinese bgp metering story In-Reply-To: <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> Message-ID: <2FCCC248-6F8C-4276-88BB-FFDC81A2BE02@arbor.net> On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: > But what is all this about "is the ITU interested in changing BGP"? If the word "metering" makes any sense in context, BGP doesn't meter anything. Neither the reporter nor the Chinese proponents nor the ITU seem to understand that making use of combined flow telemetry/BGP analytics for traffic engineering, capacity planning, and billing applications has been a common practice for the last 13 or so years. This seems to pretty much be a non-story, except for the nationalization aspect of it. I concur with Nick's hypothesis that the actual end-goal may be to 'harmonize' trans-national peering agreements/transit fees, and then tax them (probably regressively in terms of transnational traffic) - with a sidecar of surveillance for good measure. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Fri Dec 18 19:53:15 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 18 Dec 2009 19:53:15 +0000 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> Message-ID: <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> On Dec 19, 2009, at 2:49 AM, Bill Woodcock wrote: > The decision on that will mostly be made in mid-March. By whom? The RIRs aren't just going to say, "OK, ITU folks, it's all yours," heh. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From pstewart at nexicomgroup.net Fri Dec 18 20:00:02 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 18 Dec 2009 15:00:02 -0500 Subject: used hardware.. In-Reply-To: <216636937ABE004E8CD94DDB2AD8BAA5017E9A528C61@lsnexchange.limestonenetworks.com> References: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> <216636937ABE004E8CD94DDB2AD8BAA5017E9A528C61@lsnexchange.limestonenetworks.com> Message-ID: Our results with NHR were a disaster - that's all I'm say on a public list..... I highly recommend Knowledge Computers anytime someone asks - mention my name as a reference and you'll get a good price for sure ;) Hit me up offline for contact details should you wish... Paul -----Original Message----- From: Ryan Gelobter [mailto:r.gelobter at limestonenetworks.com] Sent: December-18-09 1:38 PM To: Mehmet Akcin; nanog at nanog.org list Subject: RE: used hardware.. We use Network Hardware Resale every couple of months and they are great. I haven't had experience selling anything to them, only purchasing. http://www.networkhardware.com/ Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelobter at limestonenetworks.com www.limestonenetworks.com Simple.? Solid.? Superior. -----Original Message----- From: Mehmet Akcin [mailto:mehmet at akcin.net] Sent: Friday, December 18, 2009 6:34 AM To: nanog at nanog.org list Subject: used hardware.. Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From woody at pch.net Fri Dec 18 20:05:01 2009 From: woody at pch.net (Bill Woodcock) Date: Fri, 18 Dec 2009 12:05:01 -0800 (PST) Subject: Chinese bgp metering story In-Reply-To: <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> Message-ID: On Fri, 18 Dec 2009, Dobbins, Roland wrote: > > The decision on that will mostly be made in mid-March. > By whom? A working group of the ITU Council. > The RIRs aren't just going to say, "OK, ITU folks, it's all yours," heh. Indeed not. However, the RIRs don't have a voice in the decision. This is an intergovernmental decision within the ITU Council. If the ITU Council were to decide that it's a good idea for the ITU to take over IP addressing and break it, they would then take it to the ITU Plenipotentiary. At that point, it could become policy of the treaty organization, and then member country governments would become bound to support the policy in their own legal structures. Odds are that would be expressed in laws similar to that of Korea, where it's illegal for network operators to get IP addresses from APNIC, their RIR, and they must instead get them from KRNIC, a Korean governmental agency. Which, in turn, proxies their votes in the APNIC elections, but that's another story. :-) -Bill From azher at hep.caltech.edu Fri Dec 18 20:15:13 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Fri, 18 Dec 2009 12:15:13 -0800 Subject: used hardware.. In-Reply-To: References: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B@akcin.net> <216636937ABE004E8CD94DDB2AD8BAA5017E9A528C61@lsnexchange.limestonenetworks.com> Message-ID: <4B2BE2D1.7060000@hep.caltech.edu> Not advocating NHR, but I bought one 6509 switch with several blades and no trouble for about a year. -Azher Paul Stewart wrote: > Our results with NHR were a disaster - that's all I'm say on a public list..... I highly recommend Knowledge Computers anytime someone asks - mention my name as a reference and you'll get a good price for sure ;) Hit me up offline for contact details should you wish... > > Paul > > > -----Original Message----- > From: Ryan Gelobter [mailto:r.gelobter at limestonenetworks.com] > Sent: December-18-09 1:38 PM > To: Mehmet Akcin; nanog at nanog.org list > Subject: RE: used hardware.. > > We use Network Hardware Resale every couple of months and they are great. I haven't had experience selling anything to them, only purchasing. > > http://www.networkhardware.com/ > > Ryan G > IT Assistant/Support Technician > Limestone Networks, Inc. > r.gelobter at limestonenetworks.com > www.limestonenetworks.com > Simple. Solid. Superior. > > > -----Original Message----- > From: Mehmet Akcin [mailto:mehmet at akcin.net] > Sent: Friday, December 18, 2009 6:34 AM > To: nanog at nanog.org list > Subject: used hardware.. > > Hello there.. > > I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? > > Mostly juniper stuff > > thanks in advance. > > Mehmet > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > > From fred at cisco.com Fri Dec 18 20:27:02 2009 From: fred at cisco.com (Fred Baker) Date: Fri, 18 Dec 2009 12:27:02 -0800 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> Message-ID: My sense is that the ITU has played with such ideas in the past, and the governments have for the most part found it in their interest to not screw with the Internet. Do you have any specific recommendations on how to keep that true? On Dec 18, 2009, at 12:05 PM, Bill Woodcock wrote: > > On Fri, 18 Dec 2009, Dobbins, Roland wrote: >>> The decision on that will mostly be made in mid-March. >> By whom? > > A working group of the ITU Council. > >> The RIRs aren't just going to say, "OK, ITU folks, it's all yours," >> heh. > > Indeed not. However, the RIRs don't have a voice in the decision. > This > is an intergovernmental decision within the ITU Council. If the ITU > Council were to decide that it's a good idea for the ITU to take > over IP > addressing and break it, they would then take it to the ITU > Plenipotentiary. At that point, it could become policy of the treaty > organization, and then member country governments would become bound > to > support the policy in their own legal structures. Odds are that > would be > expressed in laws similar to that of Korea, where it's illegal for > network > operators to get IP addresses from APNIC, their RIR, and they must > instead > get them from KRNIC, a Korean governmental agency. Which, in turn, > proxies their votes in the APNIC elections, but that's another > story. :-) > > -Bill > > http://www.ipinc.net/IPv4.GIF From jmamodio at gmail.com Fri Dec 18 20:43:02 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 18 Dec 2009 14:43:02 -0600 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> Message-ID: <202705b0912181243k2e0f4f67h843dd43da14acaa1@mail.gmail.com> Why can't we carry price per "kilosegment" on BGP ? And don't be so hard on the ITU folks, the only thing they want to break is the monopoly of IP address allocation. J From fred at cisco.com Fri Dec 18 20:53:56 2009 From: fred at cisco.com (Fred Baker) Date: Fri, 18 Dec 2009 12:53:56 -0800 Subject: Chinese bgp metering story In-Reply-To: <202705b0912181243k2e0f4f67h843dd43da14acaa1@mail.gmail.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> <202705b0912181243k2e0f4f67h843dd43da14acaa1@mail.gmail.com> Message-ID: On Dec 18, 2009, at 12:43 PM, Jorge Amodio wrote: > And don't be so hard on the ITU folks, the only thing they want to > break is the monopoly of IP address allocation. With all due respect, they don't want to break said monopoly, assuming one agrees that it is a monopoly (I think there's a lot more to the story than that, but that's another discussion). They want to *be* said monopoly. From jmamodio at gmail.com Fri Dec 18 21:01:54 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 18 Dec 2009 15:01:54 -0600 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <2B910601-F7D9-4551-904D-43B7060F7804@arbor.net> <202705b0912181243k2e0f4f67h843dd43da14acaa1@mail.gmail.com> Message-ID: <202705b0912181301q53f303fbg98eee250776b9d23@mail.gmail.com> On Fri, Dec 18, 2009 at 2:53 PM, Fred Baker wrote: > > On Dec 18, 2009, at 12:43 PM, Jorge Amodio wrote: >> >> And don't be so hard on the ITU folks, the only thing they want to break >> is the monopoly of IP address allocation. > > With all due respect, they don't want to break said monopoly, assuming one > agrees that it is a monopoly (I think there's a lot more to the story than > that, but that's another discussion). They want to *be* said monopoly. Indeed !!! I was being sarcastic, I was watching live the last IGF meeting when by proxy ICANN's CEO got grilled with the question about IPv6 address allocation. Jorge From sharp at sharpone.net Fri Dec 18 21:58:13 2009 From: sharp at sharpone.net (Justin T. Sharp) Date: Fri, 18 Dec 2009 14:58:13 -0700 Subject: Rackspace outage Message-ID: <4B2BFAF5.4020001@sharpone.net> Rackspace seems to have a severe routing loop, which appears to have taken a lot of sites down. Does anyone have any information on this? Host Loss% Last Avg Best Wrst StDev 1. ssg-vlan1011.lindon.pei 0.0% 0.2 0.2 0.1 1.2 0.2 2. pub-192-41-10-33.center7.com 0.0% 0.8 2.2 0.7 77.0 8.0 3. pub-192-41-0-37.center7.com 0.0% 0.4 0.4 0.3 9.7 0.5 4. s3-1-0-28--0.gw03.slkc.eli.net 0.0% 159.4 11.4 1.4 201.5 34.4 5. tg9-1.cr02.slkcutxd.integra.net 0.0% 183.4 48.4 29.2 233.2 48.3 6. tg9-1.cr01.dnvrcoet.integra.net 0.0% 201.2 50.5 29.2 246.2 49.4 7. tg13-1.cr01.dllstx97.integra.net 0.0% 111.2 45.4 29.2 230.2 46.2 8. tg1-1.br01.dllstx97.integra.net 0.0% 113.7 38.4 29.3 222.8 33.1 9. eq-dfw.rackspace.net 2.8% 428.8 738.2 229.4 1416. 200.2 10. core5-bbr1-vlan2005.dfw1.rackspace.net 88.8% 51.4 116.8 46.8 351.3 73.5 core5-bbr1-vlan3005.dfw1.rackspace.net core1-bbr1-vlan2001.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net core3-bbr1-vlan3003.dfw1.rackspace.net 11. bbr1-core5-vlan2005.dfw1.rackspace.net 91.6% 648.7 595.6 245.0 1014. 197.9 bbr1-core5-vlan3005.dfw1.rackspace.net bbr1-core1-vlan3001.dfw1.rackspace.net bbr1-core1-vlan2001.dfw1.rackspace.net bbr1-core3-vlan3003.dfw1.rackspace.net intra-core3-core1.dfw1.rackspace.com 12. core5-bbr1-vlan2005.dfw1.rackspace.net 89.7% 139.3 153.9 46.6 439.3 109.8 core5-bbr1-vlan3005.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net core1-bbr1-vlan2001.dfw1.rackspace.net core3-bbr1-vlan3003.dfw1.rackspace.net 13. bbr1-core5-vlan2005.dfw1.rackspace.net 91.1% 475.6 642.1 91.9 1516. 296.1 bbr1-core5-vlan3005.dfw1.rackspace.net bbr1-core1-vlan3001.dfw1.rackspace.net bbr1-core1-vlan2001.dfw1.rackspace.net bbr1-core3-vlan3003.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net 14. core5-bbr1-vlan2005.dfw1.rackspace.net 91.9% 147.4 170.8 66.0 475.1 122.6 core5-bbr1-vlan3005.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net core1-bbr1-vlan2001.dfw1.rackspace.net core3-bbr1-vlan3003.dfw1.rackspace.net intra-core3-core1.dfw1.rackspace.com --Justin From cidr-report at potaroo.net Fri Dec 18 22:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Dec 2009 22:00:04 GMT Subject: BGP Update Report Message-ID: <200912182200.nBIM04W4016088@wattle.apnic.net> BGP Update Report Interval: 10-Dec-09 -to- 17-Dec-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23577 16590 2.0% 24.1 -- ATM-MPLS-AS-KR Korea Telecom 2 - AS28477 13270 1.6% 1474.4 -- Universidad Autonoma del Esstado de Morelos 3 - AS9842 12792 1.5% 799.5 -- LDCC-AS Lotte Data Communication Company 4 - AS6822 11009 1.3% 550.5 -- SUPERONLINE-AS SuperOnline autonomous system 5 - AS5800 8918 1.1% 48.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS8551 8775 1.1% 26.4 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone 7 - AS35805 8542 1.0% 17.6 -- UTG-AS United Telecom AS 8 - AS34584 8010 1.0% 98.9 -- KHBDSV AS for ISP - Khabarovsk Telecommunication Center 9 - AS8452 7516 0.9% 12.7 -- TEDATA TEDATA 10 - AS9198 7361 0.9% 15.6 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - AS7643 7064 0.8% 32.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 12 - AS4249 6412 0.8% 36.9 -- LILLY-AS - Eli Lilly and Company 13 - AS9829 6376 0.8% 14.1 -- BSNL-NIB National Internet Backbone 14 - AS11139 5642 0.7% 14.1 -- CWRIN CW BARBADOS 15 - AS5434 5350 0.6% 47.3 -- NURSAT-ALA-AS Nursat-Almaty 16 - AS17964 4880 0.6% 69.7 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 17 - AS5803 4388 0.5% 50.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS34137 4180 0.5% 149.3 -- RUAMUR-AS Far east Telecommunications Company AS 19 - AS8151 4157 0.5% 5.7 -- Uninet S.A. de C.V. 20 - AS17974 3750 0.5% 9.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS27667 2846 0.3% 2846.0 -- Universidad Autonoma de la Laguna 2 - AS48754 2591 0.3% 2591.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS8909 2468 0.3% 2468.0 -- AMURSU-AS AMURSU Autonomous System 4 - AS39384 1892 0.2% 1892.0 -- GUILAN-UNIV-AS University of Guilan AS System 5 - AS14251 1879 0.2% 1879.0 -- MLSLI - Multiple Lising Service of Long Island, Inc. 6 - AS45927 1481 0.2% 1481.0 -- SCCL-123-IN THE SINGARENI COLLIERIES COMPANY LIMITED 7 - AS28477 13270 1.6% 1474.4 -- Universidad Autonoma del Esstado de Morelos 8 - AS5691 2763 0.3% 1381.5 -- MITRE-AS-5 - The MITRE Corporation 9 - AS15145 1213 0.1% 1213.0 -- GLOBALSCAPE - GlobalSCAPE, Inc. 10 - AS4270 2796 0.3% 932.0 -- Red de Interconexion Universitaria 11 - AS9842 12792 1.5% 799.5 -- LDCC-AS Lotte Data Communication Company 12 - AS17819 1977 0.2% 659.0 -- ASN-EQUINIX-AP Equinix Asia Pacific 13 - AS41368 645 0.1% 645.0 -- TVALMANSA-ASN TV ALMANSA, Servicios de Comunicacion 14 - AS39803 1264 0.1% 632.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 15 - AS6822 11009 1.3% 550.5 -- SUPERONLINE-AS SuperOnline autonomous system 16 - AS34787 460 0.1% 460.0 -- LYAKH-AS PF "Volodymyr Lyakh" 17 - AS6453 1266 0.1% 422.0 -- GLOBEINTERNET TATA Communications 18 - AS25585 416 0.1% 416.0 -- KENCOMP Kencomp Internet LTD, Small UK Internet Provider 19 - AS47559 400 0.1% 400.0 -- TSCNET-AS SC Tele Satelyt Company SRL 20 - AS37136 351 0.0% 351.0 -- ETISALAT-AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 13158 1.4% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 89.144.140.0/24 4551 0.5% AS39308 -- ASK-AS Andishe Sabz Khazar Autonomous System AS39384 -- GUILAN-UNIV-AS University of Guilan AS System 3 - 143.138.107.0/24 3027 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 4 - 148.245.181.0/24 2846 0.3% AS27667 -- Universidad Autonoma de la Laguna 5 - 170.210.56.0/22 2792 0.3% AS4270 -- Red de Interconexion Universitaria 6 - 192.12.120.0/24 2761 0.3% AS5691 -- MITRE-AS-5 - The MITRE Corporation 7 - 91.212.23.0/24 2591 0.3% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 8 - 202.5.154.0/24 2492 0.3% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 9 - 62.76.124.0/23 2468 0.3% AS8909 -- AMURSU-AS AMURSU Autonomous System 10 - 203.162.118.128/ 2262 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 11 - 65.223.235.0/24 1879 0.2% AS14251 -- MLSLI - Multiple Lising Service of Long Island, Inc. 12 - 212.253.0.0/17 1872 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 13 - 212.253.192.0/18 1871 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 14 - 212.253.20.0/24 1857 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 15 - 212.253.7.0/24 1796 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 16 - 212.253.13.0/24 1796 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 17 - 212.253.6.0/24 1795 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 18 - 202.177.223.0/24 1670 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 19 - 90.150.0.0/24 1668 0.2% AS35400 -- MFIST Interregoinal Organization Network Technologies 20 - 222.255.186.0/25 1500 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 18 22:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Dec 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200912182200.nBIM00M4016071@wattle.apnic.net> This report has been generated at Fri Dec 18 21:11:23 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 11-12-09 311684 190297 12-12-09 308771 192299 13-12-09 311685 192429 14-12-09 311744 192541 15-12-09 311908 192248 16-12-09 312103 192508 17-12-09 312072 192815 18-12-09 312972 192767 AS Summary 33185 Number of ASes in routing system 14122 Number of ASes announcing only one prefix 4367 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92551424 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 18Dec09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 312769 192732 120037 38.4% All ASes AS6389 4187 309 3878 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4367 1948 2419 55.4% TWTC - tw telecom holdings, inc. AS1785 1796 342 1454 81.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1892 585 1307 69.1% KIXS-AS-KR Korea Telecom AS17488 1458 311 1147 78.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1122 71 1051 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1580 677 903 57.2% Uninet S.A. de C.V. AS4755 1280 395 885 69.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1048 234 814 77.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1035 312 723 69.9% TEDATA TEDATA AS18101 994 320 674 67.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 1003 337 666 66.4% TV Cable S.A. AS6478 1111 468 643 57.9% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 444 615 58.1% COVAD - Covad Communications Co. AS4808 787 208 579 73.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1199 629 570 47.5% LEVEL3 Level 3 Communications AS4804 633 70 563 88.9% MPX-AS Microplex PTY LTD AS4134 1016 454 562 55.3% CHINANET-BACKBONE No.31,Jin-rong Street AS7303 665 103 562 84.5% Telecom Argentina S.A. AS24560 813 253 560 68.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1589 1035 554 34.9% ATT-INTERNET4 - AT&T WorldNet Services AS17908 765 241 524 68.5% TCISL Tata Communications AS7545 934 418 516 55.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS11492 1151 654 497 43.2% CABLEONE - CABLE ONE, INC. AS22047 545 50 495 90.8% VTR BANDA ANCHA S.A. AS4780 642 151 491 76.5% SEEDNET Digital United Inc. AS28573 828 366 462 55.8% NET Servicos de Comunicao S.A. AS9443 531 78 453 85.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS9299 662 220 442 66.8% IPG-AS-AP Philippine Long Distance Telephone Company AS35805 471 29 442 93.8% UTG-AS United Telecom AS Total 37163 11712 25451 68.5% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 109.206.0.0/19 AS50319 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 157.234.0.0/16 AS1239 SPRINTLINK - Sprint 157.234.230.0/24 AS1239 SPRINTLINK - Sprint 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 207.174.132.0/23 AS30715 207.174.152.0/22 AS30715 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From johnl at iecc.com Fri Dec 18 22:06:58 2009 From: johnl at iecc.com (John Levine) Date: 18 Dec 2009 22:06:58 -0000 Subject: Chinese bgp metering story In-Reply-To: <202705b0912181243k2e0f4f67h843dd43da14acaa1@mail.gmail.com> Message-ID: <20091218220658.23880.qmail@simone.iecc.com> >And don't be so hard on the ITU folks, the only thing they want to >break is the monopoly of IP address allocation. That's OK with me if they're willing to let the IETF break the monopoly on telephone number allocation. R's, John From egon at egon.cc Fri Dec 18 22:12:05 2009 From: egon at egon.cc (James Downs) Date: Fri, 18 Dec 2009 14:12:05 -0800 Subject: Rackspace outage In-Reply-To: <4B2BFAF5.4020001@sharpone.net> References: <4B2BFAF5.4020001@sharpone.net> Message-ID: <6A6A6CAF-466E-47EF-AC3C-579F4C354DBD@egon.cc> On Dec 18, 2009, at 1:58 PM, Justin T. Sharp wrote: > Rackspace seems to have a severe routing loop, which appears to have > taken a lot of sites down. Does anyone have any information on this? http://status.mosso.com/2009/12/cloud-sites-dfw-investigating-current-issue.html From marka at isc.org Fri Dec 18 23:33:33 2009 From: marka at isc.org (Mark Andrews) Date: Sat, 19 Dec 2009 10:33:33 +1100 Subject: sink.arpa question In-Reply-To: Your message of "Fri, 18 Dec 2009 13:49:06 CDT." <4B2BCEA2.7010402@i6ix.com> References: <1261160720.25842@mule.he.net> <4B2BCEA2.7010402@i6ix.com> Message-ID: <200912182333.nBINXXr3042427@drugs.dv.isc.org> In message <4B2BCEA2.7010402 at i6ix.com>, Jason Bertoch writes: > Ted Hardie wrote: > > > > But I think the key question is actually different. Look at this > > text in RFC 2821: > > > > > > If one or more MX RRs are found for a given > > name, SMTP systems MUST NOT utilize any A RRs associated with that > > name unless they are located using the MX RRs; the "implicit MX" rule > > above applies only if there are no MX records present. If MX records > > are present, but none of them are usable, this situation MUST be > > reported as an error. > > > > If I put in an MX record pointing to a guaranteed non-present > > FQDN, someone complying with that text will throw an error rather than > > keep seeking for an A/AAAA. Is *that* useful? If so, then > > sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. > > > > Yes, I understand the RFC. That section is what allows this topic to be > discussed in the first place. sink.arpa may very well be the interim > solution, too. It definitely looks better than "0 .". It just seems > like an ugly, smelly hack when the fundamental problem lies with > allowing the implicit MX. It implies that I should, for the benefit of > everyone, create a sink.arpa MX for every A record, where the effort > could be better spent dropping the implicit MX rule and requiring an MX > record for hosts that really do accept mail. > > /Jason "MX 0 ." is not useable. "." is not a legal host name. For those MTA's that ignore the legal hostname rule there shouldn't be any address records at "." which also make it unusable. And for those of you worring about DNSSEC costs. NODATA is 1 NSEC/NSEC3 record unless it is from a wildcard where there are some addition records, whereas NXDOMAIN is usually 2 NSEC or 3 NSEC3 records + signatures. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tvest at eyeconomics.com Sat Dec 19 00:17:54 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Fri, 18 Dec 2009 19:17:54 -0500 Subject: Chinese bgp metering story In-Reply-To: <20091218220658.23880.qmail@simone.iecc.com> References: <20091218220658.23880.qmail@simone.iecc.com> Message-ID: Nobody here remembers ICAIS? This is actually an old story/ambition, which started elsewhere, and not long after the the 1997-1998 "rebalancing" of ITU-mediated switched telecom settlements. Two nuggets from the history books pasted in below. Of course, just because it's not new doesn't mean that it's not newsworthy. As I recall, this issue precipitated a fairly titanic behind-the-scenes struggle last time around... TV _____ AAP NEWSFEED July 15, 1999, Thursday Telstra chief calls for equitable Net traffic cost sharing SYDNEY, July 15 AAP - Telstra Corp Ltd chief executive Ziggy Switkowski today called for an equitable arrangement for sharing the cost of carrying Internet traffic to and from the United States.In an address to the Asia-Pacific Economic Cooperation (APEC) business conference here, Dr Switkowski said US operators were currently enjoying an implied subsidy of 30 per cent of the costs of international Internet connection... The charging system operates on a similar principle to that used in international phone charging arrangements, he said. "For Australia alone, that represents approximately $50 million a year, and the sum varies from country to country depending on usage," Dr Switkowski said. "Telstra's view is that the future of e-commerce could be undermined if investment in capacity growth does not match growth in demand. "But infrastructure providers outside the US need to have sufficient confidence in cost sharing to invest in new capacity to meet the exploding demand for bandwidth"... _____ Economist October 19, 1996 Too cheap to meter? The fact that the Internet seems free to many of its users has been one reason for its success. Now it may have to change. But how? ...If the costs of the telephone companies and the Internet are similar, why are their methods of pricing different? The answer is that telecoms charges bear little relation to costs. The telephone industry is regulated nearly everywhere and in most countries prices are set by bureaucrats and commissions; real costs are hidden by a layer of crosssubsidies. The Internet, on the other hand, is essentially unregulated. At present, telephone companies typically make less than half their revenue from fixed charges rather than from the price of each call. Tim Kelly, of the International Telecommunication Union in Geneva, reckons that the share of revenue from connection charges and monthly rentals has risen in the past decade from about 33% to 40%; he expects an increase to around 60% over the next ten years. The companies are not keen on such "rebalancing", since it usually involves reducing lucrative call charges rather than increasing fixed charges. But without it, they are vulnerable to competition, including competition from the Internet, which can offer rival services far less expensively... ...Such settlements are a source of endless argument: America's long- distance carriers complain that local telephone companies overcharge them. Moreover, they transfer huge sums of money between countries: in 1994, carriers based in the United States handed over a net $ 4.3 billion to foreign carriers. Because countries in which telephoning is cheap (such as America) tend to ring countries where calls are dearer, American carriers grumble that they are subsidising the inefficient and uncompetitive. Gradually, therefore, telephone companies are moving towards a "sender-keeps-all" system, where they will charge each other a flat fee for access to a certain amount of transmission capacity, rather than bill each other on the basis of use. That would bring them increasingly into line with what happens on the Internet, where settlement is rudimentary. There are payments between each of the Internet's hierarchy of links: access providers pay their regional network and regional networks pay the companies that operate the high-capacity long-distance parts, the backbone of the system. But such payments are mostly based on the availability of capacity, not its use: service providers simply agree to carry each other's traffic without totting up precise bills. This encourages a "hot-potato" approach: Internet access providers hand traffic on as quickly as possible to the carrier taking it to its ultimate destination. That benefits small service providers and irritates big ones, who say they get little reward for the effort of carrying the traffic for most of its journey. In turn, this lessens their incentive to invest in new capacity. The problem of settlement is worse for access providers outside America. Led by Singapore Telecom and Australia's Telstra, they complain that they have to pay all the cost of leasing lines between their country and the United States. "The rest of the planet subsidises the United States," argues Barry Greene, who works for Cisco, a maker of routers, but was previously with Singnet, the Internet arm of Singapore Telecom. The high cost of leasing international lines means that upgrading them to ease congestion can cost a non-American company ten times more than in America. From rodrick.brown at gmail.com Sat Dec 19 00:46:42 2009 From: rodrick.brown at gmail.com (rodrick brown) Date: Fri, 18 Dec 2009 19:46:42 -0500 Subject: Routing to multiple uplinks Message-ID: This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS. From peter.hicks at poggs.co.uk Sat Dec 19 00:55:18 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Sat, 19 Dec 2009 00:55:18 +0000 Subject: Routing to multiple uplinks In-Reply-To: References: Message-ID: <4B2C2476.8030001@poggs.co.uk> rodrick brown wrote: > This may be slightly off topic however I have a very unique situation > where I need to provide two diverse paths to a major stock exchange. > Each host may either use route A or B for any given reason to access > this particular exchange using two distinct routers and target address. Have you considered point-to-point circuits? > The applicatiOn running on these hosts must only see/use one target > address this needs to be transparent as possible. NIC bonding/teaming on > the host side isn't a viable solution because of the latency overhead > same goes for vrrp/hsrp. What latency do you mean when you talk about NIC bonding and VRRP? Peter From Valdis.Kletnieks at vt.edu Sat Dec 19 01:10:15 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 18 Dec 2009 20:10:15 -0500 Subject: Routing to multiple uplinks In-Reply-To: Your message of "Fri, 18 Dec 2009 19:46:42 EST." References: Message-ID: <6275.1261185015@localhost> On Fri, 18 Dec 2009 19:46:42 EST, rodrick brown said: > The applicatiOn running on these hosts must only see/use one target > address this needs to be transparent as possible. NIC bonding/teaming > on the host side isn't a viable solution because of the latency > overhead same goes for vrrp/hsrp. If you're worried about the latency issues with NIC bonding, what do you intend to do about the speed-of-light latency from Chicago to NYC? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mysidia at gmail.com Sat Dec 19 04:09:32 2009 From: mysidia at gmail.com (James Hess) Date: Fri, 18 Dec 2009 22:09:32 -0600 Subject: Chinese bgp metering story In-Reply-To: <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> Message-ID: <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin wrote: > On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: .. > modified if need be - to achieve this. ?Mixing billing with the reachability > information signalled through BGP just doesn't seem like a good idea. Indeed not.. but it might offer one advantage, if it was mandatory for any such tarrif/cost to be advertised there to be valid, and in the form of an ancillary BGP route attribute, rather than buried in some 500,000 page treaty that forces all ISPs to decipher it and try to figure out what their liabilities are. Mainly because it makes any tarrif very visible, and easily understood. and offers an easy ability to automatically make decisions like discard reachability information that has any billing labels or "strings" attached to it, or has a cost greater than $X per million packets listed for 'source'... and easily allows an ISP to replace the next hop with null when a tarrif option has been listed, or use only a route not subject to tarrif. Thus treating as unroutable or permit routing around any transit that would like to try to taint its routes by indicating tarrif to peers. And thus also permitting the whole notion of 'IP tarrif' to see a very quick death... Otherwise, new router hardware could more easily provide suitable counters and IPFIX data (with suitable changes to ip flow export formats) to track the tarrifs due to all "tarrif payee IDs", or whatever that would be. -- -J From rdobbins at arbor.net Sat Dec 19 04:19:18 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 19 Dec 2009 04:19:18 +0000 Subject: Chinese bgp metering story In-Reply-To: <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> Message-ID: <9C564AEC-732D-47F7-B469-0316159AFEB0@arbor.net> On Dec 19, 2009, at 11:09 AM, James Hess wrote: > Otherwise, new router hardware could more easily provide suitable counters and IPFIX data (with suitable changes to ip flow export formats) to track the tarrifs due to all "tarrif payee IDs", or whatever that would be. Existing hardware does this today with NetFlow, et. al. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From stmagconsulting at gmail.com Sat Dec 19 07:03:51 2009 From: stmagconsulting at gmail.com (Stephane MAGAND) Date: Sat, 19 Dec 2009 08:03:51 +0100 Subject: Ipsec/VRF Mpls ? Message-ID: Hi after a first post with 0 answer (very thanks ..) i test a second post for get a small help. I am search a simple sample of configuration for a cisco 2821 for connect a Ipsec routers ton a MPLS IP VPN Backbone My cisco 2821 have two interface, one connected at my MPLS network and the second at the Internet. I create two vrf, one for a site to site and the second for a Remote User Access anyone have this into a config ? because i never have used Ipsec actually on cisco. The site-to-site router are a C1721, and remote user use cisco IPSEC client and i want a radius authentification (and it's the radius that sent the vrf) thanks for your help Stephane From scott at sberkman.net Sat Dec 19 08:45:21 2009 From: scott at sberkman.net (Scott Berkman) Date: Sat, 19 Dec 2009 03:45:21 -0500 Subject: Routing to multiple uplinks In-Reply-To: References: Message-ID: <001101ca8087$9afc0b70$d0f42250$@net> Anycast? http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=&nm=n anog29 Might need to know a little more about the layout here for a better answer. -Scott -----Original Message----- From: rodrick brown [mailto:rodrick.brown at gmail.com] Sent: Friday, December 18, 2009 7:47 PM To: nanog at nanog.org list Subject: Routing to multiple uplinks This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS. From adrian at creative.net.au Sat Dec 19 09:49:35 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 19 Dec 2009 17:49:35 +0800 Subject: Chinese bgp metering story In-Reply-To: <9C564AEC-732D-47F7-B469-0316159AFEB0@arbor.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> <9C564AEC-732D-47F7-B469-0316159AFEB0@arbor.net> Message-ID: <20091219094935.GA9405@skywalker.creative.net.au> On Sat, Dec 19, 2009, Dobbins, Roland wrote: > Existing hardware does this today with NetFlow, et. al. .. not only that, we've been doing this for a bloody long time in internet years. About all that really matter is figuring out how to engineer your network to allow for netflow based billing without having subtle duplicate flows everywhere.. Adrian (Ah, thinking about this stuff brings back memories, and I'm only 30..) From r.bhatia at ipax.at Sat Dec 19 10:52:35 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Sat, 19 Dec 2009 11:52:35 +0100 Subject: Edge-Core (Accton) switches In-Reply-To: <47B0A0C1ADE1ED4BA114480988FE878F1D1864@dc1.gv-office.local> References: <47B0A0C1ADE1ED4BA114480988FE878F1D1864@dc1.gv-office.local> Message-ID: <4B2CB073.3050805@ipax.at> On 02.12.2009 19:12, Todd Mueller wrote: > Anyone have any experience using Edge-Core switches (or Accton, > Edge-Core is a subsidiary)? Good/bad? Pricing/features seem good, but > you often get what you pay for . . . we have a couple of Foundry Networks EdgeIron 4802CF, which should be similar to accton's ES3550C [1]. we have a hand full of vlans (10-20) configured and use them as a top-of-the-rack (?) switch to connect our customer's servers. the gbit uplink(s) are connected to our core equipment. on our experience, the do no good job at handling too much load. depending on the firmware, the management cpu will become too loaded and you'll have troubles accessing the switch via ssh or you'll see snmp issues. however, i haven't seen any real issues with switching performance. cheers raoul [1] http://www.accton.com/products/product_range/01_l2fes/es3550c.htm -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From pl+list at pmacct.net Sat Dec 19 11:27:10 2009 From: pl+list at pmacct.net (Paolo Lucente) Date: Sat, 19 Dec 2009 11:27:10 +0000 Subject: Chinese bgp metering story In-Reply-To: <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> Message-ID: <20091219112710.GA6917@moussaka.pmacct.net> On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote: > On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin wrote: > .. > > modified if need be - to achieve this. ?Mixing billing with the reachability > > information signalled through BGP just doesn't seem like a good idea. > > Indeed not.. but it might offer one advantage, if it was mandatory > for any such tarrif/cost to be advertised there to be valid, and in > the form of an ancillary BGP route attribute, rather than buried in > some 500,000 page treaty that forces all ISPs to decipher it and > try to figure out what their liabilities are. > > Mainly because it makes any tarrif very visible, and easily understood. > and offers an easy ability to automatically make decisions like > discard reachability information that has any billing labels or > "strings" attached to it, or has a cost greater than $X per million > packets listed for 'source'... and easily allows an ISP to replace > the next hop with null when a tarrif option has been listed, or use > only a route not subject to tarrif. I concur. Such visibility is efficient and drives simplification and automation from a data mining perspective, when analyzing accounting information. In such context, some care is required. Reachability information is destination based. Mixing accounting (ie. NetFlow) and reachability (ie. BGP) information is of good value for traffic delivered out of a routing domain but not for traffic received, ie. reverse reachability lookups can be a way although they are not truly deterministic due to routing asymmetries; a mix of ingress measurements, lookup maps and an export protocol supporting L2 information (ie. for same interface, multiple peers scenarios) give way a better chance to resolve which neighboring party is pulling which traffic into the observed domain. Cheers, Paolo From randy at psg.com Sat Dec 19 11:42:33 2009 From: randy at psg.com (Randy Bush) Date: Sat, 19 Dec 2009 20:42:33 +0900 Subject: Chinese bgp metering story In-Reply-To: <20091219112710.GA6917@moussaka.pmacct.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> <20091219112710.GA6917@moussaka.pmacct.net> Message-ID: i am truely in awe how deeply the implications and alternatives have been analysed. this is particularly impressive given the complete absense of any facts about the alleged proposal. randy From rdobbins at arbor.net Sat Dec 19 11:57:07 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 19 Dec 2009 11:57:07 +0000 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> <20091219112710.GA6917@moussaka.pmacct.net> Message-ID: <3FE4E0CE-7985-4704-9EA1-AF60E3B83310@arbor.net> On Dec 19, 2009, at 6:42 PM, Randy Bush wrote: > this is particularly impressive given the complete absense of any facts about the alleged proposal. I think the whole brouhaha is the merely result of someone saying 'BGP-speaking routers' vs. saying 'peering/transit edge routers', combined with the notion of somehow cartelizing this on a national basis vs. the current individual network-to-network private/public basis. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From pl+list at pmacct.net Sat Dec 19 12:17:37 2009 From: pl+list at pmacct.net (Paolo Lucente) Date: Sat, 19 Dec 2009 12:17:37 +0000 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> <20091219112710.GA6917@moussaka.pmacct.net> Message-ID: <20091219121737.GA7029@moussaka.pmacct.net> On Sat, Dec 19, 2009 at 08:42:33PM +0900, Randy Bush wrote: > i am truely in awe how deeply the implications and alternatives have > been analysed. this is particularly impressive given the complete > absense of any facts about the alleged proposal. Part of the thread just went more of general discussion about mixing accounting/reachability information despite the original subject label was retained. Cheers, Paolo From joelja at bogus.com Sat Dec 19 18:06:27 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 19 Dec 2009 10:06:27 -0800 Subject: Chinese bgp metering story In-Reply-To: <20091219112710.GA6917@moussaka.pmacct.net> References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> <20091219112710.GA6917@moussaka.pmacct.net> Message-ID: <4B2D1623.9030801@bogus.com> Paolo Lucente wrote: > On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote: >> On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin wrote: >> .. >>> modified if need be - to achieve this. ?Mixing billing with the reachability >>> information signalled through BGP just doesn't seem like a good idea. >> Indeed not.. but it might offer one advantage, if it was mandatory >> for any such tarrif/cost to be advertised there to be valid, and in >> the form of an ancillary BGP route attribute, rather than buried in >> some 500,000 page treaty that forces all ISPs to decipher it and >> try to figure out what their liabilities are. >> >> Mainly because it makes any tarrif very visible, and easily understood. >> and offers an easy ability to automatically make decisions like >> discard reachability information that has any billing labels or >> "strings" attached to it, or has a cost greater than $X per million >> packets listed for 'source'... and easily allows an ISP to replace >> the next hop with null when a tarrif option has been listed, or use >> only a route not subject to tarrif. > > I concur. Such visibility is efficient and drives simplification and > automation from a data mining perspective, when analyzing accounting > information. > > In such context, some care is required. Reachability information is > destination based. Mixing accounting (ie. NetFlow) and reachability > (ie. BGP) information is of good value for traffic delivered out of > a routing domain but not for traffic received, ie. reverse reachability > lookups can be a way although they are not truly deterministic due to > routing asymmetries; deliberate tunning for purposes of TE, use of default. will all contribute to ingress path not resembling egress... > a mix of ingress measurements, lookup maps and > an export protocol supporting L2 information (ie. for same interface, > multiple peers scenarios) give way a better chance to resolve which > neighboring party is pulling which traffic into the observed domain. > > Cheers, > Paolo > > From sking at kingrst.com Sat Dec 19 18:17:14 2009 From: sking at kingrst.com (Steven King) Date: Sat, 19 Dec 2009 13:17:14 -0500 Subject: Routing to multiple uplinks In-Reply-To: <001101ca8087$9afc0b70$d0f42250$@net> References: <001101ca8087$9afc0b70$d0f42250$@net> Message-ID: <4B2D18AA.40209@kingrst.com> Maybe I am missing something, but how does VRRP/HSRP cause latency? On 12/19/09 3:45 AM, Scott Berkman wrote: > Anycast? > http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=&nm=n > anog29 > > Might need to know a little more about the layout here for a better answer. > > -Scott > > -----Original Message----- > From: rodrick brown [mailto:rodrick.brown at gmail.com] > Sent: Friday, December 18, 2009 7:47 PM > To: nanog at nanog.org list > Subject: Routing to multiple uplinks > > This may be slightly off topic however I have a very unique situation > where I need to provide two diverse paths to a major stock exchange. > Each host may either use route A or B for any given reason to access > this particular exchange using two distinct routers and target address. > > The applicatiOn running on these hosts must only see/use one target > address this needs to be transparent as possible. NIC bonding/teaming > on the host side isn't a viable solution because of the latency > overhead same goes for vrrp/hsrp. > > I believe my only option here is to setup multiple default routes with > a preferred path of some sort. This seems to be possible using ip > route2 on Linux. > > This just seems wrong on many levels and I thought I would post here > because I know there is something obvious I'm missing. > Please clue me in. > > Thanks. > > Sent from my iPhone 3GS. > > > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From rodrick.brown at gmail.com Sat Dec 19 19:48:12 2009 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Sat, 19 Dec 2009 14:48:12 -0500 Subject: Routing to multiple uplinks In-Reply-To: <4B2D18AA.40209@kingrst.com> References: <001101ca8087$9afc0b70$d0f42250$@net> <4B2D18AA.40209@kingrst.com> Message-ID: VRRP/HSRP does not cause latency the problem we faced prior was when links flapped or timed out this would be too much of a hindrance for our users to reconcile application state with various trading venues we are trading thousands upon thousands of trades a minute to various destinations. As stated before Path A and Path B are two distinct paths they do however provide identical services but application state is not preserved. A new session and state must be established if a user decides to switch between paths. Essentially we provide the ability for users either shutdown and start sending orders to Path A or Path B based on latency from our servers to these trading venues we're actively monitoring latency between both end points. The overall design is being driven by our rigorous application needs more than anything. The implementation is straight forward we receive a duplicate set of feeds from site A and site B and can also access various services coming from site A or site B however, at any given time a user will be sending/recieving data from one of those destinations. Never both simultaneously. So my question what is the best way to provide this type of redundancy at the host level? The application will only use one target address. On Sat, Dec 19, 2009 at 1:17 PM, Steven King wrote: > Maybe I am missing something, but how does VRRP/HSRP cause latency? > > On 12/19/09 3:45 AM, Scott Berkman wrote: > > Anycast? > > > http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=&nm=n > > anog29 > > > > Might need to know a little more about the layout here for a better > answer. > > > > -Scott > > > > -----Original Message----- > > From: rodrick brown [mailto:rodrick.brown at gmail.com] > > Sent: Friday, December 18, 2009 7:47 PM > > To: nanog at nanog.org list > > Subject: Routing to multiple uplinks > > > > This may be slightly off topic however I have a very unique situation > > where I need to provide two diverse paths to a major stock exchange. > > Each host may either use route A or B for any given reason to access > > this particular exchange using two distinct routers and target address. > > > > The applicatiOn running on these hosts must only see/use one target > > address this needs to be transparent as possible. NIC bonding/teaming > > on the host side isn't a viable solution because of the latency > > overhead same goes for vrrp/hsrp. > > > > I believe my only option here is to setup multiple default routes with > > a preferred path of some sort. This seems to be possible using ip > > route2 on Linux. > > > > This just seems wrong on many levels and I thought I would post here > > because I know there is something obvious I'm missing. > > Please clue me in. > > > > Thanks. > > > > Sent from my iPhone 3GS. > > > > > > > > > > -- > Steve King > > Network Engineer - Liquid Web, Inc. > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional > > > -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown From sking at kingrst.com Sat Dec 19 20:20:03 2009 From: sking at kingrst.com (Steven King) Date: Sat, 19 Dec 2009 15:20:03 -0500 Subject: Routing to multiple uplinks In-Reply-To: References: <001101ca8087$9afc0b70$d0f42250$@net> <4B2D18AA.40209@kingrst.com> Message-ID: <4B2D3573.4000002@kingrst.com> HSRP/VRRP can be tweaked to less than 1s fail over time. Can you provide a copy of your network map for analysis? GLBP might be a viable option as fail over is not actually an issue at that point. On 12/19/09 2:48 PM, Rodrick Brown wrote: > VRRP/HSRP does not cause latency the problem we faced prior was when > links flapped or timed out this would be too much of a hindrance for > our users to reconcile application state with various trading venues > we are trading thousands upon thousands of trades a minute to various > destinations. > > As stated before Path A and Path B are two distinct paths they do > however provide identical services but application state is not > preserved. A new session and state must be established if a user > decides to switch between paths. > > Essentially we provide the ability for users either shutdown and start > sending orders to Path A or Path B based on latency from our servers > to these trading venues we're actively monitoring latency between both > end points. > > The overall design is being driven by our rigorous application needs > more than anything. > > The implementation is straight forward we receive a duplicate set of > feeds from site A and site B and can also access various services > coming from site A or site B however, at any given time a user will be > sending/recieving data from one of those destinations. Never both > simultaneously. So my question what is the best way to provide this > type of redundancy at the host level? > > The application will only use one target address. > > On Sat, Dec 19, 2009 at 1:17 PM, Steven King > wrote: > > Maybe I am missing something, but how does VRRP/HSRP cause latency? > > On 12/19/09 3:45 AM, Scott Berkman wrote: > > Anycast? > > > http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=&nm=n > > > anog29 > > > > Might need to know a little more about the layout here for a > better answer. > > > > -Scott > > > > -----Original Message----- > > From: rodrick brown [mailto:rodrick.brown at gmail.com > ] > > Sent: Friday, December 18, 2009 7:47 PM > > To: nanog at nanog.org list > > Subject: Routing to multiple uplinks > > > > This may be slightly off topic however I have a very unique > situation > > where I need to provide two diverse paths to a major stock exchange. > > Each host may either use route A or B for any given reason to access > > this particular exchange using two distinct routers and target > address. > > > > The applicatiOn running on these hosts must only see/use one target > > address this needs to be transparent as possible. NIC > bonding/teaming > > on the host side isn't a viable solution because of the latency > > overhead same goes for vrrp/hsrp. > > > > I believe my only option here is to setup multiple default > routes with > > a preferred path of some sort. This seems to be possible using ip > > route2 on Linux. > > > > This just seems wrong on many levels and I thought I would post here > > because I know there is something obvious I'm missing. > > Please clue me in. > > > > Thanks. > > > > Sent from my iPhone 3GS. > > > > > > > > > > -- > Steve King > > Network Engineer - Liquid Web, Inc. > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional > > > > > > -- > [ Rodrick R. Brown ] > http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From deepak at ai.net Sun Dec 20 13:00:15 2009 From: deepak at ai.net (Deepak Jain) Date: Sun, 20 Dec 2009 08:00:15 -0500 Subject: Routing to multiple uplinks In-Reply-To: References: <001101ca8087$9afc0b70$d0f42250$@net> <4B2D18AA.40209@kingrst.com> Message-ID: > The overall design is being driven by our rigorous application needs > more > than anything. > > The implementation is straight forward we receive a duplicate set of > feeds > from site A and site B and can also access various services coming from > site > A or site B however, at any given time a user will be sending/recieving > data > from one of those destinations. Never both simultaneously. So my > question > what is the best way to provide this type of redundancy at the host > level? > > The application will only use one target address. > You've stated two seemingly contradictory things. 1) The User decides which paths to take yet the 2) application cannot see more than one path. First, this sounds like a User issue. The application with such rigorous requirements should have the features you need to manage this. Barring that... :) The mechanism the User uses to (manually) decide which path to take should make the election and handle the switchover in visibility. Presumably, since your application cannot tell when its switched destinations/paths it needs to be notified if the network makes a VRRP/HSRP decision. This all points to the mechanism you presumably already have in place for manual path decisions. If you are using your Linux box or whatever to make your path choices, simply have a script that sees if the path preferences have changed and use your method to notify the Application. If you are using a Cisco (or other) dedicated router, run something on the Application box or servers that will notice this change (if even by querying the router) so it can proactively detect this. You've asked for a technical suggestion but have not provided any detail about the actual constraints you have -- though you've implied them without context. Deepak Jain AiNET From ip at ioshints.info Sun Dec 20 13:05:11 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sun, 20 Dec 2009 14:05:11 +0100 Subject: Routing to multiple uplinks In-Reply-To: References: <001101ca8087$9afc0b70$d0f42250$@net> <4B2D18AA.40209@kingrst.com> Message-ID: <001901ca8175$11380080$33a80180$@info> Am I right in assuming that you're establishing application-layer sessions to two hosts with two different IP addresses (outside of your control) which provide (close to) identical services? If so, there's not much you can do outside of the application itself (at least if you want a semi-robust solution). You could try (reverse) load balancer, but even then the application session would have to be disconnected before being switched over to the other host. > As stated before Path A and Path B are two distinct paths they do however > provide identical services but application state is not preserved. A new > session and state must be established if a user decides to switch between > paths. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info From leigh.porter at ukbroadband.com Sun Dec 20 14:07:17 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 20 Dec 2009 14:07:17 -0000 Subject: Chinese bgp metering story References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com><467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu><3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com><3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net><6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com><20091219112710.GA6917@moussaka.pmacct.net> Message-ID: However, if they are after some consultancy time to write some useless documents then I will happily take their money. -- Leigh Porter -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Sat 12/19/2009 11:42 AM To: North American Network Operators Group Subject: Re: Chinese bgp metering story i am truely in awe how deeply the implications and alternatives have been analysed. this is particularly impressive given the complete absense of any facts about the alleged proposal. randy From dot at dotat.at Sun Dec 20 15:26:16 2009 From: dot at dotat.at (Tony Finch) Date: Sun, 20 Dec 2009 15:26:16 +0000 Subject: sink.arpa question In-Reply-To: <4B2BC569.2070602@i6ix.com> References: <1261091772.17216@mule.he.net> <4B2BA9EA.5080504@i6ix.com> <4B2BC569.2070602@i6ix.com> Message-ID: On Fri, 18 Dec 2009, Jason Bertoch wrote: > > Do metrics exist on how many current installs still rely on the implicit > MX? It's very common for email from web servers to be poorly configured such that it uses the webserver's hostname as the return path's mail domain. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From jgreco at ns.sol.net Sun Dec 20 17:05:15 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 20 Dec 2009 11:05:15 -0600 (CST) Subject: sink.arpa question In-Reply-To: from "Tony Finch" at Dec 20, 2009 03:26:16 PM Message-ID: <200912201705.nBKH5FN1058928@aurora.sol.net> > On Fri, 18 Dec 2009, Jason Bertoch wrote: > > Do metrics exist on how many current installs still rely on the implicit > > MX? > > It's very common for email from web servers to be poorly configured such > that it uses the webserver's hostname as the return path's mail domain. It is very difficult to measure how many current installs rely on the implicit MX, as someone else noted. On a somewhat different angle of attack: Even five years ago, it was considered mildly problematic to deploy a hostname where the A pointed someplace incapable of receiving mail, since some "products" (you know who you are) were so poorly written and still in use that they would connect to the A (or "implicit MX" if you prefer) even in the presence of MX records. Now that another five years have passed, it would be interesting to see how many antiques are still sending e-mail AND are worth talking to. I'm guessing not many. That suggests that it might well be fine to point A at something that is not capable of receiving SMTP, as long as you have MX records. An arrangement that should always have been practical, of course. Is anyone actually doing this? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mohitlad at gmail.com Sun Dec 20 17:12:03 2009 From: mohitlad at gmail.com (Mohit Lad) Date: Sun, 20 Dec 2009 22:42:03 +0530 Subject: Tools BOF at NANOG-48 Message-ID: Dear all, I am planning on organizing the Network Tools BOF at NANOG-48 with the objective of presenting interesting and useful non-commercial tools that have a fairly widespread appeal. Tool owners would make short presentations and show usefulness of the tool with case studies. If you have developed or know of a tool/package that you would like to include, please send me an email directly. As part of the tools BOF, I also plan to run a short 15-20 min "Tools roundup" outlining the most common non-commercial tools used for day to day networking tasks. The objective of this is not to present details of tools, but rather a rough taxonomy. Feel free to suggest tools you find useful. Thanks -Mohit From randy at psg.com Sun Dec 20 21:24:12 2009 From: randy at psg.com (Randy Bush) Date: Mon, 21 Dec 2009 06:24:12 +0900 Subject: Chinese bgp metering story In-Reply-To: References: <313b48d0912181019s137c70b3w16726192daafa794@mail.gmail.com> <467CC052-0B84-4C76-AF91-57A934EB50D3@cs.columbia.edu> <3B15EFF7-795B-4FF9-9D43-8F522F66E6C0@cisco.com> <3D5304EB-5A64-4D0E-83BB-332F8B5FE903@pch.net> <6eb799ab0912182009i683dc303v9ded81b2702a178d@mail.gmail.com> <20091219112710.GA6917@moussaka.pmacct.net> Message-ID: > However, if they are after some consultancy time to write some useless > documents then I will happily take their money. i suspect their intelligence is far greater then your arrogance randy From pete.barnwell at whole.net.uk Sun Dec 20 22:14:32 2009 From: pete.barnwell at whole.net.uk (Pete Barnwell) Date: Sun, 20 Dec 2009 22:14:32 +0000 Subject: sink.arpa question In-Reply-To: <200912201705.nBKH5FN1058928@aurora.sol.net> References: <200912201705.nBKH5FN1058928@aurora.sol.net> Message-ID: <4B2EA1C8.5050207@whole.net.uk> Joe Greco wrote: >> On Fri, 18 Dec 2009, Jason Bertoch wrote: >> >>> Do metrics exist on how many current installs still rely on the implicit >>> MX? >>> >> It's very common for email from web servers to be poorly configured such >> that it uses the webserver's hostname as the return path's mail domain. >> > > It is very difficult to measure how many current installs rely on the > implicit MX, as someone else noted. > > On a somewhat different angle of attack: > > Even five years ago, it was considered mildly problematic to deploy a > hostname where the A pointed someplace incapable of receiving mail, > since some "products" (you know who you are) were so poorly written > and still in use that they would connect to the A (or "implicit MX" > if you prefer) even in the presence of MX records. > > Now that another five years have passed, it would be interesting to > see how many antiques are still sending e-mail AND are worth talking > to. I'm guessing not many. > > That suggests that it might well be fine to point A at something that > is not capable of receiving SMTP, as long as you have MX records. An > arrangement that should always have been practical, of course. > > Is anyone actually doing this? > > ... JG > I'd think this more than common - the A record for the domain quite often is set to point to the same IP as the www. A record where that server isn't running an smtp service. We've certainly got clients who do this, and haven't ever reported it causing problems = one example :- banquo>host -t A www.thehut.com www.thehut.com has address 89.234.46.152 banquo>host -t A thehut.com thehut.com has address 89.234.46.152 banquo>host -t MX thehut.com thehut.com mail is handled by 3 mail.thehutgroup.com. banquo>host -t A mail.thehutgroup.com. mail.thehutgroup.com has address 217.158.230.4 Regards Pete From keith at kouzmanoff.com Mon Dec 21 19:22:08 2009 From: keith at kouzmanoff.com (keith kouzmanoff) Date: Mon, 21 Dec 2009 13:22:08 -0600 Subject: wifi hotspot software needed Message-ID: <4B2FCAE0.5070307@kouzmanoff.com> I am consulting with a new player in the internet field and I am looking for suggestions for hotspot wifi software. GPL would be great, but I know some of the stuff out doesn't have all the features. http://www.antamedia.com/ looks pretty solid and has an oem feature, anybody else us this? We will wanting to set up about 10 different hotspots in a small downtown area and we want to give away the service for free. Doesn't everybody expect that already? I'll want to also be able to manage some rotating-commercialized popups/popunders or log in advertisements to offset the costs. As well as some traffic shaping / blocking some common high bandwidth usage sites / or times of the day / for the neighbors who live in the area too. Maybe some one has done this before? If you have any suggestions, please feel free to contact me off list. keith at kouzmanoff dot com thanks! From michael.holstein at csuohio.edu Mon Dec 21 19:58:35 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 21 Dec 2009 14:58:35 -0500 Subject: wifi hotspot software needed In-Reply-To: <4B2FCAE0.5070307@kouzmanoff.com> References: <4B2FCAE0.5070307@kouzmanoff.com> Message-ID: <4B2FD36B.9000105@csuohio.edu> > I am consulting with a new player in the internet field and I am > looking for suggestions for hotspot wifi software. > > GPL would be great, but I know some of the stuff out doesn't have all > the features. DD-WRT can do this on a variety of hardware. If you use it on higher end gear (meaning not a Linksys wrt54gl) you have to buy a license, but it's pretty cheap. They use Chillispot as the underlying "captive portal". Play with it on a $50 WRT54GL and see if it meets your needs. The developers will also do custom coding and branding if you toss a reasonable fee their way. Regards, Michael Holstein Cleveland State University From mike.lyon at gmail.com Mon Dec 21 20:16:50 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 21 Dec 2009 12:16:50 -0800 Subject: wifi hotspot software needed In-Reply-To: <4B2FD36B.9000105@csuohio.edu> References: <4B2FCAE0.5070307@kouzmanoff.com> <4B2FD36B.9000105@csuohio.edu> Message-ID: <1b5c1c150912211216m26bc67a3sf579d67d619012d8@mail.gmail.com> Check out Mikrotik: http://www.mikrotik.com/ -Mike On Mon, Dec 21, 2009 at 11:58 AM, Michael Holstein < michael.holstein at csuohio.edu> wrote: > > > I am consulting with a new player in the internet field and I am > > looking for suggestions for hotspot wifi software. > > > > GPL would be great, but I know some of the stuff out doesn't have all > > the features. > > > DD-WRT can do this on a variety of hardware. If you use it on higher end > gear (meaning not a Linksys wrt54gl) you have to buy a license, but it's > pretty cheap. They use Chillispot as the underlying "captive portal". > > Play with it on a $50 WRT54GL and see if it meets your needs. > > The developers will also do custom coding and branding if you toss a > reasonable fee their way. > > Regards, > > Michael Holstein > Cleveland State University > > From joelja at bogus.com Mon Dec 21 20:16:01 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 21 Dec 2009 12:16:01 -0800 Subject: wifi hotspot software needed In-Reply-To: <4B2FD36B.9000105@csuohio.edu> References: <4B2FCAE0.5070307@kouzmanoff.com> <4B2FD36B.9000105@csuohio.edu> Message-ID: <4B2FD781.1030500@bogus.com> so can open-wrt and you can run it on something like: http://www.ubnt.com/products/rspro.php which is a lot more flexible than a consumer ap and the price starts at about $80 before you add radios. Michael Holstein wrote: >> I am consulting with a new player in the internet field and I am >> looking for suggestions for hotspot wifi software. >> >> GPL would be great, but I know some of the stuff out doesn't have all >> the features. > > > DD-WRT can do this on a variety of hardware. If you use it on higher end > gear (meaning not a Linksys wrt54gl) you have to buy a license, but it's > pretty cheap. They use Chillispot as the underlying "captive portal". > > Play with it on a $50 WRT54GL and see if it meets your needs. > > The developers will also do custom coding and branding if you toss a > reasonable fee their way. > > Regards, > > Michael Holstein > Cleveland State University > From jmamodio at gmail.com Mon Dec 21 20:24:32 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 21 Dec 2009 14:24:32 -0600 Subject: news from Google In-Reply-To: <200912141313.nBEDDt6n065490@aurora.sol.net> References: <200912141313.nBEDDt6n065490@aurora.sol.net> Message-ID: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Another one from the "Evil Doer" http://www.google.com/advertising/holiday2009/ Wish the guys from Redmond and others copy this action too ... Cheers Jorge From math at sizone.org Mon Dec 21 20:32:35 2009 From: math at sizone.org (Ken Chase) Date: Mon, 21 Dec 2009 15:32:35 -0500 Subject: news from Google In-Reply-To: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: <20091221203234.GL29757@sizone.org> Why would they do that and advertise the fact? Advertising the fact generates the possible interpretation that they were pursuing other goals other than pure altrusim. Marketing comes in many shapes and forms. CSR is a big deal these days any Im sure there are many pros at it at google now too. /kc On Mon, Dec 21, 2009 at 02:24:32PM -0600, Jorge Amodio's said: >Another one from the "Evil Doer" > >http://www.google.com/advertising/holiday2009/ > >Wish the guys from Redmond and others copy this action too ... > >Cheers >Jorge -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From corey at travioli.com Mon Dec 21 20:34:25 2009 From: corey at travioli.com (Corey Travioli) Date: Mon, 21 Dec 2009 14:34:25 -0600 Subject: news from Google In-Reply-To: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: <9DD9759A8EF14056A57FD43A4941BCE0@evo> > Another one from the "Evil Doer" > > http://www.google.com/advertising/holiday2009/ > > Wish the guys from Redmond and others copy this action too ... > > Cheers > Jorge > So what they are saying is because we as individuals are too cheep to give to charity they are giving in our stead to shame us. Yup, that is evil. Shamed From patrick at ianai.net Mon Dec 21 21:28:10 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 21 Dec 2009 16:28:10 -0500 Subject: news from Google In-Reply-To: <9DD9759A8EF14056A57FD43A4941BCE0@evo> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <9DD9759A8EF14056A57FD43A4941BCE0@evo> Message-ID: On Dec 21, 2009, at 3:34 PM, Corey Travioli wrote: >> Another one from the "Evil Doer" >> http://www.google.com/advertising/holiday2009/ >> Wish the guys from Redmond and others copy this action too ... > So what they are saying is because we as individuals are too cheep > to give to charity they are giving in our stead to shame us. Yup, that is > evil. I know it's off-topic, but I'm impressed with the idea that a public corporation can spend 8 figures on something that has essentially $0 ROI and multiple people here can find bad things about it. I'm shocked someone didn't say "but that's only 0.0000$WHATEVER percent of their profit!". Google does many things which can be argued as evil, or not, but I would say this is very much not one of them. -- TTFN, patrick From jmamodio at gmail.com Mon Dec 21 21:47:38 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 21 Dec 2009 15:47:38 -0600 Subject: news from Google In-Reply-To: References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <9DD9759A8EF14056A57FD43A4941BCE0@evo> Message-ID: <202705b0912211347m76cb494fhe7793f9269f74e3e@mail.gmail.com> > I know it's off-topic, but I'm impressed with the idea that a public corporation can spend 8 figures on something that has essentially $0 ROI and multiple people here can find bad things about it. > > I'm shocked someone didn't say "but that's only 0.0000$WHATEVER percent of their profit!". > > Google does many things which can be argued as evil, or not, but I would say this is very much not one of them. Indeed !! BTW, my reference to "Evil" was a sarcasm in relation to those who constantly need to label a company like Google as such, I don't even find Microsoft to be "Evil". Well they have been trying that for many years :-) ... Also for clarification, I didn't find that piece of information from Google on their home page or any reference from a visible site, I don't believe they are doing it just to generate some noise or PR. I just received a message from them for being their user saying: "Hello, As we near the end of the year, we wanted to take a moment to thank you for the time, energy, commitment, and trust you've shared with us in 2009. With sharing in mind, this year we've decided to do something a little different. We hope you'll find it fits the spirit of the holiday season. We're looking forward to working with you to build lasting success in 2010. Happy Holidays, Your Google Team" The link to that page was embedded in the "something a little different" text. To be frank, for all the years I've been suffering with MS-DOS, and the many versions of Windoze, I never/ever received a message from Microsoft thanking me for being their user/customer ... Cheers Jorge From math at sizone.org Mon Dec 21 21:48:25 2009 From: math at sizone.org (Ken Chase) Date: Mon, 21 Dec 2009 16:48:25 -0500 Subject: news from Google In-Reply-To: References: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <9DD9759A8EF14056A57FD43A4941BCE0@evo> Message-ID: <20091221214825.GQ29757@sizone.org> CSR isnt $0 ROI. Unless they're doing it wrong. Which they aren't. You're not paid by them and you're arguing FOR them. Well played, Google. /kc On Mon, Dec 21, 2009 at 04:28:10PM -0500, Patrick W. Gilmore's said: >On Dec 21, 2009, at 3:34 PM, Corey Travioli wrote: > >>> Another one from the "Evil Doer" >>> http://www.google.com/advertising/holiday2009/ >>> Wish the guys from Redmond and others copy this action too ... > >> So what they are saying is because we as individuals are too cheep >> to give to charity they are giving in our stead to shame us. Yup, that is >> evil. > >I know it's off-topic, but I'm impressed with the idea that a public corporation can spend 8 figures on something that has essentially $0 ROI and multiple people here can find bad things about it. > >I'm shocked someone didn't say "but that's only 0.0000$WHATEVER percent of their profit!". > >Google does many things which can be argued as evil, or not, but I would say this is very much not one of them. > >-- >TTFN, >patrick > -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From patrick at ianai.net Mon Dec 21 22:18:44 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 21 Dec 2009 17:18:44 -0500 Subject: news from Google In-Reply-To: <20091221214825.GQ29757@sizone.org> References: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <9DD9759A8EF14056A57FD43A4941BCE0@evo> <20091221214825.GQ29757@sizone.org> Message-ID: <1D4EDB7E-4BF4-426F-8DFA-8E113DD131D7@ianai.net> On Dec 21, 2009, at 4:48 PM, Ken Chase wrote: > CSR isnt $0 ROI. Unless they're doing it wrong. I said essentially. If you think they're making even 1% of $20M, one of us confused. I'll admit I do not do marketing, so maybe it's me. > Which they aren't. You're not paid by them and you're arguing FOR them. > > Well played, Google. No, I'm arguing against people who think this is evil are being silly. Including you. Sometimes donating money to charity is just donating money to charity. I really don't see Google getting more business because I posted to NANOG. Are you honestly arguing otherwise? I guess we should get upset at them if they take a tax write off too? -- TTFN, patrick > On Mon, Dec 21, 2009 at 04:28:10PM -0500, Patrick W. Gilmore's said: >> On Dec 21, 2009, at 3:34 PM, Corey Travioli wrote: >> >>>> Another one from the "Evil Doer" >>>> http://www.google.com/advertising/holiday2009/ >>>> Wish the guys from Redmond and others copy this action too ... >> >>> So what they are saying is because we as individuals are too cheep >>> to give to charity they are giving in our stead to shame us. Yup, that is >>> evil. >> >> I know it's off-topic, but I'm impressed with the idea that a public corporation can spend 8 figures on something that has essentially $0 ROI and multiple people here can find bad things about it. >> >> I'm shocked someone didn't say "but that's only 0.0000$WHATEVER percent of their profit!". >> >> Google does many things which can be argued as evil, or not, but I would say this is very much not one of them. >> >> -- >> TTFN, >> patrick >> > > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. > From mpetach at netflight.com Mon Dec 21 22:31:25 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 21 Dec 2009 14:31:25 -0800 Subject: news from Google In-Reply-To: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: <63ac96a50912211431p3844e1dbrabee7aea9471611c@mail.gmail.com> On Mon, Dec 21, 2009 at 12:24 PM, Jorge Amodio wrote: > Another one from the "Evil Doer" > > http://www.google.com/advertising/holiday2009/ > > Wish the guys from Redmond and others copy this action too ... > > Cheers > Jorge Other companies also do provide millions to charity each year: http://ycorpblog.com/?fr=yscpb&mobvs=1&s=YEF&x=0&y=0&mobid=U0ROzK69GDJdQAADgp6BU Some companies are better at marketing that fact than others. I happen to work for a company that seems particularly dysfunctional when it comes to trying to let people know that it's done something useful or good. ^_^; Matt From scott at doc.net.au Mon Dec 21 22:40:38 2009 From: scott at doc.net.au (Scott Howard) Date: Mon, 21 Dec 2009 14:40:38 -0800 Subject: news from Google In-Reply-To: <1D4EDB7E-4BF4-426F-8DFA-8E113DD131D7@ianai.net> References: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <9DD9759A8EF14056A57FD43A4941BCE0@evo> <20091221214825.GQ29757@sizone.org> <1D4EDB7E-4BF4-426F-8DFA-8E113DD131D7@ianai.net> Message-ID: On Mon, Dec 21, 2009 at 2:18 PM, Patrick W. Gilmore wrote: > > CSR isnt $0 ROI. Unless they're doing it wrong. > > I said essentially. If you think they're making even 1% of $20M, one of us > confused. I'll admit I do not do marketing, so maybe it's me. > The tax write-off alone is going to be significantly more than 1%... Scott From bclark at spectraaccess.com Mon Dec 21 22:44:16 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 21 Dec 2009 17:44:16 -0500 Subject: news from Google In-Reply-To: References: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <9DD9759A8EF14056A57FD43A4941BCE0@evo> <20091221214825.GQ29757@sizone.org> <1D4EDB7E-4BF4-426F-8DFA-8E113DD131D7@ianai.net> Message-ID: <4B2FFA40.3050908@spectraaccess.com> Scott Howard wrote: > On Mon, Dec 21, 2009 at 2:18 PM, Patrick W. Gilmore wrote: > > >>> CSR isnt $0 ROI. Unless they're doing it wrong. >>> >> I said essentially. If you think they're making even 1% of $20M, one of us >> confused. I'll admit I do not do marketing, so maybe it's me. >> >> > > The tax write-off alone is going to be significantly more than 1%... > > Scott > Bingo! We have a winner. Having been a executive at several "for profit" large companies in the past, at the end of the day anything that we did for charity was always justified by the "what do we get out of it?" question. If we couldn't answer that question we moved on to the next charity. Bret From dot at dotat.at Mon Dec 21 22:50:27 2009 From: dot at dotat.at (Tony Finch) Date: Mon, 21 Dec 2009 22:50:27 +0000 Subject: sink.arpa question In-Reply-To: <200912201705.nBKH5FN1058928@aurora.sol.net> References: <200912201705.nBKH5FN1058928@aurora.sol.net> Message-ID: On Sun, 20 Dec 2009, Joe Greco wrote: > > It is very difficult to measure how many current installs rely on the > implicit MX, as someone else noted. > > On a somewhat different angle of attack: [...] > > That suggests that it might well be fine to point A at something that > is not capable of receiving SMTP, as long as you have MX records. An > arrangement that should always have been practical, of course. > > Is anyone actually doing this? I can't quite answer your question yet, but here are some related numbers. I analysed the mail domains used in envelope return paths of 10 days of traffic from the start of this month (before the end of term - I work for Cambridge University). This totalled 2473192 messages from 98825 domains after spam filtering. The data is rather skewed: 43295 domains were used in only one message each. The breakdown of these domains from the DNS point of view is: total: 98825 broken: 897 - neither A nor MX records no A: 18687 no MX: 6282 mismatch: 56244 - A and MX point to different hosts partial: 380 - A is not a subset of MX match: 16335 - A is a subset of MX Note that there is some difference between the validation done by the DNS software I used for this analysis and that done by our MTA, and over a week has passed since we accepted these messages, which is why the "broken" count is non-zero. I did this using about 150 lines of perl and `adnshost -f -a`; I don't have a handy concurrent SMTP tool so the full analysis will take more work... Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From courtneysmith at comcast.net Mon Dec 21 23:16:47 2009 From: courtneysmith at comcast.net (Courtney Smith) Date: Mon, 21 Dec 2009 18:16:47 -0500 Subject: Tools BOF at NANOG-48 In-Reply-To: References: Message-ID: I would love to see a case study how a network integrated IRRPT into their daily operations. It's a tool I'm trying to figure out how to best integrate into my network operations. http://sourceforge.net/projects/irrpt/ On Dec 21, 2009, at 7:00 AM, nanog-request at nanog.org wrote: > > Message: 6 > Date: Sun, 20 Dec 2009 22:42:03 +0530 > From: Mohit Lad > Subject: Tools BOF at NANOG-48 > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Dear all, > > > I am planning on organizing the Network Tools BOF at NANOG-48 with the > objective of presenting interesting and useful non-commercial tools that > have a fairly widespread appeal. Tool owners would make short presentations > and show usefulness of the tool with case studies. If you have developed or > know of a tool/package that you would like to include, please send me an > email directly. > > > As part of the tools BOF, I also plan to run a short 15-20 min "Tools > roundup" outlining the most common non-commercial tools used for day to day > networking tasks. The objective of this is not to present details of tools, > but rather a rough taxonomy. Feel free to suggest tools you find useful. > > > Thanks > > -Mohit From deric.kwok2000 at gmail.com Mon Dec 21 23:25:25 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 21 Dec 2009 18:25:25 -0500 Subject: how it routes and network question Message-ID: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> Hi I recently get two dedicated servers in hosting company the ip address of the server is eg: 192.168.32.4/32 and 192.168.57.2/32 I try to check the gateway but it seems no any trace command in the server. hosting company is using dhcp in those servers network configuration. I have concern and questions 1/ How can I know those servers are same network as those net mask is /32 if not the same network, I have problem when two servers are slowing in transferring files 2/ lf the network card in server has problem and need change another one, will my ip address change to another ip address also? 3/ why hosting company is using /32 and dhcp? what is advantage? ls it easy for administration? Thank you for your help From bruce at tubes.net.au Mon Dec 21 23:45:43 2009 From: bruce at tubes.net.au (Bruce Forster) Date: Tue, 22 Dec 2009 09:45:43 +1000 Subject: how it routes and network question In-Reply-To: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> References: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> Message-ID: <000b01ca8297$b8755410$295ffc30$@net.au> 1/ How can I know those servers are same network as those net mask is /32 if not the same network, I have problem when two servers are slowing in transferring files Check the subnet mask, i doubt its going to be 255.255.255.255 2/ lf the network card in server has problem and need change another one, will my ip address change to another ip address also? Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof your old mac address. 3/ why hosting company is using /32 and dhcp? what is advantage? ls it easy for administration? Im guessing because the users are to stupid to understand what a subnet mask/gateway is its just easier to get the mac address and assign it to a user then let the user assign a ip. Normally in a co-location setup its not like this, inless its very cheap hosting. My co-location has the following setup, and this is how MOST networks should be run. Core router using BGP to transit providers, and other local peers. Switched network useing ospf to handle the routes and also VLAN's for the customers subnets. So customer should get a vlan assigned to them (which they have no need to know what the number is, they are handed a access mode port. Customers also issued a /30 (at least) in most cases a customer will get a /29 or /28 depending on what they need. In this case of a /30 its a total of 3 address's 1, GATEWAY (put on the ISP/HOST switch 2, IP ADDRESS FOR SERVER TO USE 3, BROADCAST ADDRESS. Heres an eg of a /30: Address: 192.168.1.1 11000000.10101000.00000001.000000 01 Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 => Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 Hosts/Net: 2 Class C, Private Internet Heres an eg of a /29: the % ipcalc 192.168.1.1/29 Address: 192.168.1.1 11000000.10101000.00000001.00000 001 Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 => Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 Hosts/Net: 6 Class C, Private Internet Hope this makes sence. Regards, Bruce From frnkblk at iname.com Mon Dec 21 23:59:04 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 21 Dec 2009 17:59:04 -0600 Subject: wifi hotspot software needed In-Reply-To: <4B2FCAE0.5070307@kouzmanoff.com> References: <4B2FCAE0.5070307@kouzmanoff.com> Message-ID: I've been impressed with what I've seen from SolutionInc (http://www.solutioninc.com/). They're the only multi-site product I would feel comfortable pursuing at this time. Most others require managing each site or AP separately, which is not my idea of scalable. Frank -----Original Message----- From: keith kouzmanoff [mailto:keith at kouzmanoff.com] Sent: Monday, December 21, 2009 1:22 PM To: nanog at nanog.org Subject: wifi hotspot software needed I am consulting with a new player in the internet field and I am looking for suggestions for hotspot wifi software. GPL would be great, but I know some of the stuff out doesn't have all the features. http://www.antamedia.com/ looks pretty solid and has an oem feature, anybody else us this? We will wanting to set up about 10 different hotspots in a small downtown area and we want to give away the service for free. Doesn't everybody expect that already? I'll want to also be able to manage some rotating-commercialized popups/popunders or log in advertisements to offset the costs. As well as some traffic shaping / blocking some common high bandwidth usage sites / or times of the day / for the neighbors who live in the area too. Maybe some one has done this before? If you have any suggestions, please feel free to contact me off list. keith at kouzmanoff dot com thanks! From ops.lists at gmail.com Tue Dec 22 03:43:34 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 22 Dec 2009 09:13:34 +0530 Subject: Tools BOF at NANOG-48 In-Reply-To: References: Message-ID: Hi. I'd like to see some content on log aggregation from multiple sources (parse mail / web / IDS / netflow / ... etc logs) and analysis of logs from these multiple sources. For security, traffic engineering etc etc. Using a tool like Splunk, for example - and any other alternatives to homegrown perl scripts. --srs On Sun, Dec 20, 2009 at 10:42 PM, Mohit Lad wrote: > > ?As part of the tools BOF, I also plan to run a short 15-20 min "Tools > roundup" outlining the most common non-commercial tools used for day to day > networking tasks. The objective of this is not to present details of tools, > but rather a rough taxonomy. Feel free to suggest tools you find useful. -- Suresh Ramasubramanian (ops.lists at gmail.com) From morrowc.lists at gmail.com Tue Dec 22 06:25:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Dec 2009 01:25:01 -0500 Subject: Tools BOF at NANOG-48 In-Reply-To: References: Message-ID: <75cb24520912212225x3eceb1cbm40a2c7b0fbae84d@mail.gmail.com> On Mon, Dec 21, 2009 at 6:16 PM, Courtney Smith wrote: > I would love to see a ?case study how a network integrated IRRPT into their daily operations. ?It's a tool I'm trying to figure out how to best integrate into my network operations. > > http://sourceforge.net/projects/irrpt/ maybe we'll get lucky and the developer of said tool will attend the meeting/BoF? :) -Chris > On Dec 21, 2009, at 7:00 AM, nanog-request at nanog.org wrote: > >> >> Message: 6 >> Date: Sun, 20 Dec 2009 22:42:03 +0530 >> From: Mohit Lad >> Subject: Tools BOF at NANOG-48 >> To: nanog at nanog.org >> Message-ID: >> ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Dear all, >> >> >> I am planning on organizing the Network Tools BOF at NANOG-48 with the >> objective of presenting interesting and useful non-commercial tools that >> have a fairly widespread appeal. Tool owners would make short presentations >> and show usefulness of the tool with case studies. If you have developed or >> know of a tool/package that you would like to include, please send me an >> email directly. >> >> >> As part of the tools BOF, I also plan to run a short 15-20 min "Tools >> roundup" outlining the most common non-commercial tools used for day to day >> networking tasks. The objective of this is not to present details of tools, >> but rather a rough taxonomy. Feel free to suggest tools you find useful. >> >> >> Thanks >> >> -Mohit > > From hank at efes.iucc.ac.il Tue Dec 22 07:30:00 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 22 Dec 2009 09:30:00 +0200 (IST) Subject: news from Google In-Reply-To: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: On Mon, 21 Dec 2009, Jorge Amodio wrote: > Another one from the "Evil Doer" > > http://www.google.com/advertising/holiday2009/ > > Wish the guys from Redmond and others copy this action too ... > > Cheers > Jorge Google makes about $1.5B profit per quarter. $20M of charity? I don't like MS any more than most, but Gates Foundation has received $20B from Bill and Warren over the past 3 years. My hat goes off to those guys! >From a corporate standpoint, comparing to 2006 donations as reviewed by Businessweek: http://bwnt.businessweek.com/interactive_reports/philanthropy_corporate/ Google's $20M on $6B profit for 2009 is miniscule and basically just PR hype. Wanna compare Bill to Larry & Sergey? Your comment on "wish Redmond would copy this action" is libelous and I certainly hope that major philanthropists do not "copy" Google's joke of a donation. -Hank Further references: http://www.corporatephilanthropy.org/resources/benchmarking-reports/giving-in-numbers.html http://philanthropy.com/philanthropy50/index.php?view=topdonors&year=2008 From scott at doc.net.au Tue Dec 22 07:57:11 2009 From: scott at doc.net.au (Scott Howard) Date: Mon, 21 Dec 2009 23:57:11 -0800 Subject: news from Google In-Reply-To: References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: On Mon, Dec 21, 2009 at 11:30 PM, Hank Nussbacher wrote: > > Google makes about $1.5B profit per quarter. $20M of charity? I don't > like MS any more than most, but Gates Foundation has received $20B from Bill > and Warren over the past 3 years. My hat goes off to those guys! > Just to put this in the right context you might want to read http://www.techcrunch.com/2009/12/21/google-2009-holiday-gift/ ie, this is not a charity donation from "Google", but from one part of Google on behalf of their customers/suppliers. Either way, I think we're a little off topic by this stage... Scott. From lists at netrogenic.com Tue Dec 22 09:08:48 2009 From: lists at netrogenic.com (Jay Ess) Date: Tue, 22 Dec 2009 10:08:48 +0100 Subject: news from Google In-Reply-To: <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: <4B308CA0.5090503@netrogenic.com> Jorge Amodio wrote: > Another one from the "Evil Doer" > > http://www.google.com/advertising/holiday2009/ > > Wish the guys from Redmond and others copy this action too ... > http://en.wikipedia.org/wiki/Bill_&_Melinda_Gates_Foundation From bill at edisys.co.uk Tue Dec 22 09:15:00 2009 From: bill at edisys.co.uk (William Hamilton) Date: Tue, 22 Dec 2009 09:15:00 +0000 Subject: news from Google In-Reply-To: <4B308CA0.5090503@netrogenic.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <4B308CA0.5090503@netrogenic.com> Message-ID: <4B308E14.4010701@edisys.co.uk> Jay Ess wrote: > Jorge Amodio wrote: >> Another one from the "Evil Doer" >> >> http://www.google.com/advertising/holiday2009/ >> >> Wish the guys from Redmond and others copy this action too ... >> > http://en.wikipedia.org/wiki/Bill_&_Melinda_Gates_Foundation > > Whilst it may have been established by one of the Microsoft founders, what does that have to do with Microsoft's corporate charitable giving? B From lists at netrogenic.com Tue Dec 22 09:20:39 2009 From: lists at netrogenic.com (Jay Ess) Date: Tue, 22 Dec 2009 10:20:39 +0100 Subject: news from Google In-Reply-To: <4B308E14.4010701@edisys.co.uk> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <4B308CA0.5090503@netrogenic.com> <4B308E14.4010701@edisys.co.uk> Message-ID: <4B308F67.4010904@netrogenic.com> William Hamilton wrote: > Jay Ess wrote: >> http://en.wikipedia.org/wiki/Bill_&_Melinda_Gates_Foundation >> > Whilst it may have been established by one of the Microsoft founders, > what does that have to do with Microsoft's corporate charitable giving? I would guess that the money originally comes from the profits of MS so i think its related. But you are right that it does not come directly from MS. From regnauld at nsrc.org Tue Dec 22 10:27:12 2009 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 22 Dec 2009 11:27:12 +0100 Subject: Article on spammers and their infrastructure Message-ID: <20091222102709.GD81417@macbook.catpipe.net> http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 It this something new ? The article seems to mix various issues together. And this would seem highly inefficient to me compared to traditional botnets (renting your own rack for a botnet doesn't really make sense :) Comments ? From deric.kwok2000 at gmail.com Tue Dec 22 12:31:58 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 22 Dec 2009 07:31:58 -0500 Subject: how it routes and network question In-Reply-To: <000b01ca8297$b8755410$295ffc30$@net.au> References: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> <000b01ca8297$b8755410$295ffc30$@net.au> Message-ID: <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> Hi Bruce Thank you so much to explain me in detail. I would like to know about this it in case i can get another hosting company Yes. I think the netmask should be 255.255.255.255 1/ but why they are using this netmask setting? save ip address? then does the router handle many routes in this setting? 2/ What is this advantage for the hosting company? 3/ If I need more ip in the same server, how it works? 4/ Why you said the hosting company is cheap to use this configuration? Thank you again. > > > 2/ lf ?the network card in server has problem and need change another > one, will my ip address change to another ip address also? > > Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof > your old mac address. > > > 3/ why hosting company is using /32 and dhcp? what is advantage? ls it > easy for administration? > > Im guessing because the users are to stupid to understand what a subnet > mask/gateway is its just easier to get the mac address and assign it to a > user then let the user assign a ip. > > > Normally in a co-location setup its not like this, inless its very cheap > hosting. > > My co-location has the following setup, and this is how MOST networks should > be run. > > Core router using BGP to transit providers, and other local peers. > Switched network useing ospf to handle the routes and also VLAN's for the > customers subnets. > > So customer should get a vlan assigned to them (which they have no need to > know what the number is, they are handed a access mode port. > Customers also issued a /30 (at least) in most cases a customer will get a > /29 or /28 depending on what they need. > In this case of a /30 its a total of 3 address's > 1, GATEWAY (put on the ISP/HOST switch > 2, IP ADDRESS FOR SERVER TO USE > 3, BROADCAST ADDRESS. > > Heres an eg of a /30: > > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > Netmask: ? 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 > Wildcard: ?0.0.0.3 ? ? ? ? ? ? ?00000000.00000000.00000000.000000 11 > => > Network: ? 192.168.1.0/30 ? ? ? 11000000.10101000.00000001.000000 00 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > HostMax: ? 192.168.1.2 ? ? ? ? ?11000000.10101000.00000001.000000 10 > Broadcast: 192.168.1.3 ? ? ? ? ?11000000.10101000.00000001.000000 11 > Hosts/Net: 2 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > > Heres an eg of a /29: > > the % ipcalc 192.168.1.1/29 > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > Netmask: ? 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 > Wildcard: ?0.0.0.7 ? ? ? ? ? ? ?00000000.00000000.00000000.00000 111 > => > Network: ? 192.168.1.0/29 ? ? ? 11000000.10101000.00000001.00000 000 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > HostMax: ? 192.168.1.6 ? ? ? ? ?11000000.10101000.00000001.00000 110 > Broadcast: 192.168.1.7 ? ? ? ? ?11000000.10101000.00000001.00000 111 > Hosts/Net: 6 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > Hope this makes sence. > > Regards, > > Bruce > > > From truman at suspicious.org Tue Dec 22 12:47:11 2009 From: truman at suspicious.org (Truman Boyes) Date: Tue, 22 Dec 2009 23:47:11 +1100 Subject: how it routes and network question In-Reply-To: <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> References: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> <000b01ca8297$b8755410$295ffc30$@net.au> <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> Message-ID: Hi, your "hosting company" is likely NAT'ing or using load balancers on the front end. You are obviously not "reaching" those machines by ssh'ing into 192.168.x.x... Additionally, assuming that DHCP is handing out that address on the server that mask would likely not be all ones. Even Amazon EC2 instances use private addresses now on the backend ... Kind regards, Truman On 22/12/2009, at 11:31 PM, Deric Kwok wrote: > Hi Bruce > > Thank you so much to explain me in detail. I would like to know about > this it in case i can get another hosting company > > Yes. I think the netmask should be 255.255.255.255 > 1/ but why they are using this netmask setting? save ip address? > then does the router handle many routes in this setting? > 2/ What is this advantage for the hosting company? > 3/ If I need more ip in the same server, how it works? > 4/ Why you said the hosting company is cheap to use this configuration? > > Thank you again. > > > > > >> >> >> 2/ lf the network card in server has problem and need change another >> one, will my ip address change to another ip address also? >> >> Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof >> your old mac address. >> >> >> 3/ why hosting company is using /32 and dhcp? what is advantage? ls it >> easy for administration? >> >> Im guessing because the users are to stupid to understand what a subnet >> mask/gateway is its just easier to get the mac address and assign it to a >> user then let the user assign a ip. >> >> >> Normally in a co-location setup its not like this, inless its very cheap >> hosting. >> >> My co-location has the following setup, and this is how MOST networks should >> be run. >> >> Core router using BGP to transit providers, and other local peers. >> Switched network useing ospf to handle the routes and also VLAN's for the >> customers subnets. >> >> So customer should get a vlan assigned to them (which they have no need to >> know what the number is, they are handed a access mode port. >> Customers also issued a /30 (at least) in most cases a customer will get a >> /29 or /28 depending on what they need. >> In this case of a /30 its a total of 3 address's >> 1, GATEWAY (put on the ISP/HOST switch >> 2, IP ADDRESS FOR SERVER TO USE >> 3, BROADCAST ADDRESS. >> >> Heres an eg of a /30: >> >> Address: 192.168.1.1 11000000.10101000.00000001.000000 01 >> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 >> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 >> => >> Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 >> HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 >> HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 >> Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 >> Hosts/Net: 2 Class C, Private Internet >> >> >> Heres an eg of a /29: >> >> the % ipcalc 192.168.1.1/29 >> Address: 192.168.1.1 11000000.10101000.00000001.00000 001 >> Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 >> Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 >> => >> Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 >> HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 >> HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 >> Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 >> Hosts/Net: 6 Class C, Private Internet >> >> Hope this makes sence. >> >> Regards, >> >> Bruce >> >> >> > From bruce at tubes.net.au Tue Dec 22 12:48:04 2009 From: bruce at tubes.net.au (Bruce Forster) Date: Tue, 22 Dec 2009 22:48:04 +1000 Subject: how it routes and network question In-Reply-To: <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> References: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> <000b01ca8297$b8755410$295ffc30$@net.au> <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> Message-ID: <001701ca8305$0c8a3620$259ea260$@net.au> Yes. I think the netmask should be 255.255.255.255 1/ but why they are using this netmask setting? save ip address? then does the router handle many routes in this setting? I have no idea the only way you can have a /32 is with a ppp that doesn?t use arps to talk to each end of the tunnel. I would assume they have /24's and are giving out /32 via dhcp to customers and the customers should see 255.255.255.0 with a gateway of eg, .1 etc.. 2/ What is this advantage for the hosting company? If the company is setup the way i think it is the only reason for this is: 1, they have no clue what they are doing 2, they offer a very cheap hosting service and have no managed switches, and don?t understand how to subnet and use vlan's. 3/ If I need more ip in the same server, how it works? I would of thought if you have 2 x servers you wanted to co-locate the hosting company would offer you a /29 with 1 gateway 1 broadcast and 4 useable on a vlan, so local traffic only sits on the vlan and the servers can talk to each other via the local vlan. I guess if the machines have more then 1 nic you can connect the 2 machines via a local 'backnet' network it can be useful if you have a cross-over cable between the 2 x machines and its a 1GB port. This also saves using the switches, in some cases hosting companies may count all traffic that goes over the interface (if they don?t use net flow) and you could end up paying for traffic which you really shouldn?t have to pay for. If you are using the additional ports for high amounts of data eg, backup's images etc, you can really tweak tcp settings so you can send JUMBO frames and squeeze some speed out of it. 4/ Why you said the hosting company is cheap to use this configuration? Yes its alot cheaper to have say a common-gateway that all traffic will route over and then connect a bunch of switches to this common router and manage it via dhcp, its very messy and also very noisy i can only imagine after you connect a few servers that over time you will see arp storms and all traffic on the network will cease to flow. As mentioned in my other posts how it should be done, clearly you need to buy layer 3 switches and layer 2 switches and a nice core router to deal with your bgp, you also need to make sure your using devices that can handle high packets per second. As i am writing this i feel as if im doing someone homework for them... ;P Thank you again. > > > 2/ lf ?the network card in server has problem and need change another > one, will my ip address change to another ip address also? > > Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof > your old mac address. > > > 3/ why hosting company is using /32 and dhcp? what is advantage? ls it > easy for administration? > > Im guessing because the users are to stupid to understand what a subnet > mask/gateway is its just easier to get the mac address and assign it to a > user then let the user assign a ip. > > > Normally in a co-location setup its not like this, inless its very cheap > hosting. > > My co-location has the following setup, and this is how MOST networks should > be run. > > Core router using BGP to transit providers, and other local peers. > Switched network useing ospf to handle the routes and also VLAN's for the > customers subnets. > > So customer should get a vlan assigned to them (which they have no need to > know what the number is, they are handed a access mode port. > Customers also issued a /30 (at least) in most cases a customer will get a > /29 or /28 depending on what they need. > In this case of a /30 its a total of 3 address's > 1, GATEWAY (put on the ISP/HOST switch > 2, IP ADDRESS FOR SERVER TO USE > 3, BROADCAST ADDRESS. > > Heres an eg of a /30: > > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > Netmask: ? 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 > Wildcard: ?0.0.0.3 ? ? ? ? ? ? ?00000000.00000000.00000000.000000 11 > => > Network: ? 192.168.1.0/30 ? ? ? 11000000.10101000.00000001.000000 00 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > HostMax: ? 192.168.1.2 ? ? ? ? ?11000000.10101000.00000001.000000 10 > Broadcast: 192.168.1.3 ? ? ? ? ?11000000.10101000.00000001.000000 11 > Hosts/Net: 2 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > > Heres an eg of a /29: > > the % ipcalc 192.168.1.1/29 > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > Netmask: ? 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 > Wildcard: ?0.0.0.7 ? ? ? ? ? ? ?00000000.00000000.00000000.00000 111 > => > Network: ? 192.168.1.0/29 ? ? ? 11000000.10101000.00000001.00000 000 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > HostMax: ? 192.168.1.6 ? ? ? ? ?11000000.10101000.00000001.00000 110 > Broadcast: 192.168.1.7 ? ? ? ? ?11000000.10101000.00000001.00000 111 > Hosts/Net: 6 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > Hope this makes sence. > > Regards, > > Bruce > > > From bruce at tubes.net.au Tue Dec 22 12:51:20 2009 From: bruce at tubes.net.au (Bruce Forster) Date: Tue, 22 Dec 2009 22:51:20 +1000 Subject: how it routes and network question In-Reply-To: References: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> <000b01ca8297$b8755410$295ffc30$@net.au> <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> Message-ID: <001801ca8305$7d2f56d0$778e0470$@net.au> I should add; i guess i made some assumption that you were co-locating your own servers with someone, if this isn't the case, please ignore everything i'v said ;) -bruce -----Original Message----- From: Truman Boyes [mailto:truman at suspicious.org] Sent: Tuesday, 22 December 2009 10:47 PM To: Deric Kwok Cc: Bruce Forster; nanog at nanog.org Subject: Re: how it routes and network question Hi, your "hosting company" is likely NAT'ing or using load balancers on the front end. You are obviously not "reaching" those machines by ssh'ing into 192.168.x.x... Additionally, assuming that DHCP is handing out that address on the server that mask would likely not be all ones. Even Amazon EC2 instances use private addresses now on the backend ... Kind regards, Truman On 22/12/2009, at 11:31 PM, Deric Kwok wrote: > Hi Bruce > > Thank you so much to explain me in detail. I would like to know about > this it in case i can get another hosting company > > Yes. I think the netmask should be 255.255.255.255 > 1/ but why they are using this netmask setting? save ip address? > then does the router handle many routes in this setting? > 2/ What is this advantage for the hosting company? > 3/ If I need more ip in the same server, how it works? > 4/ Why you said the hosting company is cheap to use this configuration? > > Thank you again. > > > > > >> >> >> 2/ lf the network card in server has problem and need change another >> one, will my ip address change to another ip address also? >> >> Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof >> your old mac address. >> >> >> 3/ why hosting company is using /32 and dhcp? what is advantage? ls it >> easy for administration? >> >> Im guessing because the users are to stupid to understand what a subnet >> mask/gateway is its just easier to get the mac address and assign it to a >> user then let the user assign a ip. >> >> >> Normally in a co-location setup its not like this, inless its very cheap >> hosting. >> >> My co-location has the following setup, and this is how MOST networks should >> be run. >> >> Core router using BGP to transit providers, and other local peers. >> Switched network useing ospf to handle the routes and also VLAN's for the >> customers subnets. >> >> So customer should get a vlan assigned to them (which they have no need to >> know what the number is, they are handed a access mode port. >> Customers also issued a /30 (at least) in most cases a customer will get a >> /29 or /28 depending on what they need. >> In this case of a /30 its a total of 3 address's >> 1, GATEWAY (put on the ISP/HOST switch >> 2, IP ADDRESS FOR SERVER TO USE >> 3, BROADCAST ADDRESS. >> >> Heres an eg of a /30: >> >> Address: 192.168.1.1 11000000.10101000.00000001.000000 01 >> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 >> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 >> => >> Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 >> HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 >> HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 >> Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 >> Hosts/Net: 2 Class C, Private Internet >> >> >> Heres an eg of a /29: >> >> the % ipcalc 192.168.1.1/29 >> Address: 192.168.1.1 11000000.10101000.00000001.00000 001 >> Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 >> Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 >> => >> Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 >> HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 >> HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 >> Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 >> Hosts/Net: 6 Class C, Private Internet >> >> Hope this makes sence. >> >> Regards, >> >> Bruce >> >> >> > From dot at dotat.at Tue Dec 22 13:08:18 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 22 Dec 2009 13:08:18 +0000 Subject: Article on spammers and their infrastructure In-Reply-To: <20091222102709.GD81417@macbook.catpipe.net> References: <20091222102709.GD81417@macbook.catpipe.net> Message-ID: On Tue, 22 Dec 2009, Phil Regnauld wrote: > http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 > > It this something new ? The article seems to mix various issues together. > And this would seem highly inefficient to me compared to traditional > botnets (renting your own rack for a botnet doesn't really make sense :) > > Comments ? Sounds like a snowshoe setup to me. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From daffy at daffy.za.net Tue Dec 22 13:32:58 2009 From: daffy at daffy.za.net (Kieran Murphy) Date: Tue, 22 Dec 2009 13:32:58 +0000 Subject: how it routes and network question In-Reply-To: <001801ca8305$7d2f56d0$778e0470$@net.au> References: <40d8a95a0912211525h206cfd19o4b150066a91d4b38@mail.gmail.com> <000b01ca8297$b8755410$295ffc30$@net.au> <40d8a95a0912220431p7232025bx338affded04c8bd0@mail.gmail.com> <001801ca8305$7d2f56d0$778e0470$@net.au> Message-ID: Or these are VPS', and not physical Servers. >From my brief encounters with various VPS technologies, this makes more sense. Regards, Kieran. On Tue, Dec 22, 2009 at 12:51 PM, Bruce Forster wrote: > I should add; i guess i made some assumption that you were co-locating your > own servers with someone, if this isn't the case, please ignore everything > i'v said ;) > > > -bruce > > -----Original Message----- > From: Truman Boyes [mailto:truman at suspicious.org] > Sent: Tuesday, 22 December 2009 10:47 PM > To: Deric Kwok > Cc: Bruce Forster; nanog at nanog.org > Subject: Re: how it routes and network question > > Hi, your "hosting company" is likely NAT'ing or using load balancers on the > front end. You are obviously not "reaching" those machines by ssh'ing into > 192.168.x.x... Additionally, assuming that DHCP is handing out that address > on the server that mask would likely not be all ones. > > Even Amazon EC2 instances use private addresses now on the backend ... > > Kind regards, > Truman > > > On 22/12/2009, at 11:31 PM, Deric Kwok wrote: > > > Hi Bruce > > > > Thank you so much to explain me in detail. I would like to know about > > this it in case i can get another hosting company > > > > Yes. I think the netmask should be 255.255.255.255 > > 1/ but why they are using this netmask setting? save ip address? > > then does the router handle many routes in this setting? > > 2/ What is this advantage for the hosting company? > > 3/ If I need more ip in the same server, how it works? > > 4/ Why you said the hosting company is cheap to use this configuration? > > > > Thank you again. > > > > > > > > > > > >> > >> > >> 2/ lf the network card in server has problem and need change another > >> one, will my ip address change to another ip address also? > >> > >> Yeah well thats how dhcp works, via ma caddy, i guess you can always > spoof > >> your old mac address. > >> > >> > >> 3/ why hosting company is using /32 and dhcp? what is advantage? ls it > >> easy for administration? > >> > >> Im guessing because the users are to stupid to understand what a subnet > >> mask/gateway is its just easier to get the mac address and assign it to > a > >> user then let the user assign a ip. > >> > >> > >> Normally in a co-location setup its not like this, inless its very cheap > >> hosting. > >> > >> My co-location has the following setup, and this is how MOST networks > should > >> be run. > >> > >> Core router using BGP to transit providers, and other local peers. > >> Switched network useing ospf to handle the routes and also VLAN's for > the > >> customers subnets. > >> > >> So customer should get a vlan assigned to them (which they have no need > to > >> know what the number is, they are handed a access mode port. > >> Customers also issued a /30 (at least) in most cases a customer will get > a > >> /29 or /28 depending on what they need. > >> In this case of a /30 its a total of 3 address's > >> 1, GATEWAY (put on the ISP/HOST switch > >> 2, IP ADDRESS FOR SERVER TO USE > >> 3, BROADCAST ADDRESS. > >> > >> Heres an eg of a /30: > >> > >> Address: 192.168.1.1 11000000.10101000.00000001.000000 01 > >> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 > >> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 > >> => > >> Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 > >> HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 > >> HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 > >> Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 > >> Hosts/Net: 2 Class C, Private Internet > >> > >> > >> Heres an eg of a /29: > >> > >> the % ipcalc 192.168.1.1/29 > >> Address: 192.168.1.1 11000000.10101000.00000001.00000 001 > >> Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 > >> Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 > >> => > >> Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 > >> HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 > >> HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 > >> Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 > >> Hosts/Net: 6 Class C, Private Internet > >> > >> Hope this makes sence. > >> > >> Regards, > >> > >> Bruce > >> > >> > >> > > > > > > From jmamodio at gmail.com Tue Dec 22 13:42:18 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 22 Dec 2009 07:42:18 -0600 Subject: FYI, new USG Cybersecurity Coordinator ... Message-ID: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> FYI, http://www.whitehouse.gov/blog/2009/12/22/introducing-new-cybersecurity-coordinator/?e=23&ref=image From ops.lists at gmail.com Tue Dec 22 13:45:07 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 22 Dec 2009 19:15:07 +0530 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> Message-ID: With the added refinement of spammer / botmaster controlled LIRs .. after spammer / botmaster controlled registrars. I did wonder sometimes how some snowshoe spammers could keep acquiring a series of /20 to /15 sized CIDRs over the past year or two. On Tue, Dec 22, 2009 at 6:38 PM, Tony Finch wrote: > Sounds like a snowshoe setup to me. > > Tony. -- Suresh Ramasubramanian (ops.lists at gmail.com) From Mauricio.Rodriguez at fpl.com Tue Dec 22 13:50:56 2009 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Tue, 22 Dec 2009 08:50:56 -0500 Subject: NANOG Digest, Vol 23, Issue 82 Message-ID: <611085D375448C4D99BAF870659DEAC40A6813E5D7@GOXEXVS03.fplu.fpl.com> Any time mobile. Regards, Mauricio Rodriguez Manager of IP/Data Engineering, FPL FiberNet Email: Mauricio.Rodriguez at fpl.com Office: 305-552-3418 Mobile: 786-236-2665 Pager: 786-236-2665 Sent using BlackBerry ----- Original Message ----- From: nanog-request at nanog.org To: nanog at nanog.org Sent: Tue Dec 22 08:33:01 2009 Subject: NANOG Digest, Vol 23, Issue 82 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: how it routes and network question (Deric Kwok) 2. Re: how it routes and network question (Truman Boyes) 3. RE: how it routes and network question (Bruce Forster) 4. RE: how it routes and network question (Bruce Forster) 5. Re: Article on spammers and their infrastructure (Tony Finch) 6. Re: how it routes and network question (Kieran Murphy) ---------------------------------------------------------------------- Message: 1 Date: Tue, 22 Dec 2009 07:31:58 -0500 From: Deric Kwok Subject: Re: how it routes and network question To: Bruce Forster Cc: nanog at nanog.org Message-ID: <40d8a95a0912220431p7232025bx338affded04c8bd0 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Bruce Thank you so much to explain me in detail. I would like to know about this it in case i can get another hosting company Yes. I think the netmask should be 255.255.255.255 1/ but why they are using this netmask setting? save ip address? then does the router handle many routes in this setting? 2/ What is this advantage for the hosting company? 3/ If I need more ip in the same server, how it works? 4/ Why you said the hosting company is cheap to use this configuration? Thank you again. > > > 2/ lf ?the network card in server has problem and need change another > one, will my ip address change to another ip address also? > > Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof > your old mac address. > > > 3/ why hosting company is using /32 and dhcp? what is advantage? ls it > easy for administration? > > Im guessing because the users are to stupid to understand what a subnet > mask/gateway is its just easier to get the mac address and assign it to a > user then let the user assign a ip. > > > Normally in a co-location setup its not like this, inless its very cheap > hosting. > > My co-location has the following setup, and this is how MOST networks should > be run. > > Core router using BGP to transit providers, and other local peers. > Switched network useing ospf to handle the routes and also VLAN's for the > customers subnets. > > So customer should get a vlan assigned to them (which they have no need to > know what the number is, they are handed a access mode port. > Customers also issued a /30 (at least) in most cases a customer will get a > /29 or /28 depending on what they need. > In this case of a /30 its a total of 3 address's > 1, GATEWAY (put on the ISP/HOST switch > 2, IP ADDRESS FOR SERVER TO USE > 3, BROADCAST ADDRESS. > > Heres an eg of a /30: > > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > Netmask: ? 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 > Wildcard: ?0.0.0.3 ? ? ? ? ? ? ?00000000.00000000.00000000.000000 11 > => > Network: ? 192.168.1.0/30 ? ? ? 11000000.10101000.00000001.000000 00 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > HostMax: ? 192.168.1.2 ? ? ? ? ?11000000.10101000.00000001.000000 10 > Broadcast: 192.168.1.3 ? ? ? ? ?11000000.10101000.00000001.000000 11 > Hosts/Net: 2 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > > Heres an eg of a /29: > > the % ipcalc 192.168.1.1/29 > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > Netmask: ? 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 > Wildcard: ?0.0.0.7 ? ? ? ? ? ? ?00000000.00000000.00000000.00000 111 > => > Network: ? 192.168.1.0/29 ? ? ? 11000000.10101000.00000001.00000 000 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > HostMax: ? 192.168.1.6 ? ? ? ? ?11000000.10101000.00000001.00000 110 > Broadcast: 192.168.1.7 ? ? ? ? ?11000000.10101000.00000001.00000 111 > Hosts/Net: 6 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > Hope this makes sence. > > Regards, > > Bruce > > > ------------------------------ Message: 2 Date: Tue, 22 Dec 2009 23:47:11 +1100 From: Truman Boyes Subject: Re: how it routes and network question To: Deric Kwok Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=us-ascii Hi, your "hosting company" is likely NAT'ing or using load balancers on the front end. You are obviously not "reaching" those machines by ssh'ing into 192.168.x.x... Additionally, assuming that DHCP is handing out that address on the server that mask would likely not be all ones. Even Amazon EC2 instances use private addresses now on the backend ... Kind regards, Truman On 22/12/2009, at 11:31 PM, Deric Kwok wrote: > Hi Bruce > > Thank you so much to explain me in detail. I would like to know about > this it in case i can get another hosting company > > Yes. I think the netmask should be 255.255.255.255 > 1/ but why they are using this netmask setting? save ip address? > then does the router handle many routes in this setting? > 2/ What is this advantage for the hosting company? > 3/ If I need more ip in the same server, how it works? > 4/ Why you said the hosting company is cheap to use this configuration? > > Thank you again. > > > > > >> >> >> 2/ lf the network card in server has problem and need change another >> one, will my ip address change to another ip address also? >> >> Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof >> your old mac address. >> >> >> 3/ why hosting company is using /32 and dhcp? what is advantage? ls it >> easy for administration? >> >> Im guessing because the users are to stupid to understand what a subnet >> mask/gateway is its just easier to get the mac address and assign it to a >> user then let the user assign a ip. >> >> >> Normally in a co-location setup its not like this, inless its very cheap >> hosting. >> >> My co-location has the following setup, and this is how MOST networks should >> be run. >> >> Core router using BGP to transit providers, and other local peers. >> Switched network useing ospf to handle the routes and also VLAN's for the >> customers subnets. >> >> So customer should get a vlan assigned to them (which they have no need to >> know what the number is, they are handed a access mode port. >> Customers also issued a /30 (at least) in most cases a customer will get a >> /29 or /28 depending on what they need. >> In this case of a /30 its a total of 3 address's >> 1, GATEWAY (put on the ISP/HOST switch >> 2, IP ADDRESS FOR SERVER TO USE >> 3, BROADCAST ADDRESS. >> >> Heres an eg of a /30: >> >> Address: 192.168.1.1 11000000.10101000.00000001.000000 01 >> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 >> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 >> => >> Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 >> HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 >> HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 >> Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 >> Hosts/Net: 2 Class C, Private Internet >> >> >> Heres an eg of a /29: >> >> the % ipcalc 192.168.1.1/29 >> Address: 192.168.1.1 11000000.10101000.00000001.00000 001 >> Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 >> Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 >> => >> Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 >> HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 >> HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 >> Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 >> Hosts/Net: 6 Class C, Private Internet >> >> Hope this makes sence. >> >> Regards, >> >> Bruce >> >> >> > ------------------------------ Message: 3 Date: Tue, 22 Dec 2009 22:48:04 +1000 From: "Bruce Forster" Subject: RE: how it routes and network question To: "'Deric Kwok'" Cc: nanog at nanog.org Message-ID: <001701ca8305$0c8a3620$259ea260$@net.au> Content-Type: text/plain; charset="iso-8859-1" Yes. I think the netmask should be 255.255.255.255 1/ but why they are using this netmask setting? save ip address? then does the router handle many routes in this setting? I have no idea the only way you can have a /32 is with a ppp that doesn?t use arps to talk to each end of the tunnel. I would assume they have /24's and are giving out /32 via dhcp to customers and the customers should see 255.255.255.0 with a gateway of eg, .1 etc.. 2/ What is this advantage for the hosting company? If the company is setup the way i think it is the only reason for this is: 1, they have no clue what they are doing 2, they offer a very cheap hosting service and have no managed switches, and don?t understand how to subnet and use vlan's. 3/ If I need more ip in the same server, how it works? I would of thought if you have 2 x servers you wanted to co-locate the hosting company would offer you a /29 with 1 gateway 1 broadcast and 4 useable on a vlan, so local traffic only sits on the vlan and the servers can talk to each other via the local vlan. I guess if the machines have more then 1 nic you can connect the 2 machines via a local 'backnet' network it can be useful if you have a cross-over cable between the 2 x machines and its a 1GB port. This also saves using the switches, in some cases hosting companies may count all traffic that goes over the interface (if they don?t use net flow) and you could end up paying for traffic which you really shouldn?t have to pay for. If you are using the additional ports for high amounts of data eg, backup's images etc, you can really tweak tcp settings so you can send JUMBO frames and squeeze some speed out of it. 4/ Why you said the hosting company is cheap to use this configuration? Yes its alot cheaper to have say a common-gateway that all traffic will route over and then connect a bunch of switches to this common router and manage it via dhcp, its very messy and also very noisy i can only imagine after you connect a few servers that over time you will see arp storms and all traffic on the network will cease to flow. As mentioned in my other posts how it should be done, clearly you need to buy layer 3 switches and layer 2 switches and a nice core router to deal with your bgp, you also need to make sure your using devices that can handle high packets per second. As i am writing this i feel as if im doing someone homework for them... ;P Thank you again. > > > 2/ lf ?the network card in server has problem and need change another > one, will my ip address change to another ip address also? > > Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof > your old mac address. > > > 3/ why hosting company is using /32 and dhcp? what is advantage? ls it > easy for administration? > > Im guessing because the users are to stupid to understand what a subnet > mask/gateway is its just easier to get the mac address and assign it to a > user then let the user assign a ip. > > > Normally in a co-location setup its not like this, inless its very cheap > hosting. > > My co-location has the following setup, and this is how MOST networks should > be run. > > Core router using BGP to transit providers, and other local peers. > Switched network useing ospf to handle the routes and also VLAN's for the > customers subnets. > > So customer should get a vlan assigned to them (which they have no need to > know what the number is, they are handed a access mode port. > Customers also issued a /30 (at least) in most cases a customer will get a > /29 or /28 depending on what they need. > In this case of a /30 its a total of 3 address's > 1, GATEWAY (put on the ISP/HOST switch > 2, IP ADDRESS FOR SERVER TO USE > 3, BROADCAST ADDRESS. > > Heres an eg of a /30: > > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > Netmask: ? 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 > Wildcard: ?0.0.0.3 ? ? ? ? ? ? ?00000000.00000000.00000000.000000 11 > => > Network: ? 192.168.1.0/30 ? ? ? 11000000.10101000.00000001.000000 00 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.000000 01 > HostMax: ? 192.168.1.2 ? ? ? ? ?11000000.10101000.00000001.000000 10 > Broadcast: 192.168.1.3 ? ? ? ? ?11000000.10101000.00000001.000000 11 > Hosts/Net: 2 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > > Heres an eg of a /29: > > the % ipcalc 192.168.1.1/29 > Address: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > Netmask: ? 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 > Wildcard: ?0.0.0.7 ? ? ? ? ? ? ?00000000.00000000.00000000.00000 111 > => > Network: ? 192.168.1.0/29 ? ? ? 11000000.10101000.00000001.00000 000 > HostMin: ? 192.168.1.1 ? ? ? ? ?11000000.10101000.00000001.00000 001 > HostMax: ? 192.168.1.6 ? ? ? ? ?11000000.10101000.00000001.00000 110 > Broadcast: 192.168.1.7 ? ? ? ? ?11000000.10101000.00000001.00000 111 > Hosts/Net: 6 ? ? ? ? ? ? ? ? ? ? Class C, Private Internet > > Hope this makes sence. > > Regards, > > Bruce > > > ------------------------------ Message: 4 Date: Tue, 22 Dec 2009 22:51:20 +1000 From: "Bruce Forster" Subject: RE: how it routes and network question To: "'Truman Boyes'" , "'Deric Kwok'" Cc: nanog at nanog.org Message-ID: <001801ca8305$7d2f56d0$778e0470$@net.au> Content-Type: text/plain; charset="us-ascii" I should add; i guess i made some assumption that you were co-locating your own servers with someone, if this isn't the case, please ignore everything i'v said ;) -bruce -----Original Message----- From: Truman Boyes [mailto:truman at suspicious.org] Sent: Tuesday, 22 December 2009 10:47 PM To: Deric Kwok Cc: Bruce Forster; nanog at nanog.org Subject: Re: how it routes and network question Hi, your "hosting company" is likely NAT'ing or using load balancers on the front end. You are obviously not "reaching" those machines by ssh'ing into 192.168.x.x... Additionally, assuming that DHCP is handing out that address on the server that mask would likely not be all ones. Even Amazon EC2 instances use private addresses now on the backend ... Kind regards, Truman On 22/12/2009, at 11:31 PM, Deric Kwok wrote: > Hi Bruce > > Thank you so much to explain me in detail. I would like to know about > this it in case i can get another hosting company > > Yes. I think the netmask should be 255.255.255.255 > 1/ but why they are using this netmask setting? save ip address? > then does the router handle many routes in this setting? > 2/ What is this advantage for the hosting company? > 3/ If I need more ip in the same server, how it works? > 4/ Why you said the hosting company is cheap to use this configuration? > > Thank you again. > > > > > >> >> >> 2/ lf the network card in server has problem and need change another >> one, will my ip address change to another ip address also? >> >> Yeah well thats how dhcp works, via ma caddy, i guess you can always spoof >> your old mac address. >> >> >> 3/ why hosting company is using /32 and dhcp? what is advantage? ls it >> easy for administration? >> >> Im guessing because the users are to stupid to understand what a subnet >> mask/gateway is its just easier to get the mac address and assign it to a >> user then let the user assign a ip. >> >> >> Normally in a co-location setup its not like this, inless its very cheap >> hosting. >> >> My co-location has the following setup, and this is how MOST networks should >> be run. >> >> Core router using BGP to transit providers, and other local peers. >> Switched network useing ospf to handle the routes and also VLAN's for the >> customers subnets. >> >> So customer should get a vlan assigned to them (which they have no need to >> know what the number is, they are handed a access mode port. >> Customers also issued a /30 (at least) in most cases a customer will get a >> /29 or /28 depending on what they need. >> In this case of a /30 its a total of 3 address's >> 1, GATEWAY (put on the ISP/HOST switch >> 2, IP ADDRESS FOR SERVER TO USE >> 3, BROADCAST ADDRESS. >> >> Heres an eg of a /30: >> >> Address: 192.168.1.1 11000000.10101000.00000001.000000 01 >> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 >> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 >> => >> Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 >> HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 >> HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 >> Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 >> Hosts/Net: 2 Class C, Private Internet >> >> >> Heres an eg of a /29: >> >> the % ipcalc 192.168.1.1/29 >> Address: 192.168.1.1 11000000.10101000.00000001.00000 001 >> Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 >> Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 >> => >> Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 >> HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 >> HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 >> Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 >> Hosts/Net: 6 Class C, Private Internet >> >> Hope this makes sence. >> >> Regards, >> >> Bruce >> >> >> > ------------------------------ Message: 5 Date: Tue, 22 Dec 2009 13:08:18 +0000 From: Tony Finch Subject: Re: Article on spammers and their infrastructure To: Phil Regnauld Cc: nanog at nanog.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Dec 2009, Phil Regnauld wrote: > http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 > > It this something new ? The article seems to mix various issues together. > And this would seem highly inefficient to me compared to traditional > botnets (renting your own rack for a botnet doesn't really make sense :) > > Comments ? Sounds like a snowshoe setup to me. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ------------------------------ Message: 6 Date: Tue, 22 Dec 2009 13:32:58 +0000 From: Kieran Murphy Subject: Re: how it routes and network question To: Bruce Forster Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Or these are VPS', and not physical Servers. >From my brief encounters with various VPS technologies, this makes more sense. Regards, Kieran. On Tue, Dec 22, 2009 at 12:51 PM, Bruce Forster wrote: > I should add; i guess i made some assumption that you were co-locating your > own servers with someone, if this isn't the case, please ignore everything > i'v said ;) > > > -bruce > > -----Original Message----- > From: Truman Boyes [mailto:truman at suspicious.org] > Sent: Tuesday, 22 December 2009 10:47 PM > To: Deric Kwok > Cc: Bruce Forster; nanog at nanog.org > Subject: Re: how it routes and network question > > Hi, your "hosting company" is likely NAT'ing or using load balancers on the > front end. You are obviously not "reaching" those machines by ssh'ing into > 192.168.x.x... Additionally, assuming that DHCP is handing out that address > on the server that mask would likely not be all ones. > > Even Amazon EC2 instances use private addresses now on the backend ... > > Kind regards, > Truman > > > On 22/12/2009, at 11:31 PM, Deric Kwok wrote: > > > Hi Bruce > > > > Thank you so much to explain me in detail. I would like to know about > > this it in case i can get another hosting company > > > > Yes. I think the netmask should be 255.255.255.255 > > 1/ but why they are using this netmask setting? save ip address? > > then does the router handle many routes in this setting? > > 2/ What is this advantage for the hosting company? > > 3/ If I need more ip in the same server, how it works? > > 4/ Why you said the hosting company is cheap to use this configuration? > > > > Thank you again. > > > > > > > > > > > >> > >> > >> 2/ lf the network card in server has problem and need change another > >> one, will my ip address change to another ip address also? > >> > >> Yeah well thats how dhcp works, via ma caddy, i guess you can always > spoof > >> your old mac address. > >> > >> > >> 3/ why hosting company is using /32 and dhcp? what is advantage? ls it > >> easy for administration? > >> > >> Im guessing because the users are to stupid to understand what a subnet > >> mask/gateway is its just easier to get the mac address and assign it to > a > >> user then let the user assign a ip. > >> > >> > >> Normally in a co-location setup its not like this, inless its very cheap > >> hosting. > >> > >> My co-location has the following setup, and this is how MOST networks > should > >> be run. > >> > >> Core router using BGP to transit providers, and other local peers. > >> Switched network useing ospf to handle the routes and also VLAN's for > the > >> customers subnets. > >> > >> So customer should get a vlan assigned to them (which they have no need > to > >> know what the number is, they are handed a access mode port. > >> Customers also issued a /30 (at least) in most cases a customer will get > a > >> /29 or /28 depending on what they need. > >> In this case of a /30 its a total of 3 address's > >> 1, GATEWAY (put on the ISP/HOST switch > >> 2, IP ADDRESS FOR SERVER TO USE > >> 3, BROADCAST ADDRESS. > >> > >> Heres an eg of a /30: > >> > >> Address: 192.168.1.1 11000000.10101000.00000001.000000 01 > >> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00 > >> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11 > >> => > >> Network: 192.168.1.0/30 11000000.10101000.00000001.000000 00 > >> HostMin: 192.168.1.1 11000000.10101000.00000001.000000 01 > >> HostMax: 192.168.1.2 11000000.10101000.00000001.000000 10 > >> Broadcast: 192.168.1.3 11000000.10101000.00000001.000000 11 > >> Hosts/Net: 2 Class C, Private Internet > >> > >> > >> Heres an eg of a /29: > >> > >> the % ipcalc 192.168.1.1/29 > >> Address: 192.168.1.1 11000000.10101000.00000001.00000 001 > >> Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 > >> Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 > >> => > >> Network: 192.168.1.0/29 11000000.10101000.00000001.00000 000 > >> HostMin: 192.168.1.1 11000000.10101000.00000001.00000 001 > >> HostMax: 192.168.1.6 11000000.10101000.00000001.00000 110 > >> Broadcast: 192.168.1.7 11000000.10101000.00000001.00000 111 > >> Hosts/Net: 6 Class C, Private Internet > >> > >> Hope this makes sence. > >> > >> Regards, > >> > >> Bruce > >> > >> > >> > > > > > > ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 23, Issue 82 ************************************* From Valdis.Kletnieks at vt.edu Tue Dec 22 15:09:58 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Dec 2009 10:09:58 -0500 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: Your message of "Tue, 22 Dec 2009 07:42:18 CST." <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> Message-ID: <23123.1261494598@localhost> On Tue, 22 Dec 2009 07:42:18 CST, Jorge Amodio said: > http://www.whitehouse.gov/blog/2009/12/22/introducing-new-cybersecurity-coordinator/?e=23&ref=image "Meet the new boss / Same as the old boss" -- The Who, "Won't Get Fooled Again". Do we have any indication that anything has been changed this time around? Operational content: None, unless he's actually able to make things happen now, in which case things might get interesting... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brandon at shrader.net Tue Dec 22 15:44:09 2009 From: brandon at shrader.net (Brandon M. Lapointe) Date: Tue, 22 Dec 2009 09:44:09 -0600 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <23123.1261494598@localhost> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> Message-ID: <62B051F561B10F4897A7120430E590EE820870@SEC-EXCHANGE.shrader.net> Personally, I have been seeing much more of a substantive push in this arena than in times past, owing mostly to the large umbrella of the Department of Homeland Security. As an example here in Texas - municipal, county, and some state offices are requiring network engineers to be licensed SE's (Software Engineers) under the authority of the Texas Board of Professional Engineers. The language I have seen in policies published in the last 2 months requires that anyone programming, configuring, or commissioning routers or other network hardware that contain internal software systems carry that license. ...it seems that other states are preparing to adopt the SE license (likely not until the exam is completed) and I wouldn't be surprised if a "Cybersecurity Coordinator" required such a license Federally. http://www.tbpe.state.tx.us/swe/main.htm http://www.todaysengineer.org/2009/Sep/Software-PE.asp Brandon L. Technology Systems Director SHRADER ENGINEERING -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, December 22, 2009 9:10 AM To: Jorge Amodio Cc: NANOG Subject: Re: FYI, new USG Cybersecurity Coordinator ... On Tue, 22 Dec 2009 07:42:18 CST, Jorge Amodio said: > http://www.whitehouse.gov/blog/2009/12/22/introducing-new-cybersecurit > y-coordinator/?e=23&ref=image "Meet the new boss / Same as the old boss" -- The Who, "Won't Get Fooled Again". Do we have any indication that anything has been changed this time around? Operational content: None, unless he's actually able to make things happen now, in which case things might get interesting... From feamster at cc.gatech.edu Tue Dec 22 17:48:08 2009 From: feamster at cc.gatech.edu (Nick Feamster) Date: Tue, 22 Dec 2009 12:48:08 -0500 Subject: please help - survey on network operations costs Message-ID: <20091222174808.GO40180@cc.gatech.edu> Hello, We are developing a tool that helps ISPs optimize for cost when making decisions about both internal routing and interconnection for planning and traffic management. To develop the underlying algorithms, we need a better sense of how various factors contribute to an ISP's overall operational costs. Our objective is not to obtain specific numbers---we understand that individual ISPs may have very confidential information about pricing, and that you may not want to share that with us. Rather, we are seeking to build a model that any operator could use by plugging in specific numbers. Constructing this model still requires some understanding of the relative costs of various factors. We would appreciate any help you can provide. In return, we will (1) share the results of the survey with you (after anonymizing appropriately); (2) work with you to apply our optimization technique to your network to see if it can help reduce your overall costs. Thank you very much for any help you can provide, Nick and Murtaza ------------------------------------- 1. Are you a: * access ISP network * transit provider * content distribution network * other (please specify) 2. How do you account for recurring costs incurred in carrying IP traffic on your backbone? Do you incorporate both backhaul and interconnect costs? Which one of these factors tends to be more dominant? Are there other factors that are significant enough to consider explicitly? (If you have a template cost model, that would be very helpful.) 3. What are the relative costs of each of the following for interconnection? (If you feel comfortable doing so, please rank them.) * port/interface costs (e.g., 1G, 10G, etc.) * type of transmission (e.g., IP, WDM, SONET, etc.) * transit costs * others (please specify) 4. What factors affect internal network costs for carrying traffic? * port/interface costs * distance travelled (e.g., # of hops, geography - local, regional, backbone, trans-continental) * real estate costs (e.g., carrier hotel, fiber leasing...) * traffic demand or congestion in a region (e.g., is northeast corridor more expensive than other parts of the network?) * other (please specify) 5. When pricing your own IP connectivity services, do you use average cost models? Do you use the same cost structure for each customer, regardless of how much of your backbone and interconnect infrastructure they use? From jcdill.lists at gmail.com Tue Dec 22 18:03:03 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 22 Dec 2009 10:03:03 -0800 Subject: news from Google In-Reply-To: References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> Message-ID: <4B3109D7.1040604@gmail.com> Hank Nussbacher wrote: > > Google makes about $1.5B profit per quarter. $20M of charity? I > don't like MS any more than most, but Gates Foundation has received > $20B from Bill and Warren over the past 3 years. My hat goes off to > those guys! Yes, the Gates Foundation gives a lot of money to worthy causes, which is truly admirable. However, to put things into perspective let's take a look at the history of these two companies. Microsoft was founded 34 years ago (in 1975) and IPOd 23 years ago (in 1986). Bill Gates didn't start his foundation until 12 years after the IPO. Google was founded (incorporated) 11 years ago in 1998, IPOd 5 years ago in 2005. Google Foundation was created as part of the IPO: "a commitment to contribute significant resources, including 1% of Google's equity and profits in some form, as well as employee time, to address some of the world's most urgent problems. That commitment became a range of giving initiatives including Google.org." How much did Microsoft give to charity in 1991, 5 years after their IPO? Would you bet against a proposition that by 2028 the Google Foundation does just as much (or more) than the Gates foundation is doing today? jc From Valdis.Kletnieks at vt.edu Tue Dec 22 18:12:51 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Dec 2009 13:12:51 -0500 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: Your message of "Tue, 22 Dec 2009 09:44:09 CST." <62B051F561B10F4897A7120430E590EE820870@SEC-EXCHANGE.shrader.net> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> <62B051F561B10F4897A7120430E590EE820870@SEC-EXCHANGE.shrader.net> Message-ID: <9789.1261505571@localhost> On Tue, 22 Dec 2009 09:44:09 CST, "Brandon M. Lapointe" said: > municipal, county, and some state offices are requiring network > engineers to be licensed SE's (Software Engineers) under the authority > of the Texas Board of Professional Engineers. Except it's not actually very clear that Software Engineering has all that much to do with Network Engineering. You *writing* IOS code, or just *using* it? I suppose it's a start, anyhow. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From williams.bruce at gmail.com Tue Dec 22 18:19:38 2009 From: williams.bruce at gmail.com (Bruce Williams) Date: Tue, 22 Dec 2009 10:19:38 -0800 Subject: news from Google In-Reply-To: <4B3109D7.1040604@gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <4B3109D7.1040604@gmail.com> Message-ID: <775e001a0912221019h58c44aacn380e0d9d5582f886@mail.gmail.com> Bill Gates has made a commitment to basically give away all of his money and quit MS to devote full time to doing it. It will be a hard act to follow. On Tue, Dec 22, 2009 at 10:03 AM, JC Dill wrote: > Hank Nussbacher wrote: > >> >> Google makes about $1.5B profit per quarter. $20M of charity? I don't >> like MS any more than most, but Gates Foundation has received $20B from Bill >> and Warren over the past 3 years. My hat goes off to those guys! >> > > Yes, the Gates Foundation gives a lot of money to worthy causes, which is > truly admirable. > However, to put things into perspective let's take a look at the history of > these two companies. > > Microsoft was founded 34 years ago (in 1975) and IPOd 23 years ago (in > 1986). Bill Gates didn't start his foundation until 12 years after the IPO. > > Google was founded (incorporated) 11 years ago in 1998, IPOd 5 years ago in > 2005. Google Foundation was created as part of the IPO: "a commitment to > contribute significant resources, including 1% of Google's equity and > profits in some form, as well as employee time, to address some of the > world's most urgent problems. That commitment became a range of giving > initiatives including Google.org." > > How much did Microsoft give to charity in 1991, 5 years after their IPO? > Would you bet against a proposition that by 2028 the Google Foundation does > just as much (or more) than the Gates foundation is doing today? > jc > > > -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From morrowc.lists at gmail.com Tue Dec 22 18:21:36 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Dec 2009 13:21:36 -0500 Subject: news from Google In-Reply-To: <775e001a0912221019h58c44aacn380e0d9d5582f886@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <4B3109D7.1040604@gmail.com> <775e001a0912221019h58c44aacn380e0d9d5582f886@mail.gmail.com> Message-ID: <75cb24520912221021n4495cf06i737b221908cdea10@mail.gmail.com> On Tue, Dec 22, 2009 at 1:19 PM, Bruce Williams wrote: > Bill Gates has made a commitment to basically give away all of his money and > quit MS to devote full time to doing it. It will be a hard act to follow. this is all great stuff, but unrelated to network operations. Off to another list pls? Merry Xmas! :) -chris From jmamodio at gmail.com Tue Dec 22 19:04:04 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 22 Dec 2009 13:04:04 -0600 Subject: news from Google In-Reply-To: <75cb24520912221021n4495cf06i737b221908cdea10@mail.gmail.com> References: <200912141313.nBEDDt6n065490@aurora.sol.net> <202705b0912211224ya429553v4b2417d61da0464b@mail.gmail.com> <4B3109D7.1040604@gmail.com> <775e001a0912221019h58c44aacn380e0d9d5582f886@mail.gmail.com> <75cb24520912221021n4495cf06i737b221908cdea10@mail.gmail.com> Message-ID: <202705b0912221104n6c11ace0o332ae9b849cae43@mail.gmail.com> >> Bill Gates has made a commitment to basically give away all of his money and >> quit MS to devote full time to doing it. It will be a hard act to follow. > > this is all great stuff, but unrelated to network operations. Off to > another list pls? Unless the Gates Foundation and Google wish to substantially fund NANOG, *NOG & IETF, in that case I'd not mind talking about them until we ran out of space for IPv6 allocations :-) > Merry Xmas! :) Same -Jorge From fergdawgster at gmail.com Tue Dec 22 19:06:10 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 22 Dec 2009 11:06:10 -0800 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <23123.1261494598@localhost> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> Message-ID: <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 7:09 AM, wrote: > On Tue, 22 Dec 2009 07:42:18 CST, Jorge Amodio said: >> http://www.whitehouse.gov/blog/2009/12/22/introducing-new-cybersecurity- >> coordinator/?e=23&ref=image > > "Meet the new boss / Same as the old boss" -- The Who, "Won't Get Fooled > Again". > > Do we have any indication that anything has been changed this time > around? > > Operational content: None, unless he's actually able to make things > happen now, in which case things might get interesting... > As I mentioned elsewhere, nobody else wanted the job. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMRibq1pz9mNUZTMRArJuAKDcElO6p/ryPn3j4Y1Lf/2VHaNn/gCdHrvc Df8KQ0fyt4sgsSatiaL+CLk= =z7Df -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jlewis at lewis.org Tue Dec 22 21:24:26 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 22 Dec 2009 16:24:26 -0500 (EST) Subject: Article on spammers and their infrastructure In-Reply-To: <20091222102709.GD81417@macbook.catpipe.net> References: <20091222102709.GD81417@macbook.catpipe.net> Message-ID: On Tue, 22 Dec 2009, Phil Regnauld wrote: > http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 > > It this something new ? The article seems to mix various issues together. > And this would seem highly inefficient to me compared to traditional > botnets (renting your own rack for a botnet doesn't really make sense :) I don't see how going to jump.ro, getting a bunch of IP assignments, and then setting those IPs up on a server or few servers in the US = "attackers buying own data centers". I am curious how both jump.ro and the other RIPE region LIRs involved in assigning the space and the US based networks that have been involved routing it justify assigning/routing "Assigned PA" space to "customers" who only use that space in their US operations (which in the cases I've seen have primarily been high volume email deployment). According to http://www.ripe.net/ripe/docs/ipv4-policies.html ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Tue Dec 22 22:39:09 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Dec 2009 17:39:09 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> Message-ID: <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis wrote: > Should US based networks be willing to route RIPE "ASSIGNED PA" space > customers provide? this is an interesting question, which when I worked for an ISP I always wondered about. In fact, when we'd see solely based US customers asking for this sort of thing it often meant shortly there after we'd see complaints of TOS/AUP violations. There doesn't seem to be a hard/fast rule about this though (the 'is it right to permit this activity'), but there sure is quite a bit of it going on, eh? -Chris From joelja at bogus.com Tue Dec 22 22:54:45 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 22 Dec 2009 14:54:45 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> Message-ID: <4B314E35.9040508@bogus.com> Christopher Morrow wrote: > On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis wrote: > > >> Should US based networks be willing to route RIPE "ASSIGNED PA" space >> customers provide? Are any of your customers multinationals? > this is an interesting question, which when I worked for an ISP I > always wondered about. In fact, when we'd see solely based US > customers asking for this sort of thing it often meant shortly there > after we'd see complaints of TOS/AUP violations. There doesn't seem to > be a hard/fast rule about this though (the 'is it right to permit this > activity'), but there sure is quite a bit of it going on, eh? Last two companies I have worked with, through a combination of organic growth, aquistion and partnership have a rather complex mix of PA, Legacy, RIR assignments in 4 regions, LIR assignments, and so forth. it would be fairly normal in the course of service delivery to customers to advertise prefixes obtained in one region in one or more other regions. One of these entities has a global IP backbone, the other glues it altogether with vpns, appart from scale they're not really that different. > -Chris > From jlewis at lewis.org Tue Dec 22 23:36:04 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 22 Dec 2009 18:36:04 -0500 (EST) Subject: Article on spammers and their infrastructure In-Reply-To: <4B314E35.9040508@bogus.com> References: <20091222102709.GD81417@macbook.catpipe.net> <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> <4B314E35.9040508@bogus.com> Message-ID: On Tue, 22 Dec 2009, Joel Jaeggli wrote: >>> Should US based networks be willing to route RIPE "ASSIGNED PA" space >>> customers provide? > > Are any of your customers multinationals? They may be. I don't agree that it's relevant. You can disagree with the RIPE wording or with RIPE policies, or maybe I'm misinterpreting ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. My interpretation of the above is ASSIGNED PA is the equivalent of my assigning IP space to a customer who either buys transit (connectivity) from us or colo's or buys server hosting from us where they will use that IP space. We don't simply lease out IP space for "customers" to use as they please on other networks. We do have customers who are multihomed to whom we've assigned IP space, and they announce those IPs via BGP to us and other transit providers. What I've seen recently with jump.ro and other RIPE region LIRs looks like the LIRs are effectively selling/renting (whatever you want to call it) "ASSIGNED PA" IP space to spammers who announce it using single homed ASNs in the US. As an End User in the RIPE region, if you need/want PI space, are you not able to get that directly from RIPE? The previously mentioned page is confusing to me in its coverage of that question. The RIPE NCC no longer allocates PI address space. Consequently, many LIRs do not have PI allocations from which to make PI assignments. If an LIR has an End User that requires PI address space they are able to support them by sending these requests to the RIPE NCC on behalf of the End User. This support includes helping End Users prepare a properly documented request. The RIPE NCC will make PI assignments when justified. RIPE no longer allocates PI space. If an LIR has an End User that requires PI space and the LIR doesn't have any PI left to give out, they can help that End User apply to RIPE. This implies RIPE still does "assign" PI space to end users...and if you need PI IP space and are eligible to deal with RIPE, you should be getting it from them. So, if you're not multihomed with jump.ro as one of your providers, is it appropriate for them to sell you ASSIGNED PA space which you'll use elsewhere? I don't think so. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nick at foobar.org Wed Dec 23 00:03:33 2009 From: nick at foobar.org (Nick Hilliard) Date: Wed, 23 Dec 2009 00:03:33 +0000 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> <4B314E35.9040508@bogus.com> Message-ID: <4B315E55.6020304@foobar.org> On 22/12/2009 23:36, Jon Lewis wrote: > On Tue, 22 Dec 2009, Joel Jaeggli wrote: >> On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis wrote: >>>> Should US based networks be willing to route RIPE "ASSIGNED PA" space >>>> customers provide? I would argue not and the bofh in me would be inclined to announce more specifics if I saw someone announcing my PA space from another ASN. But I'm more into the ixp sort of thing these days rather than isps. > My interpretation of the above is ASSIGNED PA is the equivalent of my > assigning IP space to a customer who either buys transit (connectivity) > from us or colo's or buys server hosting from us where they will use > that IP space. ASSIGNED PA space is intended to be announced by the provider which operates the LIR only (i.e. the space is associated with the provider). It's not intended for multihoming, and if you want multihoming space, you need PI address space. > As an End User in the RIPE region, if you need/want PI space, are you > not able to get that directly from RIPE? You can get it directly from the RIPE NCC, but it's more usual to get it via your provider's LIR, the important word being "via". The LIR just passes on your request form. The RIPE NCC is very specific about the language used here. In the context of all RIPE docs and policies, "allocate" means to bulk-delegate resources to a LIR. "assign" is the process of delegating the address space to the end-user, whether that end-user is a customer or the provider itself. So, when the RIPE NCC says: > The RIPE NCC no longer allocates PI address space. ... what they mean is that they no longer delegate bulk blocks of PI address space to LIRs so that the LIR can then assign the address space to end-users. Instead, what happens these days is: > [...]The RIPE NCC will make PI assignments when justified. i.e. if you want a PI block, you fill out a form, send it to your LIR, who sends it to the RIPE NCC. The NCC will then register the address space to the end-user. > So, if you're not multihomed with jump.ro as one of your providers, is > it appropriate for them to sell you ASSIGNED PA space which you'll use > elsewhere? I don't think so. it is completely inappropriate at many levels - imo. Nick From leo.vegoda at icann.org Wed Dec 23 00:25:43 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 22 Dec 2009 16:25:43 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: Message-ID: On 22/12/2009 3:36, "Jon Lewis" wrote: [...] > They may be. I don't agree that it's relevant. You can disagree with the > RIPE wording or with RIPE policies, or maybe I'm misinterpreting > > ASSIGNED PA: This address space has been assigned to an End User for use > with services provided by the issuing LIR. It cannot be kept when > terminating services provided by the LIR. > > My interpretation of the above is ASSIGNED PA is the equivalent of my > assigning IP space to a customer who either buys transit (connectivity) > from us or colo's or buys server hosting from us where they will use that > IP space. We don't simply lease out IP space for "customers" to use as > they please on other networks. I am sure that your interpretation was the original intent of the policy text. However, the wording could also be read in a way that allows an LIR to just provide registry services, without providing any connectivity services. Regards, Leo From andrew.wallace at rocketmail.com Wed Dec 23 00:33:46 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 23 Dec 2009 00:33:46 +0000 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> Message-ID: <4b6ee9310912221633w45ef9a59rf419956c18a0b3cd@mail.gmail.com> On Tue, Dec 22, 2009 at 7:06 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Dec 22, 2009 at 7:09 AM, ? wrote: > >> On Tue, 22 Dec 2009 07:42:18 CST, Jorge Amodio said: >>> http://www.whitehouse.gov/blog/2009/12/22/introducing-new-cybersecurity- >>> coordinator/?e=23&ref=image >> >> "Meet the new boss / Same as the old boss" -- The Who, "Won't Get Fooled >> Again". >> >> Do we have any indication that anything has been changed this time >> around? >> >> Operational content: None, unless he's actually able to make things >> happen now, in which case things might get interesting... >> > > As I mentioned elsewhere, nobody else wanted the job. :-) > > - - ferg I'm sure Gadi Evron wanted it--- except he used to work for Israel Defence Force (IDF, Military Intelligence) http://www.linkedin.com/in/gadievron and knew he would be denied. Also, Marcus Sachs probably wanted it. Both are power hungry morons in the Cybersecurity realm respected by little but no people. But as Marcus Sachs already states on SANS ISC, http://isc.sans.org/diary.html?storyid=7792 he is friends with Howard Schmidt "I've known and worked with Howard for over 12 years and I think he's going to do well in this position." Yeah I bet he will--- with you and Gadi telling him what to do behind the scenes. Israel and Pakistan working Howard Schmidt by the strings. So even though Gadi is Israeli and Marcus Sachs Pakistani and couldn't be appointed as cybersecurity czar, they both are going to be working the strings attached to the puppet show that is about to commence in 2010. Just when we thought we might have a Cybersecurity czar not related to Marcus Sachs and Gadi Evron, the White House let's us down again, and the circle of power continues, the ring of evil that is Gadi and Marcus, both with connections to foreign Intelligence agency's and working the strings of the new Cybersecurity puppet. Anybody who is 12 years friends with Marcus Sachs shouldn't of been appointed in my humble opinion, and we know Gadi is best friends with Marcus Sachs, so we are all pretty much doomed to failure, as we all know Marcus and Gadi have a pro-cyber war agenda and will try and ramp it up to Howard Schmidt from behind the scenes. While folks said no one wanted the job, thats correct, but what will be happening now, is a lot of folks who are power hungry trying to influence Howard Schmidt for their own agendas from behind closed doors. The power hungry's will now be jockeying for position behind the scenes, to influence and manipulate the new Cybersecurity czar for their own agendas, and unless Howard Schmidt is on the ball and aware of this he's going to be used and abused by everybody and he and the White House will be taken for a ride because all the interest groups with their own cybersecurity agendas are going to want to exploit Howard Schmidt, and not all of this might be in the best interests of the United States. The United States will need to be careful who gets access to Howard Schmidt, who is friends with Howard Schmidt and who might be trying to manipulate and play him. We are living in dangerous times, unless the new cybersecurity czar is managed properly. There are people out there, just two of them mentioned above, who are pro-cyber war and will want access to Howard Schmidt and they should be denied access to him, because we don't want Howard Schmidt to be told the wrong things, that relayed back to Obama and the wrong cyber political messages being said on television by Obama. I'm not worried, i'm very worried about who has access to Howard Schmidt. From gbonser at seven.com Wed Dec 23 01:44:56 2009 From: gbonser at seven.com (George Bonser) Date: Tue, 22 Dec 2009 17:44:56 -0800 Subject: IPv6 allocations, deaggregation, etc. Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> We have decided to initiate the process of becoming IPv6 capable. We have requested and received a block of addresses which, after reading some of the discussion here, I fear may be too small to suit our needs (a /48). To better understand how to proceed and in an attempt to get it right (or close to right) the first time, I am soliciting opinions and comments from other network operators. It appears from earlier discussions on this list that while many networks will not filter a /48 announcement in their routing tables, others will. We have data centers and offices in three regions of the globe; North America, Europe, and Asia/Pacific. We are also multihomed as well as having some direct peering. I can break my /48 into /56 nets for each facility. My thought process here being that if I have the same transit providers at all sites, I can announce the /48 from my primary location and that would get announced by the transit provider. They would also accept my more specific routes but not announce them outside of their AS. So traffic originating outside of my transit provider would flow toward them following the /48 and they then move the traffic to the final destination based on the more specific and in the case the traffic has no more specific route, hand the traffic to my main location for me to sort out or just black hole it. There are two problems with this approach. 1: We are unreachable from anyone filtering a /48 and 2: I could see a situation where traffic crosses the Pacific, is handed to my transit provider, and then crosses the Pacific again to get to the destination resulting in poor performance. So it now seems to me that maybe a larger block might be the best answer but being an "end user" the policies seem pretty restrictive on getting a /32 though I might qualify for several /48 blocks (at least one in each registry region). So how does one reconcile having a diverse, multihomed organization on several continents while at the same time trying to do the right thing, not requesting more resources than we need, and trying to be friendly to the various networks' operations by advertizing only what we need to? Is it unreasonable to get separate /48 blocks for operations in Europe, North America, and Asia or possibly two for Asia (one in China and one for Asia outside of China)? While that still won't help us with connectivity from networks filtering /48's, it might relieve much of the back and forth transit across oceans to get traffic originating from and destined for the same continent to stay there. I don't have a problem with regional backhaul tying an office /56 to a data center announcing a /48 and using that data center as a communications hub for the region. It also assumes a transit provider I am paying to haul my traffic will take "more specifics" for internal use even if they aren't advertizing them. I am just trying to minimize the stupidity and barriers to scale on my side of the equation. From ops.lists at gmail.com Wed Dec 23 01:53:21 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 23 Dec 2009 07:23:21 +0530 Subject: Article on spammers and their infrastructure In-Reply-To: <4B314E35.9040508@bogus.com> References: <20091222102709.GD81417@macbook.catpipe.net> <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> <4B314E35.9040508@bogus.com> Message-ID: On Wed, Dec 23, 2009 at 4:24 AM, Joel Jaeggli wrote: > Christopher Morrow wrote: >> On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis wrote: >> >> >>> Should US based networks be willing to route RIPE "ASSIGNED PA" space >>> customers provide? > > Are any of your customers multinationals? What would you do if a shell company (the european equivalent of a LLC with a UPS store address) came to you with a large sized PA netblock from out of region, and asked you to route it for them? -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanog at daork.net Wed Dec 23 02:33:56 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 23 Dec 2009 15:33:56 +1300 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> Message-ID: The assumption that networks will filter /48s is not the whole story. The RIRs giving out /48s do so from a single pool that only contains / 48 assignments. The RIRs give out /32s from a pool containing /32 or shorter prefixes (ie /31, /30, etc. etc). You will find that most networks filtering /48s allow them from the pool with only /48s in it. The root DNS servers are in /48s. If you can justify getting a /32, then I suggest you do so, but if not then don't worry, a /48 will work just fine. The networks that do filter you will pretty soon adapt I expect. Insert routing table explosion religious war here, with snipes from people saying that we need a new routing system, etc. etc. So with that in mind, do your concerns from your original post still make sense? -- Nathan Ward From gbonser at seven.com Wed Dec 23 02:52:01 2009 From: gbonser at seven.com (George Bonser) Date: Tue, 22 Dec 2009 18:52:01 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7104@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Nathan Ward [mailto:nanog at daork.net] > Sent: Tuesday, December 22, 2009 6:34 PM > To: nanog at nanog.org > Subject: Re: IPv6 allocations, deaggregation, etc. > > The assumption that networks will filter /48s is not the whole story. ... > You will find that most networks filtering /48s allow them from the > pool with only /48s in it. That makes perfect sense. > If you can justify getting a /32, then I suggest you do so, but if not > then don't worry, a /48 will work just fine. The networks that do > filter you will pretty soon adapt I expect. I can't in good conscience justify a /32. That is just too much space. I believe I can, however, justify a separate /48 in Europe and APAC with my various offices and data centers in that region coming from the /48 for that region. > Insert routing table explosion religious war here, with snipes from > people saying that we need a new routing system, etc. etc. Eh, it isn't so bad. I could think of some ways things could have been better (e.g. providers use a 32bit ASN as the prefix with a few "magic" destination prefixes for multicast, anycast, futurecast and multihomed end users use a 16-bit regional prefix with a 16-bit ASN as a 32-bit prefix) but we are too far down the road to complain too much about that sort of stuff. > So with that in mind, do your concerns from your original post still > make sense? Thanks, Nathan, and let's say that I am somewhat less apprehensive than I was. George From cabenth at gmail.com Wed Dec 23 02:54:55 2009 From: cabenth at gmail.com (eric clark) Date: Tue, 22 Dec 2009 18:54:55 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> Message-ID: <5b602b520912221854u7889e1dm3c3c7f91976acffe@mail.gmail.com> I'm not an expert, but can/should you advertise ARIN IP space on APNIC or RIPE, etc ? You are talking about having recieved ip space from ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of form than anything else though..... On Tuesday, December 22, 2009, Nathan Ward wrote: > The assumption that networks will filter /48s is not the whole story. > > The RIRs giving out /48s do so from a single pool that only contains /48 assignments. > The RIRs give out /32s from a pool containing /32 or shorter prefixes (ie /31, /30, etc. etc). > > You will find that most networks filtering /48s allow them from the pool with only /48s in it. > > The root DNS servers are in /48s. > > If you can justify getting a /32, then I suggest you do so, but if not then don't worry, a /48 will work just fine. The networks that do filter you will pretty soon adapt I expect. > > Insert routing table explosion religious war here, with snipes from people saying that we need a new routing system, etc. etc. > > So with that in mind, do your concerns from your original post still make sense? > > -- > Nathan Ward > > From nanog at daork.net Wed Dec 23 03:02:12 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 23 Dec 2009 16:02:12 +1300 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7104@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F7104@RWC-EX1.corp.seven.com> Message-ID: <0F642055-B89E-4A4B-BB83-7570FC51670B@daork.net> On 23/12/2009, at 3:52 PM, George Bonser wrote: >> If you can justify getting a /32, then I suggest you do so, but if >> not >> then don't worry, a /48 will work just fine. The networks that do >> filter you will pretty soon adapt I expect. > > I can't in good conscience justify a /32. That is just too much > space. > I believe I can, however, justify a separate /48 in Europe and APAC > with > my various offices and data centers in that region coming from the /48 > for that region. I'm not sure it's about good conscience and worrying about address space wastage anymore. I mean sure, don't go ask for a /8 or something, but follow the RIR guidelines - don't paint yourself in to a corner later by trying to save the world now. If you are assigning addresses to customers, you should have a /32 allocation. If you are an end user of addresses, you should have a /48 portable assignment. In APNIC world anyway, I'm not sure of the terms and policies used in other regions. -- Nathan Ward From sronan at fattoc.com Wed Dec 23 03:04:25 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 22 Dec 2009 22:04:25 -0500 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5b602b520912221854u7889e1dm3c3c7f91976acffe@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <5b602b520912221854u7889e1dm3c3c7f91976acffe@mail.gmail.com> Message-ID: > I'm not an expert, but can/should you advertise ARIN IP space on APNIC > or RIPE, etc ? You are talking about having recieved ip space from > ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of > form than anything else though..... This happens all the time with IPv4 space and AS #'s today, why would it be any different with v6? From nanog at daork.net Wed Dec 23 03:07:41 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 23 Dec 2009 16:07:41 +1300 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <5b602b520912221854u7889e1dm3c3c7f91976acffe@mail.gmail.com> Message-ID: On 23/12/2009, at 4:04 PM, Shane Ronan wrote: >> I'm not an expert, but can/should you advertise ARIN IP space on >> APNIC >> or RIPE, etc ? You are talking about having recieved ip space from >> ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of >> form than anything else though..... > > This happens all the time with IPv4 space and AS #'s today, why > would it be any different with v6? It's not. -- Nathan Ward From gbonser at seven.com Wed Dec 23 03:07:46 2009 From: gbonser at seven.com (George Bonser) Date: Tue, 22 Dec 2009 19:07:46 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5b602b520912221854u7889e1dm3c3c7f91976acffe@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <5b602b520912221854u7889e1dm3c3c7f91976acffe@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7105@RWC-EX1.corp.seven.com> > -----Original Message----- > From: eric clark > I'm not an expert, but can/should you advertise ARIN IP space on APNIC > or RIPE, etc ? You are talking about having recieved ip space from > ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of > form than anything else though..... That is what prompted me to say that I could probably justify a /48 in each region out of that region's registry. We have legitimate business operations in those regions so having an AS and IP block for those regions should not only be justifiable but also would tend to make things "cleaner". From ALanstein at FireEye.com Wed Dec 23 04:58:51 2009 From: ALanstein at FireEye.com (Alex Lanstein) Date: Tue, 22 Dec 2009 20:58:51 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net>, Message-ID: <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> I might as well reply to this here. The folks from threatpost had me talk at length about the various issues with doing cybercrime enforcement and how things have changed, and they picked that section for their post. My key point I wanted to hammer home was that most of the modern botnets (and/or malware that has phone home capability) have a much more stable infrastructure, as more and more of the hosting pieces are controlled by the bad guys. In the old days you'd see C&C servers running from popped boxes, but now you're seeing the criminals renting their own servers from xyz datacenter, or worse, buying their own racks/cages and going to an LIR or RIR to get direct IP allocations. They then rent out those allocations to other shell companies (or possibly to other criminals) and handle the abuse notifications on the frontend. Since these data centers have many transit options, nullrouting an ip block at a single ISP hasn't been very effective. And of course, getting an RIR to revoke IP space only happens if you don't pay the bills. A year after allocation the blocks are pretty much burned anyways, so that's not a real barrier. There doesn't even seem to be any policies against intentional fraudulent SWIPing of IP space, or at least, not one that's enforced. The Knujon guys have had some success in the domain space, maybe this could happen in the ip world as well? The only technical statement in there that I think was misinterpreted was the "owning your own ip space makes you an isp" which I clearly didn't mean. It's a quote so I must have said it but it must I think I had some qualifiers in there in that I was talking about the abuse desks at an ISP. If they are the ISP they claim it was a downstream customer and that they've fixed the issue, when really it's their own stuff that they shuffle around. Regards, Alex Lanstein ________________________________________ From: Jon Lewis [jlewis at lewis.org] Sent: Tuesday, December 22, 2009 4:24 PM To: Phil Regnauld Cc: nanog at nanog.org Subject: Re: Article on spammers and their infrastructure On Tue, 22 Dec 2009, Phil Regnauld wrote: > http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 > > It this something new ? The article seems to mix various issues together. > And this would seem highly inefficient to me compared to traditional > botnets (renting your own rack for a botnet doesn't really make sense :) I don't see how going to jump.ro, getting a bunch of IP assignments, and then setting those IPs up on a server or few servers in the US = "attackers buying own data centers". I am curious how both jump.ro and the other RIPE region LIRs involved in assigning the space and the US based networks that have been involved routing it justify assigning/routing "Assigned PA" space to "customers" who only use that space in their US operations (which in the cases I've seen have primarily been high volume email deployment). According to http://www.ripe.net/ripe/docs/ipv4-policies.html ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From joelja at bogus.com Wed Dec 23 05:16:38 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 22 Dec 2009 21:16:38 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> Message-ID: <4B31A7B6.4000304@bogus.com> George Bonser wrote: > We have decided to initiate the process of becoming IPv6 capable. We > have requested and received a block of addresses which, after reading > some of the discussion here, I fear may be too small to suit our needs > (a /48). To better understand how to proceed and in an attempt to get > it right (or close to right) the first time, I am soliciting opinions > and comments from other network operators. Given you topology your direct assignment request should properly reflect the number of sites you expect to need to need to serve. At a /48 per site it starts to look rational. > It appears from earlier discussions on this list that while many > networks will not filter a /48 announcement in their routing tables, > others will. We have data centers and offices in three regions of the > globe; North America, Europe, and Asia/Pacific. We are also multihomed > as well as having some direct peering. I can break my /48 into /56 nets > for each facility. My thought process here being that if I have the > same transit providers at all sites, I can announce the /48 from my > primary location and that would get announced by the transit provider. > They would also accept my more specific routes but not announce them > outside of their AS. So traffic originating outside of my transit > provider would flow toward them following the /48 and they then move the > traffic to the final destination based on the more specific and in the > case the traffic has no more specific route, hand the traffic to my main > location for me to sort out or just black hole it. There are two > problems with this approach. 1: We are unreachable from anyone > filtering a /48 and 2: I could see a situation where traffic crosses the > Pacific, is handed to my transit provider, and then crosses the Pacific > again to get to the destination resulting in poor performance. > > So it now seems to me that maybe a larger block might be the best answer > but being an "end user" the policies seem pretty restrictive on getting > a /32 though I might qualify for several /48 blocks (at least one in > each registry region). So how does one reconcile having a diverse, > multihomed organization on several continents while at the same time > trying to do the right thing, not requesting more resources than we > need, and trying to be friendly to the various networks' operations by > advertizing only what we need to? Is it unreasonable to get separate > /48 blocks for operations in Europe, North America, and Asia or possibly > two for Asia (one in China and one for Asia outside of China)? While > that still won't help us with connectivity from networks filtering > /48's, it might relieve much of the back and forth transit across oceans > to get traffic originating from and destined for the same continent to > stay there. I don't have a problem with regional backhaul tying an > office /56 to a data center announcing a /48 and using that data center > as a communications hub for the region. It also assumes a transit > provider I am paying to haul my traffic will take "more specifics" for > internal use even if they aren't advertizing them. > > I am just trying to minimize the stupidity and barriers to scale on my > side of the equation. > > From morrowc.lists at gmail.com Wed Dec 23 05:48:54 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Dec 2009 00:48:54 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: <4B315E55.6020304@foobar.org> References: <20091222102709.GD81417@macbook.catpipe.net> <75cb24520912221439x1d254088r66e3a28571ae8124@mail.gmail.com> <4B314E35.9040508@bogus.com> <4B315E55.6020304@foobar.org> Message-ID: <75cb24520912222148u30d51ecfm897ae2da2b6ecc0@mail.gmail.com> On Tue, Dec 22, 2009 at 7:03 PM, Nick Hilliard wrote: > On 22/12/2009 23:36, Jon Lewis wrote: >> So, if you're not multihomed with jump.ro as one of your providers, is 'multihomed' here could mean: "we have an IPSEC vpn, we need to use globally unique ip space, we may have exit points (and have space routed by other providers from this block), but we'll anchor things here in your datacenter in elbonia, ok?" >> it appropriate for them to sell you ASSIGNED PA space which you'll use >> elsewhere? ?I don't think so. 'sell you ASSIGNED PA' or 'Assign to you as a customer ASSIGNED PA' ? (cause 'selling ip space' is still officially verboten, eh?) > it is completely inappropriate at many levels - imo. agreed, it's at least a management headache, and aside from very obvious large multi-nationals (joel's examples) every time I've seen it done it was by 'bad actors'... In fact I think I had a conversation with an install engineer that went something like: "You really thought ip space assigned to a ukranian company in the ukraine was 'ok' for you to route to a customer in tampa, fla??" :( -chris From fergdawgster at gmail.com Wed Dec 23 06:12:44 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 22 Dec 2009 22:12:44 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> Message-ID: <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 8:58 PM, Alex Lanstein wrote: > I might as well reply to this here. The folks from threatpost had me > talk at length about the various issues with doing cybercrime enforcement > and how things have changed, and they picked that section for their post. > > My key point I wanted to hammer home was that most of the modern botnets > (and/or malware that has phone home capability) have a much more stable > infrastructure, as more and more of the hosting pieces are controlled by > the bad guys. > > In the old days you'd see C&C servers running from popped boxes, but now > you're seeing the criminals renting their own servers from xyz > datacenter, or worse, buying their own racks/cages and going to an LIR or > RIR to get direct IP allocations. They then rent out those allocations > to other shell companies (or possibly to other criminals) and handle the > abuse notifications on the frontend. Since these data centers have many > transit options, nullrouting an ip block at a single ISP hasn't been very > effective. And of course, getting an RIR to revoke IP space only happens > if you don't pay the bills. A year after allocation the blocks are > pretty much burned anyways, so that's not a real barrier. There doesn't > even seem to be any policies against intentional fraudulent SWIPing of IP > space, or at least, not one that's enforced. The Knujon guys have had > some success in the domain space, maybe this could happen in the ip world > as well? > > The only technical statement in there that I think was misinterpreted was > the "owning your own ip space makes you an isp" which I clearly didn't > mean. It's a quote so I must have said it but it must I think I had some > qualifiers in there in that I was talking about the abuse desks at an > ISP. If they are the ISP they claim it was a downstream customer and > that they've fixed the issue, when really it's their own stuff that they > shuffle around. > Not that I need to do so, but I might as well -- I know Alex pretty well, as both a trusted colleague & friend, and he is spot on in his assessment here. If anything, he was mild in his criticizes -- this type of criminal "diversification" has been the standard bat-and-switch method of operation for several years now. The criminals -- especially the professional Eastern Europeans -- have become quite adept in their campaigns of registering domains, obtaining IP address space, hosting facilities, etc., and are quite successful in their criminal endeavors. Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMbTTq1pz9mNUZTMRAvd8AJ0b/EY2TtqYKRqzsxxGr9GzG4TElgCgotLP TYjuUwZjUYGRM+WLzwhDHRI= =L6n9 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From morrowc.lists at gmail.com Wed Dec 23 06:58:47 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Dec 2009 01:58:47 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> Message-ID: <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Folks should not be so obtuse about these activities. It's almost blatantly > in-your-face, so to speak. These guys have no fear of retribution. no real arguement, but... 'please provide some set of workable solutions' The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome. -Chris From fergdawgster at gmail.com Wed Dec 23 07:05:50 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 22 Dec 2009 23:05:50 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> Message-ID: <6cd462c00912222305t49a5e794o4ca9bdee5196e486@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 10:58 PM, Christopher Morrow wrote: > On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson > wrote: >> Folks should not be so obtuse about these activities. It's almost >> blatantly in-your-face, so to speak. These guys have no fear of >> retribution. > > no real arguement, but... 'please provide some set of workable solutions' > First question: Solution(s) for which problem(s)? > The ARIN meetings (at least) are open, please come and help guide > policies. I'm sure RIPE also wouldn't mind a discussion, if there > could be some positive policy outcome. > Frankly, there simply is not enough hours in the day for what I already do, and trying to add "policy foo" to my laundry list of stuff just isn't going to happen. Many of us have already tried to engage ICANN on domain registration issues (primarily bad registrars and policy cruft), as well as RIRs, etc., to no avail. I've simply given up on trying to make a dent in policy issues because profit trumps everything else, plus -- as I said -- I just have no spare cycles. I have taken a different set of tactics to go after criminal activities... policy stuff doesn't work. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMcFKq1pz9mNUZTMRAjT1AJ9WqMg2UdT+KofRNxCMoKmIscGG0ACfe9h7 zlj1GwsVogB4xfmPsBYxTZ8= =vBkP -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From morrowc.lists at gmail.com Wed Dec 23 07:14:38 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Dec 2009 02:14:38 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: <6cd462c00912222305t49a5e794o4ca9bdee5196e486@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <6cd462c00912222305t49a5e794o4ca9bdee5196e486@mail.gmail.com> Message-ID: <75cb24520912222314i58ec8bd3g3a6f36b0a055ad75@mail.gmail.com> On Wed, Dec 23, 2009 at 2:05 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Dec 22, 2009 at 10:58 PM, Christopher Morrow > wrote: > >> On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson >> wrote: > >>> Folks should not be so obtuse about these activities. It's almost >>> blatantly in-your-face, so to speak. These guys have no fear of >>> retribution. >> >> no real arguement, but... 'please provide some set of workable solutions' >> > > First question: Solution(s) for which problem(s)? ideally the 'bad folks get ip space' (which was part of the initial thrust of the thread) > Many of us have already tried to engage ICANN on domain registration issues > (primarily bad registrars and policy cruft), as well as RIRs, etc., to no > avail. some headway was made, some more may still come. It's certainly not 'fast' though :( > I've simply given up on trying to make a dent in policy issues because > profit trumps everything else, plus -- as I said -- I just have no spare > cycles. If the, for the ip space issue, main problem can't be solved without policy this seems like abdication, no? > > I have taken a different set of tactics to go after criminal activities... > policy stuff doesn't work. also good... except that the only real fix for some of this is policy things, I fear. IP-address issues can't get solved without policy changes, which happen today via community consensus. Domain-name issues have to get hammered out from the top down (with some policy that allows registries to impose change on registrars. This DNS issues may also get resolved with action coming from ICANN (hope springs eternal). -Chris From morrowc.lists at gmail.com Wed Dec 23 07:19:17 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Dec 2009 02:19:17 -0500 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <4b6ee9310912221633w45ef9a59rf419956c18a0b3cd@mail.gmail.com> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> <4b6ee9310912221633w45ef9a59rf419956c18a0b3cd@mail.gmail.com> Message-ID: <75cb24520912222319q73a28aa2h80b1b79873b2e3b8@mail.gmail.com> (again, this seems really off topic, but) On Tue, Dec 22, 2009 at 7:33 PM, andrew.wallace wrote: > though Gadi is Israeli and Marcus Sachs Pakistani and couldn't be marcus is pakistani? From fergdawgster at gmail.com Wed Dec 23 07:26:48 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 22 Dec 2009 23:26:48 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <75cb24520912222314i58ec8bd3g3a6f36b0a055ad75@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <6cd462c00912222305t49a5e794o4ca9bdee5196e486@mail.gmail.com> <75cb24520912222314i58ec8bd3g3a6f36b0a055ad75@mail.gmail.com> Message-ID: <6cd462c00912222326p46636a50v3a6d552bb6fa90ce@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 11:14 PM, Christopher Morrow wrote: > > IP-address issues can't get solved without policy changes, which > happen today via community consensus. Domain-name issues have to get > hammered out from the top down (with some policy that allows > registries to impose change on registrars. This DNS issues may also > get resolved with action coming from ICANN (hope springs eternal). > Well, I have to say I'm somewhat pessimistic that ICANN really cares about what security issues evolve from their "policy" failures. If history is any lesson, it should teach us that ICANN cares more about expanding the TLD space to the point where it can be abused infinitely. Having said that, ICANN is not IANA, and the last time I checked, IANA had some measure of influence in the policies that the RIRs operated within... or is that the role of yet another level of obfuscation (policy authority)? I think you see my point... It's just unworkable as things stand, and rife with abuse -- the policy loopholes allow these commercial entities to reap the benefits of huge profits, while allowing criminals to also share in the same benefits. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMcYzq1pz9mNUZTMRAlA2AKCF5tVTxd6RCBDjsbti2PEfRjBdoACgwJ8a Z59NZBLXg2oh7+EDI+MQQEU= =zCON -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From gbonser at seven.com Wed Dec 23 08:31:05 2009 From: gbonser at seven.com (George Bonser) Date: Wed, 23 Dec 2009 00:31:05 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <3caba1f60912222242n111fd475yb8d47eb2dafe0a3c@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <4B31A7B6.4000304@bogus.com> <3caba1f60912222242n111fd475yb8d47eb2dafe0a3c@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7107@RWC-EX1.corp.seven.com> Apologies in advance for the top post. My initial idea was to use a /48, divide it up into /56 nets for each facility with /64 subnets within each facility. We would announce a /48 to our transit providers that I would expect them to announce in turn to their peers and we would also announce the more specific /56 nets to the transit providers that I would expect them not to announce to their peers. My current vlan requirements per facility would support such an addressing plan. In order to make that work, we would need the same transit providers in each region as our locations are not meshed internally. We don?t have dedicated connectivity from the US to the UK or China, for example. Currently that is not a problem as far as connectivity is concerned as my US providers appear in Europe and my China provider appears in the US. BUT when I consider the possibilities of South America and Africa and finding a transit provider that has a robust presence everywhere, my choices are very limited. I need to be multihomed and I need to be provider agnostic in my addressing. Using that scheme above does create some potential performance issues. While my transit provider collects the traffic from a remote location and routes it to the more specific location in my network, If a provider in Europe, for example, sees only the /48 announced from the US, maybe they haul the traffic across an ocean to a point where they peer with my provider ? who then must haul it back to Europe to the /56 corresponding to the destination because the original traffic source doesn?t see my /56 unless they are using the same transit provider I am. Then based on earlier discussion on the list a while back, I was concerned that a /48 wasn?t even enough to get me connected to some nets that were apparently filtering smaller than a /48 but my mind is somewhat eased in that respect and I believe that a /48 announced from space where /48s are issued will be accepted by most people. Then I was informed of ARIN 2009-5 which seems aimed at our situation; data centers widely separated by large geographical distances that are fairly autonomous and aren?t directly connected by dedicated links. It now seems that we (and the rest of the Internet) might be better served if we get a RIPE AS and net block for our Europe operations, and APNIC AS and net block for our APAC operations and get a regional /48 that I can split into /56 nets for the various satellite facilities within that region as those satellite offices CAN be directly connected to the regional data center which would act as the regional communications hub. There are probably 16 different ways to slice this but I would like to get it as close to ?right? as possible to prevent us having to renumber later while at the same time not taking more space than we need. A /48 per region seems like the right way to go at the present time. So we would have a /48 for the US, a /48 for Asia (and possibly one /48 dedicated to China) and a /48 for Europe. Satellite facilities would collect a /56 (or two or three) out of that regional block for their local use. Then I am free from being nailed to the same providers globally and have less chance of traffic crossing an ocean twice. The probability of needing 200 /48s in the next several years is pretty slim and do not warrant our getting a /32 when currently three or four /48 nets will fill the requirements. Thanks again for the input, Mick. George From: Mick O'Rourke [mailto:mkorourke at gmail.com] Sent: Tuesday, December 22, 2009 10:43 PM To: Joel Jaeggli Cc: George Bonser; nanog at nanog.org Subject: Re: IPv6 allocations, deaggregation, etc. Is the idea behind the /48 being looked at (keeping in mind a mixed IPv4/IPv6 environment & http://www.ietf.org/rfc/rfc5375.txt page 8) to have a /64 per smaller branch or VLAN, larger campus /56, and advertise out the /48 for the region?; My previous thinking and biggest thinking point is enterprise level address allocation policy, impacts to device loopbacks, voice vlans, operational simplification requirements for management and security layers etc. The feel overall has been towards needing to have a /32, a /56 per site (campus to small branch) and internally within the site /64 per VLAN. A /48 becomes too small, a /32 very much borderline. Is this a similar scenario for you? How are you justifying a /48 vs a /32? From brandon.galbraith at gmail.com Wed Dec 23 09:10:39 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 23 Dec 2009 03:10:39 -0600 Subject: Experiences with Comcast Ethernet/Transit service Message-ID: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> We're looking at using Comcast's (business) transit and private ethernet services at several client locations and I wanted to see what experiences others have had regarding this. Off-list replies are preferred. Thanks, -brandon -- Brandon Galbraith Mobile: 630.400.6992 From sean-list at head-net.com Wed Dec 23 09:57:01 2009 From: sean-list at head-net.com (Sean Head) Date: Wed, 23 Dec 2009 01:57:01 -0800 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> Message-ID: <4B31E96D.9050708@head-net.com> I just started looking into them as well. Mind of I has for similar info? (maybe just keep the responses on list?) -Sean On 2009.12.23 01:10:39, Brandon Galbraith wrote: > We're looking at using Comcast's (business) transit and private ethernet > services at several client locations and I wanted to see what experiences > others have had regarding this. Off-list replies are preferred. > > Thanks, > -brandon > From takashi at cpqd.com.br Wed Dec 23 11:39:32 2009 From: takashi at cpqd.com.br (Takashi Tome) Date: Wed, 23 Dec 2009 09:39:32 -0200 Subject: [NANOG] Roport on internet business Message-ID: Hi All Morgan Stanley has released a very interesting report on internet business with some tips to net operators: http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html Regards Takashi Tome CPqD www.cpqd.com.br From glen.kent at gmail.com Wed Dec 23 11:41:12 2009 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 23 Dec 2009 17:11:12 +0530 Subject: IGMP and PIM protection Message-ID: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> Hi, Any idea if folks use AH or ESP to protect IGMP/PIM packets? Wondering that if they do, then how would snooping switches work? Affably, Kent From rsk at gsp.org Wed Dec 23 11:57:22 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 23 Dec 2009 06:57:22 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> Message-ID: <20091223115722.GA9111@gsp.org> On Wed, Dec 23, 2009 at 01:58:47AM -0500, Christopher Morrow wrote: > no real arguement, but... 'please provide some set of workable solutions' The set of workable solutions at this point looks something like "null routes, firewall rules, blacklist entries" -- in order to deny traffic to and from such locales. I agree just about entirely with Ferg: the policy angle is a dead end. The organizations involved are either clueless or entirely focused on other goals (e.g., profit) at the expense of sound policy. ---Rsk From peter.hicks at poggs.co.uk Wed Dec 23 12:26:22 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Wed, 23 Dec 2009 12:26:22 +0000 Subject: IGMP and PIM protection In-Reply-To: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> Message-ID: <4B320C6E.5040105@poggs.co.uk> Glen Kent wrote: > Any idea if folks use AH or ESP to protect IGMP/PIM packets? Wondering > that if they do, then how would snooping switches work? > Would encrypting multicast not fundamentally break the concept of multicast itself, unless you're encrypting multicast traffic over a backbone? Peter From thegameiam at yahoo.com Wed Dec 23 13:06:34 2009 From: thegameiam at yahoo.com (David Barak) Date: Wed, 23 Dec 2009 05:06:34 -0800 (PST) Subject: IGMP and PIM protection Message-ID: <599641.39134.qm@web31802.mail.mud.yahoo.com> Multicast encryption using GDOI works well, although I haven't seen that implemented on a LAN. If you're trying to provide encryption for LAN listeners (more accurately to exclude some LAN listeners) you'll probably find more bang for the buck in implementing this on a per-application basis. That leaves the IGMP request subject to eavesdropping, but the data itself flows over a secure channel. If instead you want the IGMP itself to be encrypted, then you'll need all of the switches to participate in the security protocol, and I would imagine that there are far easier ways to provide secure connections. I believe GDOI is esp-only. Cisco's term for GDOI is GETVPN. -David Barak On Wed Dec 23rd, 2009 7:26 AM EST Peter Hicks wrote: >Glen Kent wrote: >> Any idea if folks use AH or ESP to protect IGMP/PIM packets? Wondering >> that if they do, then how would snooping switches work? >> >Would encrypting multicast not fundamentally break the concept of multicast itself, unless you're encrypting multicast traffic over a backbone? > > >Peter > > > From rdobbins at arbor.net Wed Dec 23 14:16:38 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 23 Dec 2009 14:16:38 +0000 Subject: IGMP and PIM protection In-Reply-To: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> Message-ID: <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> On Dec 23, 2009, at 6:41 PM, Glen Kent wrote: > Any idea if folks use AH or ESP to protect IGMP/PIM packets What are you trying to 'protect' them against? ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From glen.kent at gmail.com Wed Dec 23 14:17:24 2009 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 23 Dec 2009 19:47:24 +0530 Subject: IGMP and PIM protection In-Reply-To: <4B320C6E.5040105@poggs.co.uk> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <4B320C6E.5040105@poggs.co.uk> Message-ID: <92c950310912230617x34a84839o4fb9c74f2337f880@mail.gmail.com> >> > > Would encrypting multicast not fundamentally break the concept of multicast > itself, unless you're encrypting multicast traffic over a backbone? > No, i wasnt alluding to encrypting the multicast traffic. I was thinking of using ESP-NULL (AH is optional) for the IGMP/PIM packets. Affably, Kent From glen.kent at gmail.com Wed Dec 23 14:19:16 2009 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 23 Dec 2009 19:49:16 +0530 Subject: IGMP and PIM protection In-Reply-To: <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> Message-ID: <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> On Wed, Dec 23, 2009 at 7:46 PM, Dobbins, Roland wrote: > > On Dec 23, 2009, at 6:41 PM, Glen Kent wrote: > >> Any idea if folks use AH or ESP to protect IGMP/PIM packets > > What are you trying to 'protect' them against? Just integrity protection to ensure that my reports, etc. are not mangled when i recv them. OR to make sure that i only receive reports/leaves from the folks who are supposed to send them. Please note that i am NOT interested in encrypting the control traffic. Kent > > ----------------------------------------------------------------------- > Roland Dobbins // > > ? ?Injustice is relatively easy to bear; what stings is justice. > > ? ? ? ? ? ? ? ? ? ? ? ?-- H.L. Mencken > > > > > From rdobbins at arbor.net Wed Dec 23 14:22:25 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 23 Dec 2009 14:22:25 +0000 Subject: IGMP and PIM protection In-Reply-To: <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> Message-ID: <89CBE8AA-10F1-4261-87E4-86067E77DBE9@arbor.net> On Dec 23, 2009, at 9:19 PM, Glen Kent wrote: > Just integrity protection to ensure that my reports, etc. are not mangled when i recv them. OR to make sure that i only receive reports/leaves from the folks who are supposed to send them. I echo the previous respondent who noted that this is probably best done at the application layer, FWIW. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From joelja at bogus.com Wed Dec 23 14:22:50 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 23 Dec 2009 06:22:50 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <20091223115722.GA9111@gsp.org> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091223115722.GA9111@gsp.org> Message-ID: <4B3227BA.3020908@bogus.com> Rich Kulawiec wrote: > On Wed, Dec 23, 2009 at 01:58:47AM -0500, Christopher Morrow wrote: >> no real arguement, but... 'please provide some set of workable >> solutions' > > The set of workable solutions at this point looks something like > "null routes, firewall rules, blacklist entries" -- in order to deny > traffic to and from such locales. > > I agree just about entirely with Ferg: the policy angle is a dead > end. The organizations involved are either clueless or entirely > focused on other goals (e.g., profit) at the expense of sound policy. > Gosh, there's no way I can create this public good, because someone somewhere will use it in the commission of a crime notwithstanding all the benefits it confers. I'll just throw down props to Paul Samuelson since he's no longer with us and leave it at that. > ---Rsk > From swm at emanon.com Wed Dec 23 14:24:44 2009 From: swm at emanon.com (Scott Morris) Date: Wed, 23 Dec 2009 09:24:44 -0500 Subject: IGMP and PIM protection In-Reply-To: <92c950310912230617x34a84839o4fb9c74f2337f880@mail.gmail.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <4B320C6E.5040105@poggs.co.uk> <92c950310912230617x34a84839o4fb9c74f2337f880@mail.gmail.com> Message-ID: <4B32282C.708@emanon.com> So we're looking to complicate things for the same of complicating them? Using a predictable "security" doesn't exactly make things secure does it? On the links that you are running PIM or IGMP on, do you not have a predictable set of clients and therefore problems? Or are we trying to protect against something I'm not thinking of? ;) Scott Glen Kent wrote: >> Would encrypting multicast not fundamentally break the concept of multicast >> itself, unless you're encrypting multicast traffic over a backbone? >> >> > > No, i wasnt alluding to encrypting the multicast traffic. I was > thinking of using ESP-NULL (AH is optional) for the IGMP/PIM packets. > > Affably, > Kent > > > From swm at emanon.com Wed Dec 23 14:26:44 2009 From: swm at emanon.com (Scott Morris) Date: Wed, 23 Dec 2009 09:26:44 -0500 Subject: IGMP and PIM protection In-Reply-To: <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> Message-ID: <4B3228A4.4020505@emanon.com> But IGMP IS the control traffic with users. And PIM IS the control traffic between multicast routers. ? Scott Glen Kent wrote: > On Wed, Dec 23, 2009 at 7:46 PM, Dobbins, Roland wrote: > >> On Dec 23, 2009, at 6:41 PM, Glen Kent wrote: >> >> >>> Any idea if folks use AH or ESP to protect IGMP/PIM packets >>> >> What are you trying to 'protect' them against? >> > > Just integrity protection to ensure that my reports, etc. are not > mangled when i recv them. OR to make sure that i only receive > reports/leaves from the folks who are supposed to send them. > > Please note that i am NOT interested in encrypting the control traffic. > > Kent > > >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Injustice is relatively easy to bear; what stings is justice. >> >> -- H.L. Mencken >> >> >> >> >> >> > > > From sfouant at shortestpathfirst.net Wed Dec 23 15:24:59 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 23 Dec 2009 10:24:59 -0500 Subject: IGMP and PIM protection In-Reply-To: <4B3228A4.4020505@emanon.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> <4B3228A4.4020505@emanon.com> Message-ID: <00fa01ca83e4$17e387d0$47aa9770$@net> > -----Original Message----- > From: Scott Morris [mailto:swm at emanon.com] > Sent: Wednesday, December 23, 2009 9:27 AM > To: Glen Kent > Cc: nanog at nanog.org > Subject: Re: IGMP and PIM protection > > But IGMP IS the control traffic with users. And PIM IS the control > traffic between multicast routers. I think OP meant that he only wants an integrity check of the control traffic, not confidentiality, hence the statement that he does not want to encrypt the control traffic. Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From andrew.wallace at rocketmail.com Wed Dec 23 16:58:23 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 23 Dec 2009 16:58:23 +0000 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <75cb24520912222319q73a28aa2h80b1b79873b2e3b8@mail.gmail.com> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> <4b6ee9310912221633w45ef9a59rf419956c18a0b3cd@mail.gmail.com> <75cb24520912222319q73a28aa2h80b1b79873b2e3b8@mail.gmail.com> Message-ID: <4b6ee9310912230858k1e9fb142o1a57ed7ad31c9d63@mail.gmail.com> On Wed, Dec 23, 2009 at 7:19 AM, Christopher Morrow wrote: > (again, this seems really off topic, but) > > On Tue, Dec 22, 2009 at 7:33 PM, andrew.wallace > wrote: >> though Gadi is Israeli and Marcus Sachs Pakistani and couldn't be > > marcus is pakistani? > > "He was born in Lahore, Pakistan in 1959 and moved to Tallahassee, Florida with his parents and younger brother in 1961." --Wikipedia. http://en.wikipedia.org/wiki/Marcus_Sachs To me its amazing how deep into U.S Intelligence and The White House he's been allowed to go up until now. From william.allen.simpson at gmail.com Wed Dec 23 17:42:24 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 23 Dec 2009 12:42:24 -0500 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <4b6ee9310912230858k1e9fb142o1a57ed7ad31c9d63@mail.gmail.com> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> <4b6ee9310912221633w45ef9a59rf419956c18a0b3cd@mail.gmail.com> <75cb24520912222319q73a28aa2h80b1b79873b2e3b8@mail.gmail.com> <4b6ee9310912230858k1e9fb142o1a57ed7ad31c9d63@mail.gmail.com> Message-ID: <4B325680.6010602@gmail.com> andrew.wallace wrote: > "He was born in Lahore, Pakistan in 1959 and moved to Tallahassee, > Florida with his parents and younger brother in 1961." --Wikipedia. > > http://en.wikipedia.org/wiki/Marcus_Sachs > Just like many Americans. > To me its amazing how deep into U.S Intelligence and The White House > he's been allowed to go up until now. > "... Georgia Institute of Technology in Atlanta, where he graduated in 1981 with a Bachelor of Civil Engineering degree. "Commissioned as a Second Lieutenant of Engineers in the United States Army in 1981, he served over 20 years as an officer in the Army Corps of Engineers. He graduated from the United States Army Command and General Staff College, and holds a master's degree in Science and Technology Commercialization from the University of Texas and a master's degree in Computer Science from James Madison University." An un-American mole, loyal to a country and a long-time US allied government that he probably doesn't remember? I'm wondering whether you're related to: http://en.wikipedia.org/wiki/George_Wallace From brunner at nic-naa.net Wed Dec 23 18:06:47 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 23 Dec 2009 13:06:47 -0500 Subject: FYI, new USG Cybersecurity Coordinator ... In-Reply-To: <4B325680.6010602@gmail.com> References: <202705b0912220542w215e1bcdx8a59a21939ad1b71@mail.gmail.com> <23123.1261494598@localhost> <6cd462c00912221106q2d851bb6x18b0e1edfb193ec3@mail.gmail.com> <4b6ee9310912221633w45ef9a59rf419956c18a0b3cd@mail.gmail.com> <75cb24520912222319q73a28aa2h80b1b79873b2e3b8@mail.gmail.com> <4b6ee9310912230858k1e9fb142o1a57ed7ad31c9d63@mail.gmail.com> <4B325680.6010602@gmail.com> Message-ID: <4B325C37.1040708@nic-naa.net> +BIGINT The real issues are (a) is this billet actually able to originate policy, (b) interpret existing policy, (c) at least find the RNC mail archive, (d) ... Who the hell cares if the billet is filled by a Soviet Mole (tm) if the job is decoration? Eric On 12/23/09 12:42 PM, William Allen Simpson wrote: > andrew.wallace wrote: >> "He was born in Lahore, Pakistan in 1959 and moved to Tallahassee, >> Florida with his parents and younger brother in 1961." --Wikipedia. >> >> http://en.wikipedia.org/wiki/Marcus_Sachs >> > Just like many Americans. > > >> To me its amazing how deep into U.S Intelligence and The White House >> he's been allowed to go up until now. >> > "... Georgia Institute of Technology in Atlanta, where he graduated in > 1981 with a Bachelor of Civil Engineering degree. > > "Commissioned as a Second Lieutenant of Engineers in the United States > Army in 1981, he served over 20 years as an officer in the Army > Corps of > Engineers. He graduated from the United States Army Command and > General > Staff College, and holds a master's degree in Science and Technology > Commercialization from the University of Texas and a master's > degree in > Computer Science from James Madison University." > > An un-American mole, loyal to a country and a long-time US allied > government > that he probably doesn't remember? > > I'm wondering whether you're related to: > > http://en.wikipedia.org/wiki/George_Wallace > > > > From jdfalk-lists at cybernothing.org Wed Dec 23 18:18:08 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Wed, 23 Dec 2009 11:18:08 -0700 Subject: Article on spammers and their infrastructure In-Reply-To: <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> Message-ID: On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote: > On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Folks should not be so obtuse about these activities. It's almost blatantly >> in-your-face, so to speak. These guys have no fear of retribution. > > no real arguement, but... 'please provide some set of workable solutions' > > The ARIN meetings (at least) are open, please come and help guide > policies. I'm sure RIPE also wouldn't mind a discussion, if there > could be some positive policy outcome. Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, perhaps ARIN & RIPE representatives could visit anti-spam meetings such as MAAWG to ask how they can help? I'd be happy to make some introductions. -- J.D. Falk Return Path Inc From andrewy at webair.com Wed Dec 23 18:26:52 2009 From: andrewy at webair.com (andrew young) Date: Wed, 23 Dec 2009 13:26:52 -0500 Subject: looking for a contact at Orange Message-ID: <4B3260EC.3080405@webair.com> if anyone has a contact at Orange or is from Orange, can you contact me off list. need help with some issues originating from the EU. -- ---------------------------------------- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM From Michael_OReirdan at Cable.Comcast.com Wed Dec 23 18:56:36 2009 From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael) Date: Wed, 23 Dec 2009 13:56:36 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: Message-ID: JD Great point, I am more than happy to have a couple of people from ARIN or RIPE as guests at the next MAAWG in SFO or the subsequent one in Barcelona. Mike On 12/23/09 1:18 PM, "J.D. Falk" wrote: > On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote: > >> > On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson >> wrote: >>> >> -----BEGIN PGP SIGNED MESSAGE----- >>> >> Hash: SHA1 >>> >> >>> >> Folks should not be so obtuse about these activities. It's almost >>> blatantly >>> >> in-your-face, so to speak. These guys have no fear of retribution. >> > >> > no real arguement, but... 'please provide some set of workable solutions' >> > >> > The ARIN meetings (at least) are open, please come and help guide >> > policies. I'm sure RIPE also wouldn't mind a discussion, if there >> > could be some positive policy outcome. > > Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, > perhaps ARIN & RIPE representatives could visit anti-spam meetings such as > MAAWG to ask how they can help? > > I'd be happy to make some introductions. > > -- > J.D. Falk > Return Path Inc > > > > > > From marty.anstey at sunwave.net Wed Dec 23 20:00:28 2009 From: marty.anstey at sunwave.net (Marty Anstey) Date: Wed, 23 Dec 2009 12:00:28 -0800 Subject: IPv6 Training Message-ID: <4B3276DC.8000602@sunwave.net> Greetings, Just wondering if anyone has had any experience with IPv6 training courses. A quick search turns up a few results on the subject, but it would be handy to hear if anyone has any firsthand experiences or recommendations. We're based in western Canada but don't mind traveling a bit, but alternatively an online course would be acceptable as well. -M From eslerj at gmail.com Wed Dec 23 20:28:38 2009 From: eslerj at gmail.com (Joel Esler) Date: Wed, 23 Dec 2009 15:28:38 -0500 Subject: IPv6 Training In-Reply-To: <4B3276DC.8000602@sunwave.net> References: <4B3276DC.8000602@sunwave.net> Message-ID: <20091223202838.GA70045@new-host-2.home> On Wed, Dec 23, 2009 at 12:00:28PM -0800, Marty Anstey wrote: > Greetings, > > Just wondering if anyone has had any experience with IPv6 training courses. > > A quick search turns up a few results on the subject, but it would be > handy to hear if anyone has any firsthand experiences or recommendations. > We're based in western Canada but don't mind traveling a bit, but > alternatively an online course would be acceptable as well. > > -M > SANS has a course that's pretty good, from what I hear. I haven't taken it. Those that remember the discussion may find this article interesting: http://abcnews.go.com/Health/wireStory?id=9394406 Owen From mleber at he.net Wed Dec 23 21:03:40 2009 From: mleber at he.net (Mike Leber) Date: Wed, 23 Dec 2009 13:03:40 -0800 Subject: IPv6 Training In-Reply-To: <4B3276DC.8000602@sunwave.net> References: <4B3276DC.8000602@sunwave.net> Message-ID: <4B3285AC.5030503@he.net> Marty Anstey wrote: > Just wondering if anyone has had any experience with IPv6 training courses. > > A quick search turns up a few results on the subject, but it would be > handy to hear if anyone has any firsthand experiences or recommendations. > We're based in western Canada but don't mind traveling a bit, but > alternatively an online course would be acceptable as well. Once you have IPv6 connectivity established (either native IPv6 or via a tunnel from anybody (for example tunnelbroker.net or sixxs.net) if you want a self teaching procedural guide where you can setup and test various IPv6 services (HTTP, SMTP, reverse DNS, forward DNS, host record glue) then you might checkout our free IPv6 certification service at: http://ipv6.he.net/certification It's a bit tongue in cheek and meant to be sort of like entertainment with education for engineers (for example the certification ranks are from "Newb" to "Sage"). By the time you are done you are done IPv6 won't seem weird. (In fact, you'll probably be thinking "that's it?!") We are still adding tests and content as people suggest ideas, so if you run through it and see a gap you'd like covered, let me know. Alternatively, if you would like a free IPv6 Speaker/Trainer your group of 30 or more people, Hurricane Electric will fly IPv6 Evangelist Owen Delong to your meeting to present a tutorial on what you need to do to support IPv6 (for system administrators and network engineers), porting IPv4 programs to IPv6 (for software engineers), or another IPv6 topic you suggest. If you are interested, email ipv6 at he.net Mike. From tkapela at gmail.com Wed Dec 23 22:32:11 2009 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 23 Dec 2009 17:32:11 -0500 Subject: IGMP and PIM protection In-Reply-To: <00fa01ca83e4$17e387d0$47aa9770$@net> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> <4B3228A4.4020505@emanon.com> <00fa01ca83e4$17e387d0$47aa9770$@net> Message-ID: <2e9d8ae50912231432g4cc42cfbt9a764206eea0d03@mail.gmail.com> On Wed, Dec 23, 2009 at 10:24 AM, Stefan Fouant wrote: > I think OP meant that he only wants an integrity check of the control > traffic, not confidentiality, hence the statement that he does not want to > encrypt the control traffic. I read the OP to mean this, too. Musing on the idea for a moment, it would surely be 'nice' to somehow know that PIM v2 joins from some other network were, in fact, 'good' or somehow well-formed, rate-limited, and/or somehow 'safe' to accept & hold state for. However, it seems as if the OP isn't interested in inter-domain "rp protection" -- and probably more interested in authenticating more local igmp v2/3 joins for STB's and the like. Glen, clarify? -Tk From surfer at mauigateway.com Wed Dec 23 23:01:13 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 23 Dec 2009 15:01:13 -0800 Subject: [NANOG] Roport on internet business Message-ID: <20091223150113.9A501330@resin18.mta.everyone.net> --- takashi at cpqd.com.br wrote: From: "Takashi Tome" Morgan Stanley has released a very interesting report on internet business with some tips to net operators: http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html ------------------------------------------------------- It must be purchased: ---------------------- The Mobile Internet Report To receive a printed copy of The Mobile Internet Report, please contact your Morgan Stanley Representative. To purchase a copy, please click here. ---------------------- scott From owen at delong.com Wed Dec 23 23:01:59 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Dec 2009 15:01:59 -0800 Subject: IPv6 Training In-Reply-To: <4B3276DC.8000602@sunwave.net> References: <4B3276DC.8000602@sunwave.net> Message-ID: On Dec 23, 2009, at 12:00 PM, Marty Anstey wrote: > Greetings, > > Just wondering if anyone has had any experience with IPv6 training courses. > > A quick search turns up a few results on the subject, but it would be > handy to hear if anyone has any firsthand experiences or recommendations. > We're based in western Canada but don't mind traveling a bit, but > alternatively an online course would be acceptable as well. > > -M > > Depending on what you are looking for, check out tunnelbroker.net and you can learn quite a bit there. If you can be more specific about your needs, HE is actually actively working to provide training in this area, and, we are the ISP with more IPv6 experience than any other. Owen From richard at bennett.com Wed Dec 23 23:11:36 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 23 Dec 2009 15:11:36 -0800 Subject: [NANOG] Roport on internet business In-Reply-To: <20091223150113.9A501330@resin18.mta.everyone.net> References: <20091223150113.9A501330@resin18.mta.everyone.net> Message-ID: <4B32A3A8.20503@bennett.com> It's actually available for free on the World-Wide Internet at http://www.morganstanley.com/institutional/techresearch/pdfs/Mobile_Internet_Report_Key_Themes_Final.pdf , but you can purchase a paper copy if you'd rather. It's pretty slow going as it's mostly power points, some with lots and lots of words, but some of the graphs and insights are intriguing, esp. as they related to the non-USA parts of the world. The authors are pretty well convinced that the demand for more wireless spectrum will be handled by spectral efficiency improvements and deployment of more towers, they stress the importance of replacing copper with fiber and microwave in the middle mile, and don't think the telcos are doing the right things. There's a lot of discussion about how the wireless networks will handle voice and best-efforts at the same time which many will find troublesome, I suppose, but overall I'd give it 4 out of 5 stars. RB On 12/23/2009 3:01 PM, Scott Weeks wrote: > --- takashi at cpqd.com.br wrote: > From: "Takashi Tome" > > Morgan Stanley has released a very interesting report on internet business with some tips to net operators: > > http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html > ------------------------------------------------------- > > > It must be purchased: > > ---------------------- > The Mobile Internet Report > > To receive a printed copy of The Mobile Internet Report, please contact your Morgan Stanley Representative. To purchase a copy, please click here. > ---------------------- > > scott > > From jimb at jsbc.cc Wed Dec 23 23:16:50 2009 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 23 Dec 2009 15:16:50 -0800 Subject: IPv6 Training In-Reply-To: <4B3285AC.5030503@he.net> References: <4B3276DC.8000602@sunwave.net> <4B3285AC.5030503@he.net> Message-ID: <4B32A4E2.5040803@jsbc.cc> On 12/23/2009 13:03, Mike Leber wrote: > > Marty Anstey wrote: >> Just wondering if anyone has had any experience with IPv6 training >> courses. >> >> A quick search turns up a few results on the subject, but it would be >> handy to hear if anyone has any firsthand experiences or >> recommendations. >> We're based in western Canada but don't mind traveling a bit, but >> alternatively an online course would be acceptable as well. > > Once you have IPv6 connectivity established (either native IPv6 or via > a tunnel from anybody (for example tunnelbroker.net or sixxs.net) if > you want a self teaching procedural guide where you can setup and test > various IPv6 services (HTTP, SMTP, reverse DNS, forward DNS, host > record glue) then you might checkout our free IPv6 certification > service at: > > http://ipv6.he.net/certification > > It's a bit tongue in cheek and meant to be sort of like entertainment > with education for engineers (for example the certification ranks are > from "Newb" to "Sage"). By the time you are done you are done IPv6 > won't seem weird. (In fact, you'll probably be thinking "that's it?!") > Tongue in cheek? You mean I'm not *really* a Sage? :p :p The tunnelbroker.net forum is also a good source of info/discussion about IPv6. It'd be nice if it was a bit more "active" though. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From glen.kent at gmail.com Thu Dec 24 00:12:37 2009 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 24 Dec 2009 05:42:37 +0530 Subject: IGMP and PIM protection In-Reply-To: <2e9d8ae50912231432g4cc42cfbt9a764206eea0d03@mail.gmail.com> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> <4B3228A4.4020505@emanon.com> <00fa01ca83e4$17e387d0$47aa9770$@net> <2e9d8ae50912231432g4cc42cfbt9a764206eea0d03@mail.gmail.com> Message-ID: <92c950310912231612n19734d49x98f16383f8b7192b@mail.gmail.com> > > Musing on the idea for a moment, it would surely be 'nice' to somehow > know that PIM v2 joins from some other network were, in fact, 'good' > or somehow well-formed, rate-limited, and/or somehow 'safe' to accept > & hold state for. However, it seems as if the OP isn't interested in > inter-domain "rp protection" -- and probably more interested in > authenticating more local igmp v2/3 joins for STB's and the like. Yup, i was currently looking at the IGMP v2/v3 joins only. Kent > > Glen, clarify? > > -Tk > From glen.kent at gmail.com Thu Dec 24 00:13:07 2009 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 24 Dec 2009 05:43:07 +0530 Subject: IGMP and PIM protection In-Reply-To: <00fa01ca83e4$17e387d0$47aa9770$@net> References: <92c950310912230341vbe1fffcwbdbebbd5bc945509@mail.gmail.com> <069C2D3F-D527-45F7-B48F-06F3DC6CA954@arbor.net> <92c950310912230619i6e9f71fchd42867cae5774571@mail.gmail.com> <4B3228A4.4020505@emanon.com> <00fa01ca83e4$17e387d0$47aa9770$@net> Message-ID: <92c950310912231613l4a09b53aq877013f5293c205b@mail.gmail.com> > > I think OP meant that he only wants an integrity check of the control > traffic, not confidentiality, hence the statement that he does not want to > encrypt the control traffic. Yes, thats correct. Kent > > Stefan Fouant > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > From jared at puck.nether.net Thu Dec 24 00:22:05 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 23 Dec 2009 19:22:05 -0500 Subject: [NANOG] Roport on internet business In-Reply-To: <4B32A3A8.20503@bennett.com> References: <20091223150113.9A501330@resin18.mta.everyone.net> <4B32A3A8.20503@bennett.com> Message-ID: <601584A0-AEB1-4E36-AD21-03586DF98F0F@puck.nether.net> On Dec 23, 2009, at 6:11 PM, Richard Bennett wrote: > The authors are pretty well convinced that the demand for more wireless spectrum will be handled by spectral efficiency improvements and deployment of more towers, they stress the importance of replacing copper with fiber and microwave in the middle mile, and don't think the telcos are doing the right things. I know, watching my local incumbent they are not replacing damaged copper with fiber. I think they must have warehouses of it someplace. I can't imagine that it is good to replace buried copper w/copper during the wintertime. If you're out doing it, might as well *actually* install fiber in the conduit. (Unless it's about unions/job protection for the copper guys). - Jared (not saying unions are bad, but when you operate two assets and have a different union for each, it can limit your potential significantly). From scott at doc.net.au Thu Dec 24 00:30:32 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 23 Dec 2009 16:30:32 -0800 Subject: [NANOG] Roport on internet business In-Reply-To: <20091223150113.9A501330@resin18.mta.everyone.net> References: <20091223150113.9A501330@resin18.mta.everyone.net> Message-ID: On Wed, Dec 23, 2009 at 3:01 PM, Scott Weeks wrote: > It must be purchased: > Only if you want the dead-tree edition. The others are linked below the text you've quoted. Scott. From richard at bennett.com Thu Dec 24 01:05:56 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 23 Dec 2009 17:05:56 -0800 Subject: [NANOG] Roport on internet business In-Reply-To: <601584A0-AEB1-4E36-AD21-03586DF98F0F@puck.nether.net> References: <20091223150113.9A501330@resin18.mta.everyone.net> <4B32A3A8.20503@bennett.com> <601584A0-AEB1-4E36-AD21-03586DF98F0F@puck.nether.net> Message-ID: <4B32BE74.3070909@bennett.com> Maybe we need to pass some laws that ban copper wire outdoors. On 12/23/2009 4:22 PM, Jared Mauch wrote: > On Dec 23, 2009, at 6:11 PM, Richard Bennett wrote: > > >> The authors are pretty well convinced that the demand for more wireless spectrum will be handled by spectral efficiency improvements and deployment of more towers, they stress the importance of replacing copper with fiber and microwave in the middle mile, and don't think the telcos are doing the right things. >> > I know, watching my local incumbent they are not replacing damaged copper with fiber. I think they must have warehouses of it someplace. I can't imagine that it is good to replace buried copper w/copper during the wintertime. If you're out doing it, might as well *actually* install fiber in the conduit. > > (Unless it's about unions/job protection for the copper guys). > > - Jared (not saying unions are bad, but when you operate two assets and have a different union for each, it can limit your potential significantly). From pace at jolokianetworks.com Thu Dec 24 01:08:47 2009 From: pace at jolokianetworks.com (Mark Pace) Date: Wed, 23 Dec 2009 17:08:47 -0800 Subject: UltraDNS Failure? Message-ID: <4B32BF1F.8010103@jolokianetworks.com> Anyone else having problems resolving DNS from UltraDNS? I'm seeing this: $ dig www.ultradns.com @8.8.8.8 ; <<>> DiG 9.6.0-P1 <<>> www.ultradns.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26650 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ultradns.com. IN A ;; Query time: 38 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Dec 23 16:59:39 2009 ;; MSG SIZE rcvd: 34 $ dig www.ultradns.com +trace ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.0-P1 <<>> www.ultradns.com +trace ;; global options: +cmd . 490316 IN NS d.root-servers.net. . 490316 IN NS k.root-servers.net. . 490316 IN NS j.root-servers.net. . 490316 IN NS h.root-servers.net. . 490316 IN NS g.root-servers.net. . 490316 IN NS m.root-servers.net. . 490316 IN NS c.root-servers.net. . 490316 IN NS i.root-servers.net. . 490316 IN NS b.root-servers.net. . 490316 IN NS e.root-servers.net. . 490316 IN NS a.root-servers.net. . 490316 IN NS l.root-servers.net. . 490316 IN NS f.root-servers.net. . 490316 IN NS d.root-servers.net. . 490316 IN NS k.root-servers.net. . 490316 IN NS j.root-servers.net. . 490316 IN NS h.root-servers.net. . 490316 IN NS g.root-servers.net. . 490316 IN NS m.root-servers.net. . 490316 IN NS c.root-servers.net. . 490316 IN NS i.root-servers.net. . 490316 IN NS b.root-servers.net. . 490316 IN NS e.root-servers.net. . 490316 IN NS a.root-servers.net. . 490316 IN NS l.root-servers.net. . 490316 IN NS f.root-servers.net. ;; Received 717 bytes from 10.23.69.254#53(10.23.69.254) in 52 ms com. 172800 IN NS C.GTLD-SERVERS.NET. com. 172800 IN NS A.GTLD-SERVERS.NET. com. 172800 IN NS G.GTLD-SERVERS.NET. com. 172800 IN NS I.GTLD-SERVERS.NET. com. 172800 IN NS D.GTLD-SERVERS.NET. com. 172800 IN NS E.GTLD-SERVERS.NET. com. 172800 IN NS B.GTLD-SERVERS.NET. com. 172800 IN NS J.GTLD-SERVERS.NET. com. 172800 IN NS K.GTLD-SERVERS.NET. com. 172800 IN NS H.GTLD-SERVERS.NET. com. 172800 IN NS F.GTLD-SERVERS.NET. com. 172800 IN NS L.GTLD-SERVERS.NET. com. 172800 IN NS M.GTLD-SERVERS.NET. ;; Received 522 bytes from 192.228.79.201#53(b.root-servers.net) in 70 ms ultradns.com. 172800 IN NS pdns1.ultradns.net. ultradns.com. 172800 IN NS pdns2.ultradns.net. ultradns.com. 172800 IN NS pdns3.ultradns.org. ultradns.com. 172800 IN NS pdns4.ultradns.org. ultradns.com. 172800 IN NS pdns5.ultradns.info. ultradns.com. 172800 IN NS pdns6.ultradns.co.uk. ;; Received 237 bytes from 192.52.178.30#53(K.GTLD-SERVERS.NET) in 374 ms ;; connection timed out; no servers could be reached From shrdlu at deaddrop.org Thu Dec 24 01:13:53 2009 From: shrdlu at deaddrop.org (Shrdlu) Date: Wed, 23 Dec 2009 17:13:53 -0800 Subject: UltraDNS Failure? In-Reply-To: <4B32BF1F.8010103@jolokianetworks.com> References: <4B32BF1F.8010103@jolokianetworks.com> Message-ID: <4B32C051.70509@deaddrop.org> Mark Pace wrote: > Anyone else having problems resolving DNS from UltraDNS? > > I'm seeing this: > > $ dig www.ultradns.com @8.8.8.8 Yeah, they went belly up in the last 20 or so. Hard. Looks like it's hitting some of Amazon's Cloud stuff too. It seems west coast related, by the way. -- Oh, mairzy doats and dozy doats and liddle lamzy divey A kiddley divey too, wooden chu? Three little fiddies in an iddy, bitty pooh, Three little fiddies and a mama fiddy too... From pace at jolokianetworks.com Thu Dec 24 01:17:16 2009 From: pace at jolokianetworks.com (Mark Pace) Date: Wed, 23 Dec 2009 17:17:16 -0800 Subject: UltraDNS Failure? In-Reply-To: <4B32C051.70509@deaddrop.org> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> Message-ID: <4B32C11C.6000906@jolokianetworks.com> >> Anyone else having problems resolving DNS from UltraDNS? >> >> I'm seeing this: >> >> $ dig www.ultradns.com @8.8.8.8 > > Yeah, they went belly up in the last 20 or so. Hard. Looks like it's > hitting some of Amazon's Cloud stuff too. It seems west coast related, > by the way. > On the west coast here. They went at 4:44pm (Pacific). pace From pace at jolokianetworks.com Thu Dec 24 01:22:26 2009 From: pace at jolokianetworks.com (Mark Pace) Date: Wed, 23 Dec 2009 17:22:26 -0800 Subject: UltraDNS Failure? In-Reply-To: <4B32C11C.6000906@jolokianetworks.com> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> <4B32C11C.6000906@jolokianetworks.com> Message-ID: <4B32C252.608@jolokianetworks.com> > >>> Anyone else having problems resolving DNS from UltraDNS? >>> >>> I'm seeing this: >>> >>> $ dig www.ultradns.com @8.8.8.8 >>> >> Yeah, they went belly up in the last 20 or so. Hard. Looks like it's >> hitting some of Amazon's Cloud stuff too. It seems west coast related, >> by the way. >> >> > On the west coast here. They went at 4:44pm (Pacific). > > Recovered at this point... pace From surfer at mauigateway.com Thu Dec 24 01:24:04 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 23 Dec 2009 17:24:04 -0800 Subject: [NANOG] Roport on internet business Message-ID: <20091223172404.9A50031F@resin18.mta.everyone.net> ------- scott at doc.net.au wrote: ---------- From: Scott Howard On Wed, Dec 23, 2009 at 3:01 PM, Scott Weeks wrote: > It must be purchased: Only if you want the dead-tree edition. The others are linked below the text you've quoted. ---------------------------------------------- DOH! I blame it on Christmasits. It's a bad disease I recently caught... ;-) Apologies for the confusion. Have a great Christmas! scott From pace at jolokianetworks.com Thu Dec 24 01:29:59 2009 From: pace at jolokianetworks.com (Mark Pace) Date: Wed, 23 Dec 2009 17:29:59 -0800 Subject: UltraDNS Failure? In-Reply-To: <4B32C252.608@jolokianetworks.com> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> <4B32C11C.6000906@jolokianetworks.com> <4B32C252.608@jolokianetworks.com> Message-ID: <4B32C417.5050609@jolokianetworks.com> Clarification: www.ultradns.com is back. There are still other problems afoot, like amazon: $ dig amazon.com @8.8.8.8 ; <<>> DiG 9.6.0-P1 <<>> amazon.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56390 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;amazon.com. IN A ;; Query time: 2042 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Dec 23 17:28:10 2009 ;; MSG SIZE rcvd: 28 On 12/23/2009 5:22 PM, Mark Pace wrote: > >> >> >>>> Anyone else having problems resolving DNS from UltraDNS? >>>> >>>> I'm seeing this: >>>> >>>> $ dig www.ultradns.com @8.8.8.8 >>>> >>>> >>> Yeah, they went belly up in the last 20 or so. Hard. Looks like it's >>> hitting some of Amazon's Cloud stuff too. It seems west coast related, >>> by the way. >>> >>> >>> >> On the west coast here. They went at 4:44pm (Pacific). >> >> >> > Recovered at this point... > > > pace > From jsage at finchhaven.com Thu Dec 24 01:31:10 2009 From: jsage at finchhaven.com (John Sage) Date: Wed, 23 Dec 2009 17:31:10 -0800 Subject: UltraDNS Failure? In-Reply-To: <4B32C252.608@jolokianetworks.com> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> <4B32C11C.6000906@jolokianetworks.com> <4B32C252.608@jolokianetworks.com> Message-ID: <4B32C45E.3070606@finchhaven.com> Mark Pace wrote: >> >>>> Anyone else having problems resolving DNS from UltraDNS? >>>> >>>> I'm seeing this: >>>> >>>> $ dig www.ultradns.com @8.8.8.8 >>>> >>> Yeah, they went belly up in the last 20 or so. Hard. Looks like it's >>> hitting some of Amazon's Cloud stuff too. It seems west coast related, >>> by the way. >>> >>> >> On the west coast here. They went at 4:44pm (Pacific). >> >> > Recovered at this point... Not from Seattle WA via Comcast HSI: jsage at spunky:$ dig www.ultradns.com @8.8.8.8 ; <<>> DiG 9.6.1-P2 <<>> www.ultradns.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21733 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ultradns.com. IN A ;; Query time: 65 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Dec 23 17:29:41 2009 ;; MSG SIZE rcvd: 34 Also images on my web site are not loading from s3.amazonaws.com - John From shrdlu at deaddrop.org Thu Dec 24 01:38:21 2009 From: shrdlu at deaddrop.org (Shrdlu) Date: Wed, 23 Dec 2009 17:38:21 -0800 Subject: UltraDNS Failure? In-Reply-To: <4B32C252.608@jolokianetworks.com> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> <4B32C11C.6000906@jolokianetworks.com> <4B32C252.608@jolokianetworks.com> Message-ID: <4B32C60D.10507@deaddrop.org> I'm still seeing the DNS servers at udns down, hard. Amazon's cloud will need a reboot when this is over. Dang, what the heck happened to all that anycast stuff? From ras at e-gerbil.net Thu Dec 24 01:42:00 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 23 Dec 2009 19:42:00 -0600 Subject: UltraDNS Failure? In-Reply-To: <4B32C60D.10507@deaddrop.org> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> <4B32C11C.6000906@jolokianetworks.com> <4B32C252.608@jolokianetworks.com> <4B32C60D.10507@deaddrop.org> Message-ID: <20091224014200.GF75640@gerbil.cluepon.net> On Wed, Dec 23, 2009 at 05:38:21PM -0800, Shrdlu wrote: > I'm still seeing the DNS servers at udns down, hard. Amazon's cloud will > need a reboot when this is over. Dang, what the heck happened to all > that anycast stuff? We have some DNS providing type customers (not UltraDNS) receiving a few million packets/sec of UDP/53 DoS traffic, starting at about the same time as the UltraDNS problems. No clue if it's related, but it certainly sounds suspicious. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sfouant at shortestpathfirst.net Thu Dec 24 01:57:48 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 24 Dec 2009 01:57:48 +0000 Subject: UltraDNS Failure? Message-ID: <1245398857-1261619766-cardhu_decombobulator_blackberry.rim.net-1130645172-@bda294.bisx.prod.on.blackberry> There have been several DNS based DDoS observed throughout the day targetting Ultra as well as a few other companies. They were first observed earlier in the morning on the East coast. ------Original Message------ From: Richard A Steenbergen To: Shrdlu Cc: Nanog Subject: Re: UltraDNS Failure? Sent: Dec 23, 2009 8:42 PM On Wed, Dec 23, 2009 at 05:38:21PM -0800, Shrdlu wrote: > I'm still seeing the DNS servers at udns down, hard. Amazon's cloud will > need a reboot when this is over. Dang, what the heck happened to all > that anycast stuff? We have some DNS providing type customers (not UltraDNS) receiving a few million packets/sec of UDP/53 DoS traffic, starting at about the same time as the UltraDNS problems. No clue if it's related, but it certainly sounds suspicious. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) Sent from my Verizon Wireless BlackBerry From shrdlu at deaddrop.org Thu Dec 24 02:02:46 2009 From: shrdlu at deaddrop.org (Shrdlu) Date: Wed, 23 Dec 2009 18:02:46 -0800 Subject: UltraDNS Failure? In-Reply-To: <20091224014200.GF75640@gerbil.cluepon.net> References: <4B32BF1F.8010103@jolokianetworks.com> <4B32C051.70509@deaddrop.org> <4B32C11C.6000906@jolokianetworks.com> <4B32C252.608@jolokianetworks.com> <4B32C60D.10507@deaddrop.org> <20091224014200.GF75640@gerbil.cluepon.net> Message-ID: <4B32CBC6.8080003@deaddrop.org> Richard A Steenbergen wrote: > On Wed, Dec 23, 2009 at 05:38:21PM -0800, Shrdlu wrote: > >>I'm still seeing the DNS servers at udns down, hard. Amazon's cloud will >>need a reboot when this is over. Dang, what the heck happened to all >>that anycast stuff? > > > We have some DNS providing type customers (not UltraDNS) receiving a few > million packets/sec of UDP/53 DoS traffic, starting at about the same > time as the UltraDNS problems. No clue if it's related, but it certainly > sounds suspicious. :) I saw close to a hundred hits on my local dns servers for one request, and they were mostly due to the crazy amazon cloud stuff. You looking at the packets? -- Oh, mairzy doats and dozy doats and liddle lamzy divey A kiddley divey too, wooden chu? Three little fiddies in an iddy, bitty pooh, Three little fiddies and a mama fiddy too... From martin at theicelandguy.com Thu Dec 24 02:27:09 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 23 Dec 2009 21:27:09 -0500 Subject: IPv6 Training In-Reply-To: <4B3276DC.8000602@sunwave.net> References: <4B3276DC.8000602@sunwave.net> Message-ID: Marty A., Not an endorsement, but Aaron Hughes ahughes at bind.com has been doing training. I mention him because I'm aware that he has a track record, has done some +NOG presos and generally knowledgeable. He's also the only person I'm aware of outside of Europe doing training. Alternatively, I believe Jordi Palet Martinez is still an excellent trainer as well. Jordi is easily found in your favorite search engine. YMMV. Best, Marty (Yes, deliberately posted to nanog. For archives) -M< On 12/23/09, Marty Anstey wrote: > Greetings, > > Just wondering if anyone has had any experience with IPv6 training courses. > > A quick search turns up a few results on the subject, but it would be > handy to hear if anyone has any firsthand experiences or recommendations. > We're based in western Canada but don't mind traveling a bit, but > alternatively an online course would be acceptable as well. > > -M > > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From thegameiam at yahoo.com Thu Dec 24 02:46:46 2009 From: thegameiam at yahoo.com (David Barak) Date: Wed, 23 Dec 2009 18:46:46 -0800 (PST) Subject: [NANOG] Roport on internet business In-Reply-To: <601584A0-AEB1-4E36-AD21-03586DF98F0F@puck.nether.net> References: <20091223150113.9A501330@resin18.mta.everyone.net> <4B32A3A8.20503@bennett.com> <601584A0-AEB1-4E36-AD21-03586DF98F0F@puck.nether.net> Message-ID: <187058.38633.qm@web31807.mail.mud.yahoo.com> >----- Original Message ---- >From: Jared Mauch >I know, watching my local incumbent they are not replacing damaged copper with fiber. I think they must have warehouses of it someplace. I can't imagine that it is good to replace buried copper w/copper during the wintertime. If you're out doing it, might as well *actually* install fiber in the conduit. >(Unless it's about unions/job protection for the copper guys). >- Jared (not saying unions are bad, but when you operate two assets and have a different union for each, it can limit your potential significantly). One of the very hard things about running a large, geographically distributed layer 0/1 organization is managing the various and sundry physical cables from point to point. Replacing one bad span with a good span which is qualitatively different introduces a level of version control and management headache, and if done in a haphazard fashion can reduce the overall availability of the network. I don't know who your incumbent is, but it's reasonable to assume that they have some strategy for cable plant management which includes overall technology refresh at some point, with like-for-like replacement until then. Also, last I checked, the specs on "how to build a good layer 0/1 fiber infrastructure" were different than those for copper - because the capabilities are different, the network architecture has different optimizations available. This doesn't mean that the provider shouldn't be moving toward a large-scale fiber rollout - far from it! I just wanted to provide a reason why they might not want to do said rollout in a piecemeal fashion. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From hiersd at gmail.com Thu Dec 24 02:59:19 2009 From: hiersd at gmail.com (David Hiers) Date: Wed, 23 Dec 2009 18:59:19 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: Message-ID: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> 1. I grew up at the local airport watching my CFII pop train an endless stream of pilots. 2. The checklist for my last production gear swap had over 400 steps and 4 time/task gates (each with a rollback plan). As I did each sequence of steps, I called it out, and someone read their copy of the checklist and checked it off. An entire peanut gallery of rouges watched the whole thing on livemeeting, waiting to pounce on the first misstep or shortcut. 3. We migrated an entire nationwide phone system in 6 hours and nobody noticed anything. 4. We met afterward to in an after action review meeting that I picked up in the Army. I'm more persistent than smart, and I tell ya, if you prep well enough, you can hand your checklist to a stoned intern and you'll have no worries at all. David On Wed, Dec 23, 2009 at 12:48 PM, Owen DeLong wrote: > Those that remember the discussion may find this article interesting: > > http://abcnews.go.com/Health/wireStory?id=9394406 > > Owen > > > From martin at theicelandguy.com Thu Dec 24 03:27:37 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 23 Dec 2009 22:27:37 -0500 Subject: used hardware In-Reply-To: References: <26CF6BC367161D4BAFC39B6ED6F885F301D612E4@TNEXPRD.hottopic.com> Message-ID: www.subspacecom.com -- gear ++ Shows up @ NANOG, doesn't spam and clue. Best, -M< On 12/18/09, Barrett Lyon wrote: > I buy a lot of gear from Peter Giberd at Townsend. I have been > working with him for a good 7 years. It's budded into a friendship, > good people there. > > -B > > > http://www.townsendassets.com/ > > > On Dec 18, 2009, at 11:03 AM, Bill Lewis wrote: > >> http://www.networkhardware.com/ContactNHR/ >> Mostly Cisco, but I think they'll do Juniper. >> >> Bill >> >> ---------------------------------------------------------------------- >> >> -Date: Fri, 18 Dec 2009 04:34:05 -0800 >> -From: Mehmet Akcin >> -Subject: used hardware.. >> -To: "nanog at nanog.org list" >> -Message-ID: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B at akcin.net> >> -Content-Type: text/plain; charset=us-ascii >> -Hello there.. >> -I am looking to sell and buy some used hardware, where is the best >> place for this, other than ebay ? >> -Mostly juniper stuff >> -thanks in advance. >> -Mehmet >> > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jlewis at lewis.org Thu Dec 24 16:59:52 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 24 Dec 2009 11:59:52 -0500 (EST) Subject: Article on spammers and their infrastructure In-Reply-To: References: Message-ID: On Tue, 22 Dec 2009, Leo Vegoda wrote: >> ASSIGNED PA: This address space has been assigned to an End User for use >> with services provided by the issuing LIR. It cannot be kept when >> terminating services provided by the LIR. >> >> My interpretation of the above is ASSIGNED PA is the equivalent of my >> assigning IP space to a customer who either buys transit (connectivity) >> from us or colo's or buys server hosting from us where they will use that >> IP space. We don't simply lease out IP space for "customers" to use as >> they please on other networks. > > I am sure that your interpretation was the original intent of the policy > text. However, the wording could also be read in a way that allows an LIR to > just provide registry services, without providing any connectivity services. That's one hell of a stretch. Registry services aren't needed if they don't have the IP space, so saying that the service the end user is buying that justifies the IP assignment is 'registration services' is a circular argument. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kenny.sallee at gmail.com Thu Dec 24 17:24:37 2009 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Thu, 24 Dec 2009 09:24:37 -0800 Subject: Ipsec/VRF Mpls ? In-Reply-To: References: Message-ID: <4a80ecce0912240924o16809096ref935455a1a0b735@mail.gmail.com> Hello Stephane - if you search google for VRF aware IPSEC you will find links and relevant information and configs. I did this on older hardware by creating an IPSEC tunnel between 2 routeable loopbacks and creating a GRE tunnel that used the loopbacks and tunnel source and destination. Then place the GRE tunnel in a VRF. Kenny On Fri, Dec 18, 2009 at 11:03 PM, Stephane MAGAND wrote: > Hi > > after a first post with 0 answer (very thanks ..) i test a second post for > get a small help. > > I am search a simple sample of configuration for a cisco 2821 for connect > a Ipsec routers ton a MPLS IP VPN Backbone > > My cisco 2821 have two interface, one connected at my MPLS network > and the second at the Internet. > > I create two vrf, one for a site to site and the second for a Remote User > Access > > anyone have this into a config ? because i never have used Ipsec actually > on > > cisco. > > The site-to-site router are a C1721, and remote user use cisco IPSEC client > and > i want a radius authentification (and it's the radius that sent the vrf) > > thanks for your help > Stephane > From randy at psg.com Thu Dec 24 17:51:49 2009 From: randy at psg.com (Randy Bush) Date: Thu, 24 Dec 2009 12:51:49 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> Message-ID: > I'm more persistent than smart, and I tell ya, if you prep well > enough, you can hand your checklist to a stoned intern and you'll > have no worries at all. this works in a tech culture where folk follow mops obsessively. my experience is that most north american engineers are too smart to do that, and take shortcuts. randy From eddy at fasteddy.org Thu Dec 24 18:06:09 2009 From: eddy at fasteddy.org (Eddy Martinez) Date: Thu, 24 Dec 2009 10:06:09 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> Message-ID: <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> On Dec 24, 2009, at 9:51 AM, Randy Bush wrote: >> I'm more persistent than smart, and I tell ya, if you prep well >> enough, you can hand your checklist to a stoned intern and you'll >> have no worries at all. > > this works in a tech culture where folk follow mops obsessively. my > experience is that most north american engineers are too smart to do > that, and take shortcuts. > > randy > Being a "North American Engineer", I resent that remark. =] I _do_ create action plans and _do_ quarterback each step and _do_ slap down any attempt to deviate. Eddy From randy at psg.com Thu Dec 24 18:09:26 2009 From: randy at psg.com (Randy Bush) Date: Thu, 24 Dec 2009 13:09:26 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: > I _do_ create action plans and _do_ quarterback each step and _do_ > slap down any attempt to deviate. imagine a network engineering culture where the concept of 'attempt to deviate' just does not occur. randy From eddy at fasteddy.org Thu Dec 24 18:22:08 2009 From: eddy at fasteddy.org (Eddy Martinez) Date: Thu, 24 Dec 2009 10:22:08 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: <25844FDA-3E2B-4981-AE64-96E7F215BD3C@fasteddy.org> On Dec 24, 2009, at 10:09 AM, Randy Bush wrote: >> I _do_ create action plans and _do_ quarterback each step and _do_ >> slap down any attempt to deviate. > > imagine a network engineering culture where the concept of 'attempt to > deviate' just does not occur. > > randy =] The networking group is under control. Its the software engineers that start making edits to configs and code on the fly, improvisation at its finest. I guess my scope of interaction is greater than just networking. The hard part is that its a peer situation and how do you elevate the members of another team who have a lessor standard of operation. Also, they feel its fine to act like a cowboy and tackle problems on the fly. As long as the product is live before the window close. Then there is the almighty "We can't back out, we already made too many changes" that makes me want to grab rope and attach it to the ceiling. Have a Merry Christmas, Eddy From nanog at shankland.org Thu Dec 24 18:49:49 2009 From: nanog at shankland.org (Jim Shankland) Date: Thu, 24 Dec 2009 10:49:49 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <25844FDA-3E2B-4981-AE64-96E7F215BD3C@fasteddy.org> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <25844FDA-3E2B-4981-AE64-96E7F215BD3C@fasteddy.org> Message-ID: <4B33B7CD.5010409@shankland.org> Eddy Martinez wrote: > On Dec 24, 2009, at 10:09 AM, Randy Bush wrote: > >>> I _do_ create action plans and _do_ quarterback each step and _do_ >>> slap down any attempt to deviate. >> imagine a network engineering culture where the concept of 'attempt to >> deviate' just does not occur. I find the thought of *any* culture in which attempts to deviate "just do not occur" a little unnerving. Jim Shankland http://blog.oliver-gassner.de/archives/225-Guenter-Eich,-Traeume.html From dga at cs.cmu.edu Thu Dec 24 18:58:44 2009 From: dga at cs.cmu.edu (David Andersen) Date: Thu, 24 Dec 2009 13:58:44 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: On Dec 24, 2009, at 1:09 PM, Randy Bush wrote: >> I _do_ create action plans and _do_ quarterback each step and _do_ >> slap down any attempt to deviate. > > imagine a network engineering culture where the concept of 'attempt to > deviate' just does not occur. Are you trying to suggest that this is something horrible, or that it's the future of network engineering? :) I'm actually serious in asking the question, despite the grin. -Dave From randy at psg.com Thu Dec 24 19:42:41 2009 From: randy at psg.com (Randy Bush) Date: Thu, 24 Dec 2009 14:42:41 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: >> imagine a network engineering culture where the concept of 'attempt to >> deviate' just does not occur. > > Are you trying to suggest that this is something horrible, or that > it's the future of network engineering? :) neither. it is one [type of] ops engineering culture, and a very successful one. it seems, from this gaijin's naive point of view, to be the common one in japan. when i try to 'sell' configuration automation, they are confused by how important it is to me. they have a hard time seeing the need because mops just work. my read is that this is because people do not have the arrogance to take shortcuts. when one is raised knowing that one's responsibility to the group is more important than how smart one may think that one is, mops work. randy From davei at otd.com Thu Dec 24 19:48:35 2009 From: davei at otd.com (Dave Israel) Date: Thu, 24 Dec 2009 14:48:35 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: <4B33C593.9010705@otd.com> >>> I _do_ create action plans and _do_ quarterback each step and _do_ >>> slap down any attempt to deviate. >>> >> imagine a network engineering culture where the concept of 'attempt to >> deviate' just does not occur. >> > > Are you trying to suggest that this is something horrible, or that it's the future of network engineering? :) > > I'm actually serious in asking the question, despite the grin. > Possibly, he is trying to hint at a connection with Nazis, so somebody will mention it, invoking Godwin's Law, and bringing a fruitless religious thread to a close. There's a full range of methods, with "just do it" on one side, "deviation is terms for dismissal" on the other, and plenty of shades of gray in between. I've seen both extremes result in excessive downtime. (How impromptu engineering can go wrong shouldn't take much imagination; the "no deviation" rule is especially hysterical when the backout plan doesn't work, but even without that, the "one thing didn't work exactly right, back it out and try again in two weeks" effect is destructive to both progress and morale.) Working with the dynamic and quality of the team is more important than any change management paradigm. -Dave From jlewis at lewis.org Thu Dec 24 20:13:19 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 24 Dec 2009 15:13:19 -0500 (EST) Subject: Article on spammers and their infrastructure In-Reply-To: References: Message-ID: Wouldn't that be kind of pointless? ARIN policies are proposed by the public, not ARIN staff or board members. https://www.arin.net/policy/pdp.html Policy proposals may be submitted by anyone in the global Internet community except for members of the ARIN Board of Trustees or the ARIN staff. On Wed, 23 Dec 2009, O'Reirdan, Michael wrote: > JD > > Great point, I am more than happy to have a couple of people from ARIN or > RIPE as guests at the next MAAWG in SFO or the subsequent one in Barcelona. > > Mike > > > On 12/23/09 1:18 PM, "J.D. Falk" wrote: > >> On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote: >> >>>> On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson >>> wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Folks should not be so obtuse about these activities. It's almost >>>> blatantly >>>>>> in-your-face, so to speak. These guys have no fear of retribution. >>>> >>>> no real arguement, but... 'please provide some set of workable solutions' >>>> >>>> The ARIN meetings (at least) are open, please come and help guide >>>> policies. I'm sure RIPE also wouldn't mind a discussion, if there >>>> could be some positive policy outcome. >> >> Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, >> perhaps ARIN & RIPE representatives could visit anti-spam meetings such as >> MAAWG to ask how they can help? >> >> I'd be happy to make some introductions. >> >> -- >> J.D. Falk >> Return Path Inc >> >> >> >> >> >> > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From surfer at mauigateway.com Thu Dec 24 20:31:28 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 24 Dec 2009 12:31:28 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion Message-ID: <20091224123128.9A507A5B@resin18.mta.everyone.net> : this works in a tech culture where folk follow mops obsessively. my : experience is that most north americam engineers are too smart to do : that, and take shoprtcuts > and _do_ slap down any attempt to deviate : imagine a network engineering culture where the concept of 'attempt to : deviate' just does not occur > the network group is under control Hopefully, at least some of that was tongue-in-cheek. For managers: saved LOTS of dollars when deviating from MoPs by fixing AFU things not thought of in the MoP. For fellow netgeeks: no one woke you up because the AFU things were fixed while you slept. scott From scottleibrand at gmail.com Thu Dec 24 20:37:13 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 24 Dec 2009 12:37:13 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7107@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <4B31A7B6.4000304@bogus.com> <3caba1f60912222242n111fd475yb8d47eb2dafe0a3c@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7107@RWC-EX1.corp.seven.com> Message-ID: <4B33D0F9.4010105@gmail.com> On 12/23/2009 12:31 AM, George Bonser wrote: > Apologies in advance for the top post. > Likewise. These are general comments, though, so I don't feel too badly... :-) It sounds like you're on the right track. You discovered the 2009-5 Multiple Discrete Networks draft policy, which should allow you a separate /48 for each discrete network. That is somewhat orthogonal to the question of whether you should get separate resources from each RIR whose region you operate a network in. If the networks on different continents are discrete, I think the answer there is yes. I'll also point out another resource for discussing topics like this, particularly if it appears that a change in policy would be needed to accommodate your needs: ARIN's Public Policy Mailing List (PPML), https://www.arin.net/participate/mailing_lists/index.html. That's where 2009-5 came from, and I know there are still some needs unmet by current ARIN IPv6 address policy, so we're always looking for more good ideas, and feedback on the ones being discussed. At the moment, there are some very interesting discussions ongoing about how to rewrite ARIN IPv6 address policy to simplify it while making provider independent addressing more widely available and making it easier to filter traffic engineering deaggregates without accidentally filtering multihomed networks. And on the IPv4 side, there are two policy proposals on the docket to lower ARIN's minimum allocation size to /23 or /24. I encourage anyone on this list who's interested in these topics to browse the PPML archives, look over the full list of active draft policies and policy proposals at https://www.arin.net/policy/proposals/, and subscribe to PPML. We need all the input we can get. Thanks, Scott Leibrand elected volunteer member of the ARIN Advisory Council, but speaking only for myself > > > My initial idea was to use a /48, divide it up into /56 nets for each facility with /64 subnets within each facility. We would announce a /48 to our transit providers that I would expect them to announce in turn to their peers and we would also announce the more specific /56 nets to the transit providers that I would expect them not to announce to their peers. My current vlan requirements per facility would support such an addressing plan. In order to make that work, we would need the same transit providers in each region as our locations are not meshed internally. We don?t have dedicated connectivity from the US to the UK or China, for example. Currently that is not a problem as far as connectivity is concerned as my US providers appear in Europe and my China provider appears in the US. BUT when I consider the possibilities of South America and Africa and finding a transit provider that has a robust presence everywhere, my choices are very limited. I need to be multihomed and I need to be provider agnostic in my addressing. > > > > Using that scheme above does create some potential performance issues. While my transit provider collects the traffic from a remote location and routes it to the more specific location in my network, If a provider in Europe, for example, sees only the /48 announced from the US, maybe they haul the traffic across an ocean to a point where they peer with my provider ? who then must haul it back to Europe to the /56 corresponding to the destination because the original traffic source doesn?t see my /56 unless they are using the same transit provider I am. > > > > Then based on earlier discussion on the list a while back, I was concerned that a /48 wasn?t even enough to get me connected to some nets that were apparently filtering smaller than a /48 but my mind is somewhat eased in that respect and I believe that a /48 announced from space where /48s are issued will be accepted by most people. > > > > Then I was informed of ARIN 2009-5 which seems aimed at our situation; data centers widely separated by large geographical distances that are fairly autonomous and aren?t directly connected by dedicated links. It now seems that we (and the rest of the Internet) might be better served if we get a RIPE AS and net block for our Europe operations, and APNIC AS and net block for our APAC operations and get a regional /48 that I can split into /56 nets for the various satellite facilities within that region as those satellite offices CAN be directly connected to the regional data center which would act as the regional communications hub. > > > > There are probably 16 different ways to slice this but I would like to get it as close to ?right? as possible to prevent us having to renumber later while at the same time not taking more space than we need. A /48 per region seems like the right way to go at the present time. So we would have a /48 for the US, a /48 for Asia (and possibly one /48 dedicated to China) and a /48 for Europe. Satellite facilities would collect a /56 (or two or three) out of that regional block for their local use. Then I am free from being nailed to the same providers globally and have less chance of traffic crossing an ocean twice. > > > > The probability of needing 200 /48s in the next several years is pretty slim and do not warrant our getting a /32 when currently three or four /48 nets will fill the requirements. > > > > Thanks again for the input, Mick. > > > > George > > > > > > From: Mick O'Rourke [mailto:mkorourke at gmail.com] > Sent: Tuesday, December 22, 2009 10:43 PM > To: Joel Jaeggli > Cc: George Bonser; nanog at nanog.org > Subject: Re: IPv6 allocations, deaggregation, etc. > > > > Is the idea behind the /48 being looked at (keeping in mind a mixed IPv4/IPv6 environment& http://www.ietf.org/rfc/rfc5375.txt page 8) to have a /64 per smaller branch or VLAN, larger campus /56, and advertise out the /48 for the region?; My previous thinking and biggest thinking point is enterprise level address allocation policy, impacts to device loopbacks, voice vlans, operational simplification requirements for management and security layers etc. The feel overall has been towards needing to have a /32, a /56 per site (campus to small branch) and internally within the site /64 per VLAN. A /48 becomes too small, a /32 very much borderline. Is this a similar scenario for you? How are you justifying a /48 vs a /32? > > From surfer at mauigateway.com Thu Dec 24 20:54:12 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 24 Dec 2009 12:54:12 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion Message-ID: <20091224125412.9A506781@resin18.mta.everyone.net> :-) :mops work. It depends on who wrote it and the experience the person has (on the particular network) who generated it.. scott From ebw at abenaki.wabanaki.net Thu Dec 24 20:55:03 2009 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Thu, 24 Dec 2009 15:55:03 -0500 Subject: The cost of nines Message-ID: <4B33D527.5020006@abenaki.wabanaki.net> Hi all, On the 7th of next month I'll be participating in an ICANN consultation on the proposed draft registry agreement, and the number of "nines" that have crept into it, relative to what was expected of new registry operators a decade ago, is one of the hidden cost increases I will discuss with ICANN's lawyers, who are responsible for the extra nines. I'm looking for sources of cost-per-nine, network provisioning, and host provisioning, where "host" is usually a bunch of boxen, not just a pizza box. The way the requirements are now, a startup of another .museum, say for libraries or archives, or a new .coop, or a new linguistic and cultural say a .scot, has to provide a higher level of performance than Verisign currently does for com/net/name, which is slightly absurd, if not worse. I can cite sources, or not, as preferred, and while CORE is comfortable at any number ICANN's lawyers can come up with under the theory that "more nines is what security and stability mean", my goal is to allow real startups, like .museum and .coop were in 2001, not be forced to outsource registry operations to an already highly capitalized registry service provider, for competition policy reasons. I'm also "in the market" for recent failure data, such as Ultra's yesterday, and Verisign's v6, not for competitive reasons, but to show that the SLA expectation of ICANN's lawyers may need modification if placed proximal to actual operational failure data. Off-list or on, and thanks in advance, from my Yule tree to your own. Cheers, Eric From gbonser at seven.com Thu Dec 24 22:36:38 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Dec 2009 14:36:38 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <4B33D0F9.4010105@gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <4B31A7B6.4000304@bogus.com> <3caba1f60912222242n111fd475yb8d47eb2dafe0a3c@mail.gmail.com><5A6D953473350C4B9995546AFE9939EE081F7107@RWC-EX1.corp.seven.com> <4B33D0F9.4010105@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7116@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Scott Leibrand > > It sounds like you're on the right track. You discovered the 2009-5 > Multiple Discrete Networks draft policy, which should allow you a > separate /48 for each discrete network. That is somewhat orthogonal to > the question of whether you should get separate resources from each RIR > whose region you operate a network in. If the networks on different > continents are discrete, I think the answer there is yes. The extent to which they are discrete is really more of a function of the partners those networks serve when it comes to the data centers. While most of our partners are regional, that is more by happenstance than by design and I see it changing over time as more of them operate outside of their "home" region. I also want to ensure a design that allows us to serve anyone from anywhere which further "fuzzes" how discrete each potentially is. And this is actually the part where I am having the most trouble sorting the best practice. There are some advantages to doing it either way. I could get a /45 to handle everything. Having a /45 would allow me to aggregate /48s where practical while obtaining individual /48 networks would not guarantee they would be in any sort of contiguous space and not likely allow me to aggregate them even where physically possible to do so. One possible problem of using a US block globally is that someone might see a source address from me and assume it is originating in the US if they are using some sort of geolocation in order to direct service. That might cause me to be directed to a sub-optimal service portal depending on who I am communicating with. Getting blocks from the regions served seems to be the way that will cause less of a problem overall at the cost of ability to aggregate the blocks should the entire network become fully physically integrated at some point in the future. > I'll also point out another resource for discussing topics like this, > particularly if it appears that a change in policy would be needed to > accommodate your needs: ARIN's Public Policy Mailing List (PPML), > https://www.arin.net/participate/mailing_lists/index.html Thanks for the pointer, Scott, I will have a look. George From wavetossed at googlemail.com Fri Dec 25 00:01:48 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 25 Dec 2009 00:01:48 +0000 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> >> imagine a network engineering culture where the concept of 'attempt to >> deviate' just does not occur. > > Are you trying to suggest that this is something horrible, or that it's the future of network engineering? :) The model of network engineering that grew up during the 1990s is forever gone unless you work in a smaller organization where people have to wear many hats. In the big ISPs, now identical to the big telcos, operations and engineering design duties are separated. The operations folks do not deviate from the written plans that they work with. If the slightest thing happens that is not in the plan, they rollback the changes as specified in the plan. They don't fix anything unless it is officially broken with trouble tickets filed and escalations up to senior management. That is about the only time that operations people can get away with taking shortcuts and creative solutions. On the other hand, the engineering design folks should spend a good part of their day trying out things, thinking up new ideas, poking around equipment and software to see how far it can be pushed. Then, when they have learned something and are ready to implement it in the network, they write a detailed plan for operations. Then some other engineering folks test the heck out of that design to try and find fault with it. After all the faults are fixed, it goes to operations and the engineering design folks move on to something else unless serious problems occur and operations needs a design engineer to approve some sensible action to be taken. The operations folk can't take the sensible action because that would deviate from their plans, but getting engineering design folks involved, gives them an out for real emergencies. So the term "network engineering" is ambiguous because a lot of people use it to mean the 90's style job where engineering design activity and operational activity were all jumbled together. In some companies, taking the engineering design track not only means that you lose enable on the routers, but you lose all TACACS access and have to get authorisation from a VP just to ask for a copy of the running config on a production router. Some people like ops because they see a lot of stuff go by and learn from it, get their CCIE and move into design engineering. Others like ops because they are scared of the responsibility for thinking up what to do next, and making a mistake. As far as I can see, the only way to get a job that mixes ops and design is to be in 3rd or 4th level support which is the top of the technical escalation chain where a few excellent design engineers do have enable on the routers because they fix important problems in near realtime. I suspect that it would be advantageous to have a career in which you worked for a while in ops before moving into design engineering if you want to get into top-level support. Take all this with a grain of salt. Every company does things a bit different, and the terminology that is used is ambiguous. It would be interesting to see what others have to say about this answer. --Michael Dillon From wavetossed at googlemail.com Fri Dec 25 00:11:22 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 25 Dec 2009 00:11:22 +0000 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7104@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F7104@RWC-EX1.corp.seven.com> Message-ID: <877585b00912241611t752c07e3x1331faff9b716ee3@mail.gmail.com> > I can't in good conscience justify a /32. ?That is just too much space. Then you need to go back to IPv6 101. > I believe I can, however, justify a separate /48 in Europe and APAC with > my various offices and data centers in that region coming from the /48 > for that region. A /48 is for a single site. If you are operating a network connecting many sites, then you are a network operator and should get a /32 block. Don't try to fit more into a /48 than one single site. If you need to announce /33 or /34 prefixes to make things work, then deal with it. Talk to providers and explain what is going on. IPv6 routing is in its infancy and many people tend to set it up and let it run on autopilot. There is no law saying that you must announce one and only one /32 aggregate everywhere. For real technical solutions to your problem, you are probably better off going to the IPv6-ops list Subscription info is here --Michael Dillon --Michael Dillon From leo.vegoda at icann.org Fri Dec 25 00:17:15 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 24 Dec 2009 16:17:15 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: References: Message-ID: <079DEF09-0CBF-41CB-B07A-910D796E10BE@icann.org> On Dec 24, 2009, at 8:59 AM, Jon Lewis wrote: [?] >> I am sure that your interpretation was the original intent of the policy >> text. However, the wording could also be read in a way that allows an LIR to >> just provide registry services, without providing any connectivity services. > > That's one hell of a stretch. Registry services aren't needed if they > don't have the IP space, so saying that the service the end user is buying > that justifies the IP assignment is 'registration services' is a circular > argument. Of course - but if you wanted to provide services to spammers and their friends it's the sort of stretch you'd find yourself making. Regards, Leo From gbonser at seven.com Fri Dec 25 01:37:30 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Dec 2009 17:37:30 -0800 Subject: IPv6 allocations, deaggregation, etc. In-Reply-To: <877585b00912241611t752c07e3x1331faff9b716ee3@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7101@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE081F7104@RWC-EX1.corp.seven.com> <877585b00912241611t752c07e3x1331faff9b716ee3@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7117@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Michael Dillon [mailto:wavetossed at googlemail.com] > Sent: Thursday, December 24, 2009 4:11 PM > To: nanog at nanog.org > Subject: Re: IPv6 allocations, deaggregation, etc. > > > I can't in good conscience justify a /32. ?That is just too much > space. > > Then you need to go back to IPv6 101. This is an end user application, not an ISP application. Something between a /32 and a /48 would suffice. The idea was that a /32 is too large (in my opinion) for an organization that isn't planning on having more than 20 sites in the next 5 years. If it were 200, that would be a different story. If having a block smaller than a /32 breaks something, then it needs to break early so it can be addressed before things progress much further. And getting a /32 would appear to violate ARIN's policy: 6.5.8.2. Initial assignment size Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. An HD-Ratio of .94 must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. If we were to number all sites globally into a /45, we could meet the .94 HD-Ratio but with the potential problems noted in earlier traffic on this thread. I am now leaning toward expanding my request to a /45 if we go with a global block or a /46 if we go with only using ARIN allocations in North American operations. > Don't try to fit more into a /48 than one single site. Yeah, I think I pretty much "get" that, at this point. I can hang small offices off of a data center, giving them one or more /56 nets each but yeah, trying to split a /48 between data centers is probably counter-productive. > If you need to announce /33 or /34 prefixes to make things work, then > deal with it. Talk to providers and explain what is going on. IPv6 > routing > is in its infancy and many people tend to set it up and let it run on > autopilot. There is no law saying that you must announce one and > only one /32 aggregate everywhere. Agreed. Wasn't planning on it but if we did eventually become fully integrated globally, I would probably announce the larger aggregate(s) out of one main location, maybe handing any unassigned traffic to a honey-net or something. At least if a mistake is made somewhere in addressing, that would give me a "backstop" so that we could provide a temporary fix for the problem quickly until it got fixed correctly. If someone misconfigures something and traffic goes out with the wrong subnet SA but still in our block (say someone transposes a couple of subnet digits someplace), at least the reply traffic would come back to someplace I have some control over and could route (or tunnel) the reply traffic back to where it needs to go until the root cause could be fixed. It would be ugly and slow for a while but it wouldn't be completely broken until a maintenance window where we could correct the underlying problem. Things like that offers an opportunity to fix emergencies quickly and schedule more disruptive corrective actions for a later time when people can plan for the outage. It is yet another advantage of having a larger global block over a gaggle of smaller scattered blocks. > > For real technical solutions to your problem, you are probably better > off > going to the IPv6-ops list Signed up yesterday :) > > --Michael Dillon Thanks, Michael. George From rdobbins at arbor.net Fri Dec 25 01:53:25 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 25 Dec 2009 01:53:25 +0000 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> Message-ID: On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote: > It would be interesting to see what others have to say about this answer. I think it's a pretty accurate summation of how these things work in a lot of big organizations, all over the world. There's a detrimental side to it, in that in the engineering org, the near-complete siloing away from ops can lead to an ivory-tower/King Canute type of mentality; in the ops org, this phenomenon in turn can lead to increasing frustration and lowered morale, which in turn leads to apathy and poor customer service. All too often, one ends up with mutually-hostile engineering and ops teams who waste time and energy actively working to frustrate one another's ambitions, rather than combining their efforts to design, build, and operate the best network possible. Which in turn leads to many of the frustrations experienced every day by the end-customer. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From gbonser at seven.com Fri Dec 25 02:27:37 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Dec 2009 18:27:37 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com><4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org><877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Dobbins, Roland > > On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote: > > > It would be interesting to see what others have to say about this > answer. > > I think it's a pretty accurate summation of how these things work in a > lot of big organizations, all over the world. I think that one must keep in mind that there are two kinds of check-lists. There is a takeoff list where you can always choose to go back to the ramp and fly another day if something doesn't check out but there is a different priority when someone is already in the air and something goes wrong. You can't decide to land a different day. In that case you must rely on experience and knowledge to handle the situation as it presents itself. Sure, you can have some basic checks for things even in an emergency but you can't know how the problem is going to present itself ahead of time. In cases like that you have set of general parameters but the person "at the controls" needs to have leeway to both clearly identify the nature of the problem and mitigate the same if possible and that might include calling in some extra eyes in order to identify things that might be going on with applications or other devices that aren't specifically network gear. So you can put a lot of process around changes in advance but there isn't quite as much to manage incidents that strike out of the clear blue. Too much process at that point could impede progress in clearing the issue. Capt. Sullenberger did not need to fill out an incident report, bring up a conference bridge, and give a detailed description of what was happening with his plane, the status of all subsystems, and his proposed plan of action (subject to consensus of those on the conference bridge) and get approval for deviation from his initial flight plan before he took the required actions to land the plane as best as he could under the circumstances. And while that is a bit extreme in the sense of most networks in that lives are not often at stake, some concepts are the same (and there might be networks supporting various occupations on this planet where lives might actually be at stake in the case of a network failure during some sort of activity). One of the most efficient shops I worked in was when the production internet operation was owned by the engineering department. Corporate operations owned the internal corporate IT, but engineering owned the internet production data centers and network operations. If engineering released a code revision that blew up the network, the VP of Engineering was responsible for the entire picture, not just the software piece. Same is true where a networking change blew up the application. Having the responsibility for the entire "system" (software, hardware platforms, and networking) under the same organization resulted in a lot smoother operation without backbiting and greater access to and sharing of resources between the application engineers, the systems administrators, and the network engineers. From rdobbins at arbor.net Fri Dec 25 02:51:11 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 25 Dec 2009 02:51:11 +0000 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com><4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org><877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> Message-ID: On Dec 25, 2009, at 9:27 AM, George Bonser wrote: > Capt. Sullenberger did not need to fill out an incident > report, bring up a conference bridge, and give a detailed description of > what was happening with his plane, the status of all subsystems, and his > proposed plan of action (subject to consensus of those on the conference > bridge) and get approval for deviation from his initial flight plan > before he took the required actions to land the plane as best as he > could under the circumstances. Conversely, the ever-increasing outright hostility and contempt evinced towards their customers by airlines worldwide - especially US-based airlines - over the last decade or so, all in the name of 'regulations', offers a useful counterexample. When it comes to larger organizations, this latter scenario is more the norm than what you describe, in my experience. Critical problems are left unresolved for days/weeks/months; if one attempts to report an issue which is causing problems for many of an organizations customers worldwide, but one isn't oneself a direct customer of said organization, one is often as not ignored and shunted aside. This isn't specific to the SP realm; it's simply a function of increased size, which leads to increased bureaucritization, which leads to dehumanization and the subordination of the organization's ostensible goals to internal politics, one-upsmanship, and blame-laying, no matter the industry in question. The folks with a can-do attitude who're willing to buck the system in order to do the right thing for the customer stand out in stark contrast to their peers, and in many cases end up paying a price in terms of career advancement because of their willingness to Do The Right Thing. 'Process' is all too often merely a ruse designed to avoid responsibility, shift blame/liability, justify hiring lower-cost/unqualified employees whilst shedding expensive/competent employees, and indulge in empire-building. We've seen this throughout corporate America with the 'permanent Y2K' of SoX and HIPAA, and the increasing involvement of government in terms of telecommunications-related rule-making which ends up directly affecting SPs. I'm a big advocate of standards and change-control, and not an advocate of seat-of-the-pants, midnight engineering - except when the latter is necessary, as in the examples you give. Unfortunately, many folks who work in larger organizations are actively prohibited from indulging in fluid, situationally-approrpriate problem resolution; and because of the aforementioned siloing of ops and engineering, their valuable first-hand experiences and the lessons learned thereby aren't taken into account during the design and rulemaking processes. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From scott at doc.net.au Fri Dec 25 07:08:39 2009 From: scott at doc.net.au (Scott Howard) Date: Thu, 24 Dec 2009 23:08:39 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> Message-ID: On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote: > So you can put a lot of process around changes in advance but there > isn't quite as much to manage incidents that strike out of the clear > blue. Too much process at that point could impede progress in clearing > the issue. Capt. Sullenberger did not need to fill out an incident > report, bring up a conference bridge, and give a detailed description of > what was happening with his plane, the status of all subsystems, and his > proposed plan of action (subject to consensus of those on the conference > bridge) and get approval for deviation from his initial flight plan > before he took the required actions to land the plane as best as he > could under the circumstances. "*mayday mayday mayday. **Cactus fifteen thirty nine hit birds, we've lost thrust (in/on) both engines we're turning back towards LaGuardia*" - Capt. Sullenberger Not exactly "detailed", but he definitely initiated an "incident report" (the mayday), gave a "description of what was happening with his plane", the "status of [the relevant] subsystems", and his proposed plan of action - even in the order you've asked for! His actions were then "subject to the consensus of those on the conference bridge" (ie, ATC) who could have denied his actions if they believed they would have made the situation worse (ie, if what they were proposing would have had them on a collision course with another plane). In this case, the conference bridge gave approval for his course of action ("*ok uh, you need to return to LaGuardia? turn left heading of uh two two zero.*" - ATC) 5 seconds before they made the above call they were reaching for the QRH (Quick Reference Handbook), which contains checklists of the steps to take in such a situation - including what to do in the event of loss of both engines due to multiple birdstrikes. They had no need to confer with others as to what actions to take to try and recover from the problem, or what order to take them in, because that pre-work had already been carried out when the check-lists were written. Of course, at the end of the day, training, skill and experience played a very large part in what transpired - but so did the actions of the people on the "conference bridge" (You can't get much more of a "conference bridge" than open radio frequencies), and the checklists they have for almost every conceivable situation. Scott. From gbonser at seven.com Fri Dec 25 08:16:43 2009 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Dec 2009 00:16:43 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> I think any network engineer who sees a major problem is going to have a "Houston, we have a problem" moment. And actually, he was telling the ATC what he was going to need to do, he wasn't getting permission so much as telling them what he was doing so traffic could be cleared out of his way. First he told them he was returning to the airport, then he inquired about Peterburough, the ATC called Peterburough to get a runway and inform them of an inbound emergency, then the Captain told the ATC they were going to be in the Hudson. And "I hit birds, have lost both engines, and am turning back" results in a whole different chain of events these days than "I have two guys banging on the cockpit door and am returning" or simply turning back toward the airport with no communication. And any network engineer is going to say something if he sees CPU or bandwidth utilization hit the rail in either direction. Saying something like "we just got flooded with thousands of /24 and smaller wildly flapping routes from peer X and I am shutting off the BGP session until they get their stuff straight" is different than "we just got flooded with thousands of routes and it is blowing up the router and all the other routers talking to it. Can I do something about it?" And that illustrates a point that is key. In that case the ATC was asking what the pilot needed and was prepared to clear traffic, get emergency equipment prepared, whatever it took to get that person dealing with the problem whatever they needed to get it resolved in the best way forward. The ATC isn't asking him if he was sure he set the flaps at the right angle and "did you try to restart the engine" sorts of things. What I was getting at is that sometimes too much process can get in the way in an emergency and the time taken to implement such process can result in a failure cascading through the network making the problem much worse. I have much less of a problem with process surrounding planned events. The more the better as long as it makes sense. Migrations and additions and modifications *should* be well planned and checklisted and have backout points and procedures. That is just good operations when you have tight SLAs and tight maintenance windows with customers you want to keep. Happy Holidays George From: Scott Howard "mayday mayday mayday. Cactus fifteen thirty nine hit birds, we've lost thrust (in/on) both engines we're turning back towards LaGuardia" - Capt. Sullenberger Not exactly "detailed", but he definitely initiated an "incident report" (the mayday), gave a "description of what was happening with his plane", the "status of [the relevant] subsystems", and his proposed plan of action - even in the order you've asked for! His actions were then "subject to the consensus of those on the conference bridge" (ie, ATC) who could have denied his actions if they believed they would have made the situation worse (ie, if what they were proposing would have had them on a collision course with another plane). In this case, the conference bridge gave approval for his course of action ("ok uh, you need to return to LaGuardia? turn left heading of uh two two zero." - ATC) 5 seconds before they made the above call they were reaching for the QRH (Quick Reference Handbook), which contains checklists of the steps to take in such a situation - including what to do in the event of loss of both engines due to multiple birdstrikes. They had no need to confer with others as to what actions to take to try and recover from the problem, or what order to take them in, because that pre-work had already been carried out when the check-lists were written. Of course, at the end of the day, training, skill and experience played a very large part in what transpired - but so did the actions of the people on the "conference bridge" (You can't get much more of a "conference bridge" than open radio frequencies), and the checklists they have for almost every conceivable situation. Scott. From avg at kotovnik.com Fri Dec 25 10:44:09 2009 From: avg at kotovnik.com (Vadim Antonov) Date: Fri, 25 Dec 2009 02:44:09 -0800 (PST) Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> Message-ID: Just clearing a small point about pilots (I'm a pilot) - the pilot-in-command has ultimate responsibility for his a/c and can ignore whatever ATC tells him to do if he considers that to be contrary to the safety of his flight (he may be asked to explain his actions later, though). Now, usually ignoring ATC or keeping it in the dark about one's intentions is not very clever - but dispatchers are not in the cockpit and may misunderstand the situation or be simply mistaken about something (so a pilot is encouraged to decline ATC instructions he considers to be in error - informing ATC about it, of course). But one of the first things a pilot does in an emergency is pulling out the appropriate emergency checklist. It is kind of hard to keep from forgetting to check obvious things when things get hectic (one of the distressingly common causes of accidents is trivial running out of fuel - either because the pilot didn't do homework on the ground (checking actual fuel level in tanks, etc) or because when the engine got suddenly quiet he forgot to switch to another, non-empty, tank). The mantra about priorities in both normal and emergency situations is "Aviate-Navigate-Communicate" meaning that maintaining control of a/c always comes first, no matter what. Knowing where you are and where you are going (and other pertinent situational awareness such as condition of the a/c and current plan of actions) come second. Talking is lowest priority. The pre-planned emergency checklists may be a good idea for network operators. Try obvious (when you're calm, that's it) actions first, if they fail to help, try to limit damage. Only then go file the ticket and talk to people who can investigate situation in depth and can develop a fix. The way aviation industry come with these checklists is, basically, experience - it pays to debrief after recovery from every problem not adequately fixed by existing procedures, find common ones, and develop diagnostic procedure one could follow step-by-step for these situations. (The non-punitive error or incident reporting which actually shields pilots from FAA enforcement actions in most cases also helps to collect real-world information on where and how pilots get into trouble). The all-too-common multistep ticket escalation chains (which merely work as delay lines in a significant portion of cases) is something to be avoided. Even better is to provide some drilling in diagnostic and recovery from common problems to the front-line personnel - starting from following the checklist on a simulated outage in the lab, and then getting it down to what pilots call "the flow" - a habitual memorized procedure, which is performed first and then checked against the checklist. Note that use of checklists, drilling, and flows does not make pilots a kind of robots - they still have to make decisions, recognize and deal with situations not covered in the standard procedures; what it does is speeding up dealing with common tasks, reduces mistakes, and frees up mental processing for thinking ahead. The ISP industry has a long way to go until it reaches the same level of sophistication in handling problems as aviation has. --vadim On Fri, 25 Dec 2009, George Bonser wrote: > I think any network engineer who sees a major problem is going to have a > "Houston, we have a problem" moment. And actually, he was telling the > ATC what he was going to need to do, he wasn't getting permission so > much as telling them what he was doing so traffic could be cleared out > of his way. First he told them he was returning to the airport, then he > inquired about Peterburough, the ATC called Peterburough to get a runway > and inform them of an inbound emergency, then the Captain told the ATC > they were going to be in the Hudson. And "I hit birds, have lost both > engines, and am turning back" results in a whole different chain of > events these days than "I have two guys banging on the cockpit door and > am returning" or simply turning back toward the airport with no > communication. And any network engineer is going to say something if he > sees CPU or bandwidth utilization hit the rail in either direction. > Saying something like "we just got flooded with thousands of /24 and > smaller wildly flapping routes from peer X and I am shutting off the BGP > session until they get their stuff straight" is different than "we just > got flooded with thousands of routes and it is blowing up the router and > all the other routers talking to it. Can I do something about it?" > > > > And that illustrates a point that is key. In that case the ATC was > asking what the pilot needed and was prepared to clear traffic, get > emergency equipment prepared, whatever it took to get that person > dealing with the problem whatever they needed to get it resolved in the > best way forward. The ATC isn't asking him if he was sure he set the > flaps at the right angle and "did you try to restart the engine" sorts > of things. > > > > What I was getting at is that sometimes too much process can get in the > way in an emergency and the time taken to implement such process can > result in a failure cascading through the network making the problem > much worse. I have much less of a problem with process surrounding > planned events. The more the better as long as it makes sense. > Migrations and additions and modifications *should* be well planned and > checklisted and have backout points and procedures. That is just good > operations when you have tight SLAs and tight maintenance windows with > customers you want to keep. > > > > Happy Holidays > > > > George > > > > > > From: Scott Howard > > > > > > "mayday mayday mayday. Cactus fifteen thirty nine hit birds, we've lost > thrust (in/on) both engines we're turning back towards LaGuardia" - > Capt. Sullenberger > > Not exactly "detailed", but he definitely initiated an "incident report" > (the mayday), gave a "description of what was happening with his plane", > the "status of [the relevant] subsystems", and his proposed plan of > action - even in the order you've asked for! > > > His actions were then "subject to the consensus of those on the > conference bridge" (ie, ATC) who could have denied his actions if they > believed they would have made the situation worse (ie, if what they were > proposing would have had them on a collision course with another plane). > In this case, the conference bridge gave approval for his course of > action ("ok uh, you need to return to LaGuardia? turn left heading of uh > two two zero." - ATC) > > 5 seconds before they made the above call they were reaching for the QRH > (Quick Reference Handbook), which contains checklists of the steps to > take in such a situation - including what to do in the event of loss of > both engines due to multiple birdstrikes. They had no need to confer > with others as to what actions to take to try and recover from the > problem, or what order to take them in, because that pre-work had > already been carried out when the check-lists were written. > > Of course, at the end of the day, training, skill and experience played > a very large part in what transpired - but so did the actions of the > people on the "conference bridge" (You can't get much more of a > "conference bridge" than open radio frequencies), and the checklists > they have for almost every conceivable situation. > > Scott. > > From swmike at swm.pp.se Fri Dec 25 10:57:41 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 25 Dec 2009 11:57:41 +0100 (CET) Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: Message-ID: On Fri, 25 Dec 2009, Vadim Antonov wrote: > The ISP industry has a long way to go until it reaches the same level of > sophistication in handling problems as aviation has. Well, to counter this one might talk about the medical business (doctors) which hasn't been able to embrace the checklists at all (apart from in a few places), and they still consider their profession to be a craft, just like most network engineers do. It's the classical "good/fast/cheap, please pick two". Aviation is slow/careful to bring in new tech, same with the health care side, they're both very conservative. We in the network business are still immature but quick and flexible, but as time goes on, our services are more and more important, and thus things settle in and slow down, but becomes more reliable. This is an evoltion that'll take quite some time, but it's already changed a lot the past 10 years. There was quite a buzz regarding doctor checklists a few years back, I read several articles about it, but now I can't find the one I want to find, but talks a bit about the topic. -- Mikael Abrahamsson email: swmike at swm.pp.se From tkapela at gmail.com Fri Dec 25 15:57:06 2009 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 25 Dec 2009 10:57:06 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> Message-ID: <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov wrote: > The ISP industry has a long way to go until it reaches the same level of > sophistication in handling problems as aviation has. It seems that there's a logical fallacy floating around somewhere (networks have parts and are complicated, airplanes and flight involve lots of parts and are also complicated, therefore aircraft are like networks). I assert that comparing 'packet switching' to an industry that has its roots in the late 1800's and had its first "hello world" moment in 1903 isn't terribly fruitful. Further, aircraft are the asymptotic limit of 'singly homed transit.' Because of this, I think one could argue that pilots and ATC must be held to a different professional standard due to the nature of public trust at risk. At the other end of our strawman spectrum, we have end users who must accept the risk that their provider will be unable to connect them to lolcats.com on occasion, perhaps as often as 0.01% per year, and most are happy to accept this. Four nines survivability on flights, clearly, won't work. What I'm getting at is that after following this thread for a while, I'm not convinced any amount of process-borrowing is going to solve problems better, faster, or even avoid them in the first place. At best, our craft is 1/3rd as "old" (if that's somehow I measure of maturity) as flight and nobody is being sued to settle 200+ accidental deaths because of our mistakes. -Tk From nanog-post at rsuc.gweep.net Fri Dec 25 17:09:54 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 25 Dec 2009 12:09:54 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> Message-ID: <20091225170954.GA79396@gweep.net> On Thu, Dec 24, 2009 at 01:09:26PM -0500, Randy Bush wrote: > > I _do_ create action plans and _do_ quarterback each step and _do_ > > slap down any attempt to deviate. > > imagine a network engineering culture where the concept of 'attempt to > deviate' just does not occur. Whimsical deviations don't belong in the maint execution, they belong in the brainstorming and design. Gather more points of view during the peer review of the specification of work. In my experience, good engineering makes for bad drama (and conversely if it is a "dramatic save" then you have a bad engineer and likely a cowboy). Have a plan that executes in stages, tests at checkpoints where partial completion is possible, and a fallback for each step. A great way to train up junior people, document as you go, expose flaws and lines of future investigation, and if things go south you escalte to those who can judge *reasonable* new directions. To me, that kind of change management for non-automatable work is a descendent of resonable group work. If you have project-oriented autonomous teams that stick to the guideposts of "your standards" and "minimal disruptions/maximal uptime" then good work will emerge. As for automation, that enables your expensive hmans to do more smart things so should always be incorporated in processes and be something people move toward, IMO. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bross at pobox.com Fri Dec 25 18:22:55 2009 From: bross at pobox.com (bross at pobox.com) Date: Fri, 25 Dec 2009 13:22:55 -0500 (EST) Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> Message-ID: On Thu, 24 Dec 2009, Scott Howard wrote: > His actions were then "subject to the consensus of those on the conference > bridge" (ie, ATC) who could have denied his actions if they believed they > would have made the situation worse (ie, if what they were proposing would > have had them on a collision course with another plane). This has been mentioned by others in this thread, but not to the level of importance I think it represents. I, too, am a pilot. The pilot in command of an aircraft always has the final say on the safety of the flight, not the controller, and not the design engineers. If the pilot in command violates the rules and the result is negative (crash, loss of separation, etc.) you better believe there will be questions to be answered and a possible loss of the pilot's license (or life!) may result. On the other hand if the pilot's decision to violate the rules results in a positive outcome (see Sullenburger or any other number of emergencies that happen every day that you never hear about) there will often never even be a single question about why the rules were violated. This can be applied directly to network engineering work. If I assign an engineer to do a network change, yes, they better have a plan/checklist/etc. before they start and they better follow it. When things go wrong, I expect that engineer to make the right decisions to minimize the damage. Sometimes that means following the rules to the letter. Sometimes that means breaking the rules. If the rules are broken, there darn better be a good reason for it, but frankly, a good engineer will always have a good explanation, just like the good pilot. Rigid procedures are no better than the lack of procedures. Process is very important, don't get me wrong, but so is the knowledge and experience to know when you should throw them out the door. Any organization that doesn't recognize that is doomed to inefficiency at best, and failure at worst. -- Brandon Ross AIM: BrandonNRoss Director of Network Engineering ICQ: 2269442 Xiocom Wireless Skype: brandonross Yahoo: BrandonNRoss From cscora at apnic.net Fri Dec 25 18:31:18 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Dec 2009 04:31:18 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200912251831.nBPIVIZB011708@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 26 Dec, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 308286 Prefixes after maximum aggregation: 143053 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 151084 Total ASes present in the Internet Routing Table: 32979 Prefixes per ASN: 9.35 Origin-only ASes present in the Internet Routing Table: 28631 Origin ASes announcing only one prefix: 13989 Transit ASes present in the Internet Routing Table: 4348 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 53 Max AS path prepend of ASN (38753) 50 Prefixes from unregistered ASNs in the Routing Table: 698 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 377 Prefixes from 32-bit ASNs in the Routing Table: 335 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 159 Number of addresses announced to Internet: 2166385920 Equivalent to 129 /8s, 32 /16s and 109 /24s Percentage of available address space announced: 58.4 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.5 Total number of prefixes smaller than registry allocations: 148666 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 74669 Total APNIC prefixes after maximum aggregation: 25729 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 71353 Unique aggregates announced from the APNIC address blocks: 31168 APNIC Region origin ASes present in the Internet Routing Table: 3892 APNIC Prefixes per ASN: 18.33 APNIC Region origin ASes announcing only one prefix: 1060 APNIC Region transit ASes present in the Internet Routing Table: 606 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 53 Number of APNIC addresses announced to Internet: 486028576 Equivalent to 28 /8s, 248 /16s and 53 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 129610 Total ARIN prefixes after maximum aggregation: 67484 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 103736 Unique aggregates announced from the ARIN address blocks: 39062 ARIN Region origin ASes present in the Internet Routing Table: 13437 ARIN Prefixes per ASN: 7.72 ARIN Region origin ASes announcing only one prefix: 5206 ARIN Region transit ASes present in the Internet Routing Table: 1334 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 734241056 Equivalent to 43 /8s, 195 /16s and 161 /24s Percentage of available ARIN address space announced: 64.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70597 Total RIPE prefixes after maximum aggregation: 41388 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 63982 Unique aggregates announced from the RIPE address blocks: 42697 RIPE Region origin ASes present in the Internet Routing Table: 13910 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7240 RIPE Region transit ASes present in the Internet Routing Table: 2094 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 409151808 Equivalent to 24 /8s, 99 /16s and 41 /24s Percentage of available RIPE address space announced: 76.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26893 Total LACNIC prefixes after maximum aggregation: 6525 LACNIC Deaggregation factor: 4.12 Prefixes being announced from the LACNIC address blocks: 25237 Unique aggregates announced from the LACNIC address blocks: 13799 LACNIC Region origin ASes present in the Internet Routing Table: 1223 LACNIC Prefixes per ASN: 20.64 LACNIC Region origin ASes announcing only one prefix: 391 LACNIC Region transit ASes present in the Internet Routing Table: 202 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 69604864 Equivalent to 4 /8s, 38 /16s and 22 /24s Percentage of available LACNIC address space announced: 69.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5959 Total AfriNIC prefixes after maximum aggregation: 1595 AfriNIC Deaggregation factor: 3.74 Prefixes being announced from the AfriNIC address blocks: 4364 Unique aggregates announced from the AfriNIC address blocks: 1547 AfriNIC Region origin ASes present in the Internet Routing Table: 335 AfriNIC Prefixes per ASN: 13.03 AfriNIC Region origin ASes announcing only one prefix: 92 AfriNIC Region transit ASes present in the Internet Routing Table: 71 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14527744 Equivalent to 0 /8s, 221 /16s and 173 /24s Percentage of available AfriNIC address space announced: 43.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1785 7509 465 Korea Telecom (KIX) 17488 1459 145 133 Hathway IP Over Cable Interne 4755 1285 291 146 TATA Communications formerly 4134 1014 19445 398 CHINANET-BACKBONE 9583 998 75 505 Sify Limited 18101 997 204 37 Reliance Infocom Ltd Internet 7545 920 198 94 TPG Internet Pty Ltd 9829 848 676 23 BSNL National Internet Backbo 17974 843 272 62 PT TELEKOMUNIKASI INDONESIA 4808 833 1583 211 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4187 3891 306 bellsouth.net, inc. 4323 3777 1068 400 Time Warner Telecom 1785 1798 699 134 PaeTec Communications, Inc. 7018 1588 5791 1031 AT&T WorldNet Services 20115 1534 1486 666 Charter Communications 2386 1287 615 928 AT&T Data Communications Serv 3356 1205 10930 424 Level 3 Communications, LLC 11492 1153 222 14 Cable One 22773 1122 2600 66 Cox Communications, Inc. 6478 1099 242 304 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 518 99 208 Evolva Telecom 35805 511 40 5 United Telecom of Georgia 3292 448 1903 393 TDC Tele Danmark 702 419 1837 337 UUNET - Commercial IP service 8551 386 354 41 Bezeq International 8866 378 110 23 Bulgarian Telecommunication C 3320 361 7068 307 Deutsche Telekom AG 3301 350 1412 306 TeliaNet Sweden 3215 349 3160 112 France Telecom Transpac 12479 314 578 6 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1570 2898 230 UniNet S.A. de C.V. 10620 1005 224 131 TVCABLE BOGOTA 28573 829 674 84 NET Servicos de Comunicao S.A 7303 665 351 96 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 11172 446 99 70 Servicios Alestra S.A de C.V 6503 444 163 183 AVANTEL, S.A. 14117 437 29 11 Telefonica del Sur S.A. 7738 431 858 29 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1039 444 8 TEDATA 24863 714 142 54 LINKdotNET AS number 3741 273 857 233 The Internet Solution 2018 178 196 100 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 157 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 114 505 68 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4187 3891 306 bellsouth.net, inc. 4323 3777 1068 400 Time Warner Telecom 1785 1798 699 134 PaeTec Communications, Inc. 4766 1785 7509 465 Korea Telecom (KIX) 7018 1588 5791 1031 AT&T WorldNet Services 8151 1570 2898 230 UniNet S.A. de C.V. 20115 1534 1486 666 Charter Communications 17488 1459 145 133 Hathway IP Over Cable Interne 2386 1287 615 928 AT&T Data Communications Serv 4755 1285 291 146 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3777 3377 Time Warner Telecom 1785 1798 1664 PaeTec Communications, Inc. 8151 1570 1340 UniNet S.A. de C.V. 17488 1459 1326 Hathway IP Over Cable Interne 4766 1785 1320 Korea Telecom (KIX) 4755 1285 1139 TATA Communications formerly 11492 1153 1139 Cable One 22773 1122 1056 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1039 1031 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:65 /12:181 /13:381 /14:652 /15:1234 /16:10834 /17:5044 /18:8613 /19:17732 /20:21648 /21:21638 /22:27984 /23:28122 /24:161157 /25:934 /26:1177 /27:585 /28:222 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2727 4187 bellsouth.net, inc. 4323 2368 3777 Time Warner Telecom 4766 1435 1785 Korea Telecom (KIX) 1785 1265 1798 PaeTec Communications, Inc. 17488 1224 1459 Hathway IP Over Cable Interne 11492 1073 1153 Cable One 18566 1040 1059 Covad Communications 7018 958 1588 AT&T WorldNet Services 8452 935 1039 TEDATA 10620 910 1005 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:242 12:2019 13:9 15:22 16:3 17:8 20:37 24:1291 32:49 38:637 40:99 41:1868 44:3 46:1 47:30 52:6 55:2 56:2 57:24 58:644 59:657 60:446 61:1098 62:970 63:2014 64:3801 65:2371 66:4117 67:1855 68:1041 69:2807 70:686 71:231 72:1884 73:3 74:2075 75:223 76:362 77:864 78:600 79:405 80:963 81:803 82:460 83:439 84:515 85:1000 86:379 87:692 88:420 89:1550 90:63 91:2667 92:418 93:1137 94:1340 95:785 96:194 97:290 98:463 99:23 109:202 110:281 111:516 112:161 113:219 114:296 115:470 116:1091 117:592 118:385 119:804 120:148 121:823 122:1359 123:806 124:1012 125:1303 128:212 129:201 130:134 131:455 132:83 133:16 134:188 135:41 136:228 137:168 138:234 139:82 140:463 141:122 142:376 143:335 144:390 145:53 146:390 147:180 148:564 149:196 150:151 151:172 152:228 153:162 154:2 155:270 156:174 157:332 158:98 159:355 160:305 161:174 162:281 163:221 164:309 165:472 166:490 167:393 168:761 169:160 170:571 171:42 172:1 173:404 174:529 175:20 180:268 183:171 184:3 186:243 187:217 188:1075 189:613 190:3415 192:5713 193:4361 194:3368 195:2776 196:1183 198:3552 199:3389 200:5233 201:1448 202:8018 203:8311 204:3984 205:2168 206:2424 207:3072 208:3944 209:3425 210:2565 211:1158 212:1652 213:1646 214:261 215:58 216:4438 217:1380 218:478 219:455 220:1166 221:449 222:300 End of report From gbonser at seven.com Fri Dec 25 19:53:14 2009 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Dec 2009 11:53:14 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F711B@RWC-EX1.corp.seven.com> > What I'm getting at is that after following this thread for a while, > I'm not convinced any amount of process-borrowing is going to solve > problems better, faster, or even avoid them in the first place. At > best, our craft is 1/3rd as "old" (if that's somehow I measure of > maturity) as flight and nobody is being sued to settle 200+ accidental > deaths because of our mistakes. > > -Tk Not now, that is true, but when you look at things that are "on the drawing board" such as systems designed to manage automobile traffic flows, networks that are used to fly UAVs, networks that keep track of "friendly" units in combat where the technology might someday migrate to civilian law enforcement and/or emergency services (keeping track of where firefighters are in a building or at a wildfire, for example), I can see situations in the future where people's lives could be dependent on networks working properly, or at least endangered if a network fails. But my original intent was to point out that there are two kinds of process for two different kinds of circumstances and the sort of process surrounding routine changes might not be the best process for handing emergency changes. I have seen examples of places that want to handle emergency changes with the same sort of process they use for routine changes and those places can be frustrating to work with when stuff is broken. My goal was to give managers of networks who might read this the idea that when the fan is in an unsavory condition, more can get done by shifting from a mode of questioning, analyzing and second-guessing everything the engineer is doing to a mode where the organization is responding to immediate needs, clearing obstacles out of the way, and documenting as best they can what is done and when, to make the debriefing afterwards easier. AFTER the incident is the time to go over what was done, think about how it was dealt with, consider any changes in emergency process that might have shortened the duration, etc. In fact the "What could we have done differently that would have shortened the duration of the outage" question is pretty important. The answer might be "nothing", and that is ok, too, but the question should be asked. From Michael_OReirdan at Cable.Comcast.com Fri Dec 25 20:24:35 2009 From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael) Date: Fri, 25 Dec 2009 15:24:35 -0500 Subject: Article on spammers and their infrastructure References: Message-ID: <45AEC6EF95942140888406588E1A6602089DBF94@PACDCEXCMB04.cable.comcast.com> I expect the ARIN and RIPE folks may be influential and as such, it could be a good idea for them to attend. Mike ________________________________ From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Thu 12/24/2009 3:13 PM To: O'Reirdan, Michael Cc: J.D. Falk; nanog at nanog.org Subject: Re: Article on spammers and their infrastructure Wouldn't that be kind of pointless? ARIN policies are proposed by the public, not ARIN staff or board members. https://www.arin.net/policy/pdp.html Policy proposals may be submitted by anyone in the global Internet community except for members of the ARIN Board of Trustees or the ARIN staff. On Wed, 23 Dec 2009, O'Reirdan, Michael wrote: > JD > > Great point, I am more than happy to have a couple of people from ARIN or > RIPE as guests at the next MAAWG in SFO or the subsequent one in Barcelona. > > Mike > > > On 12/23/09 1:18 PM, "J.D. Falk" wrote: > >> On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote: >> >>>> On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson >>> wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Folks should not be so obtuse about these activities. It's almost >>>> blatantly >>>>>> in-your-face, so to speak. These guys have no fear of retribution. >>>> >>>> no real arguement, but... 'please provide some set of workable solutions' >>>> >>>> The ARIN meetings (at least) are open, please come and help guide >>>> policies. I'm sure RIPE also wouldn't mind a discussion, if there >>>> could be some positive policy outcome. >> >> Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, >> perhaps ARIN & RIPE representatives could visit anti-spam meetings such as >> MAAWG to ask how they can help? >> >> I'd be happy to make some introductions. >> >> -- >> J.D. Falk >> Return Path Inc >> >> >> >> >> >> > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From frnkblk at iname.com Fri Dec 25 20:38:08 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 25 Dec 2009 14:38:08 -0600 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> Message-ID: Shops where engineering and operations function separately can suffer from reduced efficiencies. A recent example comes to mind. Vendor X was onsite turning up some equipment, including a small VPN concentrator for remote access. It was a new model of VPN concentrator that the installers hadn't worked with before. They used "scripts", a set of a CLI commands with field-replaceable variables for site specific parameters, to configure the device. But connections to the VPN were failing. After trying different versions of the scripts (for similar models) they "broke down" and called their internal tech support department for help. Total turn-up time for the concentrator: 8+ hours. There wasn't that much wrong with the script that kept it from working, but the ops folks lacked the training to understand the problems and fix them. On the other hand, the engineering folks should probably have produced a more robust set of scripts. While having no experience myself, it would seem a good practice that every project, including the actual turn-up, include representation from engineering. This automatically creates a liaison between the two groups and keeps the engineer abreast of "real world" issues. Frank -----Original Message----- From: Michael Dillon [mailto:wavetossed at googlemail.com] Sent: Thursday, December 24, 2009 6:02 PM To: NANOG list Subject: Re: Revisiting the Aviation Safety vs. Networking discussion >> imagine a network engineering culture where the concept of 'attempt to >> deviate' just does not occur. > > Are you trying to suggest that this is something horrible, or that it's the future of network engineering? :) The model of network engineering that grew up during the 1990s is forever gone unless you work in a smaller organization where people have to wear many hats. In the big ISPs, now identical to the big telcos, operations and engineering design duties are separated. The operations folks do not deviate from the written plans that they work with. If the slightest thing happens that is not in the plan, they rollback the changes as specified in the plan. They don't fix anything unless it is officially broken with trouble tickets filed and escalations up to senior management. That is about the only time that operations people can get away with taking shortcuts and creative solutions. On the other hand, the engineering design folks should spend a good part of their day trying out things, thinking up new ideas, poking around equipment and software to see how far it can be pushed. Then, when they have learned something and are ready to implement it in the network, they write a detailed plan for operations. Then some other engineering folks test the heck out of that design to try and find fault with it. After all the faults are fixed, it goes to operations and the engineering design folks move on to something else unless serious problems occur and operations needs a design engineer to approve some sensible action to be taken. The operations folk can't take the sensible action because that would deviate from their plans, but getting engineering design folks involved, gives them an out for real emergencies. So the term "network engineering" is ambiguous because a lot of people use it to mean the 90's style job where engineering design activity and operational activity were all jumbled together. In some companies, taking the engineering design track not only means that you lose enable on the routers, but you lose all TACACS access and have to get authorisation from a VP just to ask for a copy of the running config on a production router. Some people like ops because they see a lot of stuff go by and learn from it, get their CCIE and move into design engineering. Others like ops because they are scared of the responsibility for thinking up what to do next, and making a mistake. As far as I can see, the only way to get a job that mixes ops and design is to be in 3rd or 4th level support which is the top of the technical escalation chain where a few excellent design engineers do have enable on the routers because they fix important problems in near realtime. I suspect that it would be advantageous to have a career in which you worked for a while in ops before moving into design engineering if you want to get into top-level support. Take all this with a grain of salt. Every company does things a bit different, and the terminology that is used is ambiguous. It would be interesting to see what others have to say about this answer. --Michael Dillon From jared at puck.nether.net Fri Dec 25 20:43:23 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 25 Dec 2009 15:43:23 -0500 Subject: BCPs, Exercising emergency process et al In-Reply-To: References: Message-ID: <0E0B49D1-A623-40CC-B65E-DBD90F37D9EF@puck.nether.net> On Dec 25, 2009, at 5:44 AM, Vadim Antonov wrote: > The pre-planned emergency checklists may be a good idea for network > operators. Try obvious (when you're calm, that's it) actions first, if > they fail to help, try to limit damage. Only then go file the ticket and > talk to people who can investigate situation in depth and can develop a > fix. This is why the US Government runs various events to test their procedures and process, and invites the private sector to participate. Cyberstorm III planning is underway. If you want to participate, let me know, I'll connect you with the right groups. ISP participation would be incredibly valuable, it's not always been there to the point where someone plays the role of the whole Internet. There are other events, Topoff, NLE, etc that are run at state or regional levels. As much as everyone here derides the US Gov't, the new cybersecurity wonk, etc.. I would love to see more people engaged in these activities than implying some disconnected group is running things. They WANT industry to participate, but getting the actual neteng types involved is something they don't know how to reach out to properly. Lets bridge this gap. I personally see a LOT of networking and computing failures from lack of employing a BCP in operations. These events are a chance to test your process and procedures, and quite possibly improve them. - Jared From cidr-report at potaroo.net Fri Dec 25 22:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Dec 2009 22:00:03 GMT Subject: BGP Update Report Message-ID: <200912252200.nBPM03pA021510@wattle.apnic.net> BGP Update Report Interval: 17-Dec-09 -to- 24-Dec-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9842 49612 3.7% 3100.8 -- LDCC-AS Lotte Data Communication Company 2 - AS6389 17210 1.3% 4.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS6471 16504 1.2% 40.7 -- ENTEL CHILE S.A. 4 - AS28477 12984 1.0% 1442.7 -- Universidad Autonoma del Esstado de Morelos 5 - AS9829 11259 0.8% 13.1 -- BSNL-NIB National Internet Backbone 6 - AS6822 10499 0.8% 338.7 -- SUPERONLINE-AS SuperOnline autonomous system 7 - AS4270 9785 0.7% 1957.0 -- Red de Interconexion Universitaria 8 - AS4323 8419 0.6% 1.9 -- TWTC - tw telecom holdings, inc. 9 - AS7738 7913 0.6% 18.3 -- Telecomunicacoes da Bahia S.A. 10 - AS14420 7592 0.6% 16.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 11 - AS17974 7406 0.6% 8.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS8452 7349 0.6% 7.1 -- TEDATA TEDATA 13 - AS8909 6707 0.5% 6707.0 -- AMURSU-AS AMURSU Autonomous System 14 - AS7643 6639 0.5% 7.8 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 15 - AS8151 6323 0.5% 4.0 -- Uninet S.A. de C.V. 16 - AS5800 6284 0.5% 31.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS4249 6148 0.5% 33.2 -- LILLY-AS - Eli Lilly and Company 18 - AS35805 5771 0.4% 11.4 -- UTG-AS United Telecom AS 19 - AS1785 5763 0.4% 3.2 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS2386 5664 0.4% 4.4 -- INS-AS - AT&T Data Communications Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8909 6707 0.5% 6707.0 -- AMURSU-AS AMURSU Autonomous System 2 - AS9842 49612 3.7% 3100.8 -- LDCC-AS Lotte Data Communication Company 3 - AS48754 2365 0.2% 2365.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 4 - AS50091 2173 0.2% 2173.0 -- NEGENET Negenet, N.T.P.SH 5 - AS39384 2036 0.1% 2036.0 -- GUILAN-UNIV-AS University of Guilan AS System 6 - AS4270 9785 0.7% 1957.0 -- Red de Interconexion Universitaria 7 - AS28477 12984 1.0% 1442.7 -- Universidad Autonoma del Esstado de Morelos 8 - AS9320 3081 0.2% 1027.0 -- BREGISTRY-AS-KR Ministry of Court Administration 9 - AS34787 904 0.1% 904.0 -- LYAKH-AS PF "Volodymyr Lyakh" 10 - AS45927 692 0.1% 692.0 -- SCCL-123-IN THE SINGARENI COLLIERIES COMPANY LIMITED 11 - AS50214 655 0.1% 655.0 -- QWARTA Qwarta Ltd 12 - AS14251 1248 0.1% 624.0 -- MLSLI - Multiple Lising Service of Long Island, Inc. 13 - AS27667 553 0.0% 553.0 -- Universidad Autonoma de la Laguna 14 - AS18610 941 0.1% 470.5 -- SEQUO-AS - Sequoia Capital 15 - AS47559 403 0.0% 403.0 -- TSCNET-AS SC Tele Satelyt Company SRL 16 - AS6822 10499 0.8% 338.7 -- SUPERONLINE-AS SuperOnline autonomous system 17 - AS45185 281 0.0% 281.0 -- RHYTHM-INDIA-AS-AP Rhythm & Hues Sudios India Pvt Ltd AS Content for MUM 18 - AS35400 1912 0.1% 273.1 -- MFIST Interregoinal Organization Network Technologies 19 - AS40636 546 0.0% 273.0 -- UNITEDSYSTEMS - United Systems 20 - AS9516 509 0.0% 254.5 -- T2-TRANSIT-AS-AP T2 Networks Pte Ltd. Transit AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/24 12864 0.9% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 170.210.56.0/22 9767 0.7% AS4270 -- Red de Interconexion Universitaria 3 - 62.76.124.0/23 6707 0.5% AS8909 -- AMURSU-AS AMURSU Autonomous System 4 - 89.144.140.0/24 4931 0.3% AS39308 -- ASK-AS Andishe Sabz Khazar Autonomous System AS39384 -- GUILAN-UNIV-AS University of Guilan AS System 5 - 210.93.176.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 6 - 124.243.80.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 7 - 124.243.96.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 8 - 124.243.112.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 9 - 210.93.144.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 10 - 124.243.64.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 11 - 124.243.0.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 12 - 210.93.160.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 13 - 210.93.128.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 14 - 124.243.32.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 15 - 124.243.16.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 16 - 124.243.48.0/20 3908 0.3% AS9842 -- LDCC-AS Lotte Data Communication Company 17 - 202.5.154.0/24 3423 0.2% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 18 - 210.93.149.0/24 2687 0.2% AS9842 -- LDCC-AS Lotte Data Communication Company 19 - 91.212.23.0/24 2365 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 20 - 192.12.120.0/24 2351 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 25 22:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Dec 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200912252200.nBPM007t021502@wattle.apnic.net> This report has been generated at Fri Dec 25 21:11:26 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 18-12-09 312972 192741 19-12-09 312740 193763 20-12-09 312648 193600 21-12-09 313296 193390 22-12-09 313159 193196 23-12-09 313292 193069 24-12-09 313303 193004 25-12-09 313727 193170 AS Summary 33200 Number of ASes in routing system 14139 Number of ASes announcing only one prefix 4369 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92520704 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 25Dec09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 313754 193155 120599 38.4% All ASes AS6389 4187 313 3874 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4369 1952 2417 55.3% TWTC - tw telecom holdings, inc. AS1785 1798 449 1349 75.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1901 585 1316 69.2% KIXS-AS-KR Korea Telecom AS17488 1459 338 1121 76.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1122 71 1051 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1285 373 912 71.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1569 670 899 57.3% Uninet S.A. de C.V. AS10620 1005 168 837 83.3% TV Cable S.A. AS19262 1048 234 814 77.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1039 307 732 70.5% TEDATA TEDATA AS18566 1059 343 716 67.6% COVAD - Covad Communications Co. AS18101 997 301 696 69.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1099 476 623 56.7% ATT-INTERNET3 - AT&T WorldNet Services AS4808 833 230 603 72.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 816 219 597 73.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1206 624 582 48.3% LEVEL3 Level 3 Communications AS4804 633 70 563 88.9% MPX-AS Microplex PTY LTD AS7303 665 103 562 84.5% Telecom Argentina S.A. AS7018 1585 1032 553 34.9% ATT-INTERNET4 - AT&T WorldNet Services AS4134 1014 476 538 53.1% CHINANET-BACKBONE No.31,Jin-rong Street AS17908 765 239 526 68.8% TCISL Tata Communications AS7545 937 433 504 53.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 545 50 495 90.8% VTR BANDA ANCHA S.A. AS11492 1153 660 493 42.8% CABLEONE - CABLE ONE, INC. AS28573 829 347 482 58.1% NET Servicos de Comunicao S.A. AS4780 615 148 467 75.9% SEEDNET Digital United Inc. AS35805 511 44 467 91.4% UTG-AS United Telecom AS AS9443 531 78 453 85.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS9299 663 211 452 68.2% IPG-AS-AP Philippine Long Distance Telephone Company Total 37238 11544 25694 69.0% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 157.234.0.0/16 AS1239 SPRINTLINK - Sprint 157.234.230.0/24 AS1239 SPRINTLINK - Sprint 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 207.174.132.0/23 AS30715 207.174.152.0/22 AS30715 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From avg at kotovnik.com Sat Dec 26 00:17:44 2009 From: avg at kotovnik.com (Vadim Antonov) Date: Fri, 25 Dec 2009 16:17:44 -0800 (PST) Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F711B@RWC-EX1.corp.seven.com> Message-ID: > I can see situations in the future where people's lives could be > dependent on networks working properly, or at least endangered if a > network fails. Actually it's not the future. My father's design bureau was making hardware, since 70s (including network stuff) for running industrial processes of a kind where software crash or a network malfunction was usually associated with casualties. Gas pipelines, power plants, electric grids, stuff like that. That's a completely different class of hardware, more of a kind you'd find in avionics - modules in triplicate, voting, pervasive error correction, etc. Software was also designed differently, with a lot more review processes, and with data structures designed for integrity checking (I still use this trick in my work, which saves me a lot of grief during debugging) and recovery from memory corruption and such. I'd be seriously loath to put any of the current crop of COTS network boxes into a life-critical network. --vadim From sean at donelan.com Sat Dec 26 21:18:20 2009 From: sean at donelan.com (Sean Donelan) Date: Sat, 26 Dec 2009 16:18:20 -0500 (EST) Subject: BCPs, Exercising emergency process et al In-Reply-To: <0E0B49D1-A623-40CC-B65E-DBD90F37D9EF@puck.nether.net> References: <0E0B49D1-A623-40CC-B65E-DBD90F37D9EF@puck.nether.net> Message-ID: On Fri, 25 Dec 2009, Jared Mauch wrote: > Cyberstorm III planning is underway. If you want to participate, let >me know, I'll connect you with the right groups. ISP participation would >be incredibly valuable, it's not always been there to the point where >someone plays the role of the whole Internet. And if you are not currently working at an ISP, DHS and lots of other parts of US Government are trying to hire folks with network and computer security knowledge. http://www.washingtonpost.com/wp-dyn/content/article/2009/12/22/AR2009122203789.html http://www.usajobs.gov/ > As much as everyone here derides the US Gov't, the new cybersecurity >wonk, etc.. I would love to see more people engaged in these activities >than implying some disconnected group is running things. They WANT >industry to participate, but getting the actual neteng types involved is >something they don't know how to reach out to properly. Industry, academics, public, just about anyone willing to participate can do something. There are reasons for the rules, processes and procedures governments need to follow; but a good idea is a good idea. Unfortunately, its sometimes harder to figure out what is a bad idea before it causes trouble; because it looked like a good idea at the time. Or to put it another way, if you don't engage, some decisions eventually still have to get made based on what people who did engage told them. Suggestions on how to do something better help make better decisions. -- on vacation, just speaking for myself. From robert at tellurian.com Sun Dec 27 00:24:02 2009 From: robert at tellurian.com (Robert Boyle) Date: Sat, 26 Dec 2009 19:24:02 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> Message-ID: <1261873668_244853@mail1.tellurian.net> At 02:08 AM 12/25/2009, Scott Howard wrote: >On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote: > > > So you can put a lot of process around changes in advance but there > > isn't quite as much to manage incidents that strike out of the clear > > blue. Too much process at that point could impede progress in clearing > > the issue. Capt. Sullenberger did not need to fill out an incident > > report, bring up a conference bridge, and give a detailed description of > > what was happening with his plane, the status of all subsystems, and his > > proposed plan of action (subject to consensus of those on the conference > > bridge) and get approval for deviation from his initial flight plan > > before he took the required actions to land the plane as best as he > > could under the circumstances. > >"*mayday mayday mayday. **Cactus fifteen thirty nine hit birds, we've lost >thrust (in/on) both engines we're turning back towards LaGuardia*" - Capt. >Sullenberger > >Not exactly "detailed", but he definitely initiated an "incident report" >(the mayday), gave a "description of what was happening with his plane", the >"status of [the relevant] subsystems", and his proposed plan of action - >even in the order you've asked for! > >His actions were then "subject to the consensus of those on the conference >bridge" (ie, ATC) who could have denied his actions if they believed they >would have made the situation worse (ie, if what they were proposing would >have had them on a collision course with another plane). In this case, the >conference bridge gave approval for his course of action ("*ok uh, you need >to return to LaGuardia? turn left heading of uh two two zero.*" - ATC) Once he declared an emergency, he had the right of way over all other traffic. ATC would move anyone in his way out of the way. Under U.S. FAA FAR 91.3, "Responsibility and authority of the pilot in command", the FAA declares:[2] * (a) The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft. * (b) In an in-flight emergency requiring immediate action, the pilot in command may deviate from any rule of this part to the extent required to meet that emergency. * (c) Each pilot in command who deviates from a rule under paragraph (b) of this section shall, upon the request of the Administrator, send a written report of that deviation to the Administrator. Just because we have checklists doesn't mean we can't think on our feet and handle situations not contemplated in checklists, but checklists and procedures exist to ensure we don't forget something we need to remember. They aren't a substitute for creativity and logical thought. They are an aid to it to ensure a minimum of creative thinking is needed to solve problems which shouldn't exist in the first place. -Robert SEL&MEL+I "Well done is better than well said." - Benjamin Franklin From mohacsi at niif.hu Mon Dec 28 13:11:21 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 28 Dec 2009 14:11:21 +0100 (CET) Subject: IPv6 Training In-Reply-To: <4B3276DC.8000602@sunwave.net> References: <4B3276DC.8000602@sunwave.net> Message-ID: Hi, Have a look at www.6deploy.org. There is an online quick intro + all the training modules are available in PDF. And there are number of workshops organised around the world with hands-on trainings. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 23 Dec 2009, Marty Anstey wrote: > Greetings, > > Just wondering if anyone has had any experience with IPv6 training courses. > > A quick search turns up a few results on the subject, but it would be > handy to hear if anyone has any firsthand experiences or recommendations. > We're based in western Canada but don't mind traveling a bit, but > alternatively an online course would be acceptable as well. > > -M > > > > From hiersd at gmail.com Mon Dec 28 15:05:55 2009 From: hiersd at gmail.com (David Hiers) Date: Mon, 28 Dec 2009 07:05:55 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <1261873668_244853@mail1.tellurian.net> References: <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> <1261873668_244853@mail1.tellurian.net> Message-ID: <2873f3700912280705u35144e28uca2df8910249e05b@mail.gmail.com> In general, it seems that a field has to be aware that it can kill (or has killed) an embarrassing number of people before its members accept the need for controls such as processes and checklists. Here's a couple if incidents in which gruesome, public loss of life was necessary to for thought to triumph over ego: Doctors took forever to get over their bad selves and adopt the process of handwashing: http://en.wikipedia.org/wiki/Ignaz_Semmelweis Pilots discover humility and the value of checklists in managing complexity: http://www.atchistory.org/History/checklst.htm Reactor-rats, wing-wipers, barber-surgeons, and rocket-jockeys now recognize that the best and brightest among us, polished with state of the art education and training, ruthlessly drilled in the fundamentals, and armed with the best processes and checklists, are just barely good enough to have even-money odds when dealing with everything the world can throw at them. I suppose that once us packet-pushers kill enough people, the economics of lost market share, falling stock prices, and embarrassed CxOs on CNN will push us in that direction. Until then, however, Anarchy and Heroics (http://www.cert.org/archive/pdf/csi0711.pdf) sing their siren song. David On Sat, Dec 26, 2009 at 4:24 PM, Robert Boyle wrote: > At 02:08 AM 12/25/2009, Scott Howard wrote: >> >> On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote: >> >> > So you can put a lot of process around changes in advance but there >> > isn't quite as much to manage incidents that strike out of the clear >> > blue. ?Too much process at that point could impede progress in clearing >> > the issue. ?Capt. Sullenberger did not need to fill out an incident >> > report, bring up a conference bridge, and give a detailed description of >> > what was happening with his plane, the status of all subsystems, and his >> > proposed plan of action (subject to consensus of those on the conference >> > bridge) and get approval for deviation from his initial flight plan >> > before he took the required actions to land the plane as best as he >> > could under the circumstances. >> >> "*mayday mayday mayday. **Cactus fifteen thirty nine hit birds, we've lost >> thrust (in/on) both engines we're turning back towards LaGuardia*" - Capt. >> Sullenberger >> >> Not exactly "detailed", but he definitely initiated an "incident report" >> (the mayday), gave a "description of what was happening with his plane", >> the >> "status of [the relevant] subsystems", and his proposed plan of action - >> even in the order you've asked for! >> >> His actions were then "subject to the consensus of those on the conference >> bridge" (ie, ATC) who could have denied his actions if they believed they >> would have made the situation worse (ie, if what they were proposing would >> have had them on a collision course with another plane). In this case, the >> conference bridge gave approval for his course of action ("*ok uh, you >> need >> to return to LaGuardia? turn left heading of uh two two zero.*" - ATC) > > Once he declared an emergency, he had the right of way over all other > traffic. ATC would move anyone in his way out of the way. > Under U.S. > FAA FAR 91.3, "Responsibility and > authority of the pilot in command", the FAA declares:[2] > ? * (a) The pilot in command of an aircraft is directly responsible for, and > is the final authority as to, the operation of that aircraft. > ? * (b) In an in-flight emergency requiring immediate action, the pilot in > command may deviate from any rule of this part to the extent required to > meet that emergency. > ? * (c) Each pilot in command who deviates from a rule under paragraph (b) > of this section shall, upon the request of the Administrator, send a written > report of that deviation to the Administrator. > Just because we have checklists doesn't mean we can't think on our feet and > handle situations not contemplated in checklists, but checklists and > procedures exist to ensure we don't forget something we need to remember. > They aren't a substitute for creativity and logical thought. They are an aid > to it to ensure a minimum of creative thinking is needed to solve problems > which shouldn't exist in the first place. > > -Robert > SEL&MEL+I > > > > "Well done is better than well said." - Benjamin Franklin > > > From woody at pch.net Mon Dec 28 17:19:29 2009 From: woody at pch.net (Bill Woodcock) Date: Mon, 28 Dec 2009 09:19:29 -0800 (PST) Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <1261873668_244853@mail1.tellurian.net> References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> <1261873668_244853@mail1.tellurian.net> Message-ID: The connection may not be immediately apparent, but I think Philip Greenspun's article critiquing Malcolm Gladwell's musings on cranial metrics etc. has some bearing: http://philip.greenspun.com/flying/foreign-airline-safety ...or is at least an interesting read. In observing network operations screw-ups, I've seen a lot that were either caused by, or prolonged by, a culture-of-emergency. Young guys drinking way too much coffee, working a service window at two in the morning, believing they've seen something that needs to be fixed, and winging it. In building networks, I've tried very hard to engineer things such that the operating procedure for dealing with an "emergency" is to note its existence and place it in a work queue to be dealt with by people who are on a day shift, have just come in from a full night's sleep, and are working in a team with senior people who can assist with anything tricky, and make sure that junior folks are following proceedures that have been worked out in advance by people who had plenty of time in a lab, and plenty of time to choose the best of many alternative procedures. In my experience, reducing the frequency of emergencies is most beneficial in reducing the frequency of outages. :-) -Bill From michael at rancid.berkeley.edu Mon Dec 28 19:38:37 2009 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 28 Dec 2009 11:38:37 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> Message-ID: <4B39093D.4050006@rancid.berkeley.edu> On 12/25/09 7:57 AM, Anton Kapela wrote: > What I'm getting at is that after following this thread for a while, > I'm not convinced any amount of process-borrowing is going to solve > problems better, faster, or even avoid them in the first place. At > best, our craft is 1/3rd as "old" (if that's somehow I measure of > maturity) as flight and nobody is being sued to settle 200+ accidental > deaths because of our mistakes. So, we're supposed to make the mistakes of aviation, nuclear power, the chemical industry (i.e. Bhopal), oil production & refining, etc., all over again? Checklists and MOPs are but one of the things we ignore from other industries. Some others: o Increasing complexity and tight coupling lead to systemic failures. Simply grafting redundancy onto complex systems can make them less, not more, reliable. Yet this is the trend in networking. "Want bells and whistles, firewalls, load-balancers, rate-limiters in your network? You can have 'em without sacrificing reliability if you just buy two of 'em!" o The gradual acceptance of components or procedures that have adequate reliability for a certain task (say, research) that are not reliable enough for another task (e.g. being a critical part of a 1,000 megawatt nuclear power plant) without understanding the implications. Do we know how our technology is being used and will be used? Will the people adopting IP for everything (the "smart grid," VoIP, life-supporting functions) fail to see these implications just as the people who shoved a fissile core into a pressure vessel did? This last point directly contradicts the theme of your message. The notion that what we do is not (yet) a matter of life-or-death has bitten other industries in the past and it provides a nice illustration of why we should *not* be ignoring their lessons. michael From owen at delong.com Mon Dec 28 20:24:35 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Dec 2009 12:24:35 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <2873f3700912231859t78bc0191g5745d674403dc52@mail.gmail.com> <4BCAACD2-4BC9-4E71-AFD7-A2A52B386633@fasteddy.org> <877585b00912241601i29449b84mc8ea067f2968d16d@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7118@RWC-EX1.corp.seven.com> Message-ID: <92633624-8BB1-42AB-8E3A-C2E8747640E2@delong.com> On Dec 24, 2009, at 11:08 PM, Scott Howard wrote: > On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote: > >> So you can put a lot of process around changes in advance but there >> isn't quite as much to manage incidents that strike out of the clear >> blue. Too much process at that point could impede progress in clearing >> the issue. Capt. Sullenberger did not need to fill out an incident >> report, bring up a conference bridge, and give a detailed description of >> what was happening with his plane, the status of all subsystems, and his >> proposed plan of action (subject to consensus of those on the conference >> bridge) and get approval for deviation from his initial flight plan >> before he took the required actions to land the plane as best as he >> could under the circumstances. > > > > "*mayday mayday mayday. **Cactus fifteen thirty nine hit birds, we've lost > thrust (in/on) both engines we're turning back towards LaGuardia*" - Capt. > Sullenberger > > Not exactly "detailed", but he definitely initiated an "incident report" > (the mayday), gave a "description of what was happening with his plane", the > "status of [the relevant] subsystems", and his proposed plan of action - > even in the order you've asked for! > Exactly. > His actions were then "subject to the consensus of those on the conference > bridge" (ie, ATC) who could have denied his actions if they believed they > would have made the situation worse (ie, if what they were proposing would > have had them on a collision course with another plane). In this case, the > conference bridge gave approval for his course of action ("*ok uh, you need > to return to LaGuardia? turn left heading of uh two two zero.*" - ATC) > Not exactly. If the others on the bridge don't consent, FAR 91.3 gives him full and absolute authority to tell them to screw themselves and do what he feels is best. FAR 91.3 reads: Responsibility and authority of the pilot in command. (a) The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft. (b) In an in-flight emergency requiring immediate action, the pilot in command may deviate from any rule of this part to the extent required to meet that emergency. (c) Each pilot in command who deviates from a rule under paragraph (b) of this section shall, upon the request of the Administrator, send a written report of that deviation to the Administrator. As near as I can tell, that regulation was last modified in 1963. > 5 seconds before they made the above call they were reaching for the QRH > (Quick Reference Handbook), which contains checklists of the steps to take > in such a situation - including what to do in the event of loss of both > engines due to multiple birdstrikes. They had no need to confer with others > as to what actions to take to try and recover from the problem, or what > order to take them in, because that pre-work had already been carried out > when the check-lists were written. > Yep. > Of course, at the end of the day, training, skill and experience played a > very large part in what transpired - but so did the actions of the people on > the "conference bridge" (You can't get much more of a "conference bridge" > than open radio frequencies), and the checklists they have for almost every > conceivable situation. > And in case there are any misconceptions here on the list, I know that in the public eye, there is often a lot of distrust and/or perceived animosity between controllers and pilots. Frankly, this is a misconception for the most part. Sure, there are incidents where pilots and controllers don't get along, each blaming the other. However, by and large, both groups are consummate professionals doing their best to make sure flights end well. In my years as a pilot, I have had more than one occasion to be very thankful for ATC and the services they provide. Generally, they are a very helpful and hardworking group. I respect them greatly and appreciate the tough job they do. Owen (Commercial Pilot, ASEL, Instrument Airplane) From owen at delong.com Mon Dec 28 20:38:28 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Dec 2009 12:38:28 -0800 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> Message-ID: On Dec 25, 2009, at 7:57 AM, Anton Kapela wrote: > On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov wrote: > >> The ISP industry has a long way to go until it reaches the same level of >> sophistication in handling problems as aviation has. > > It seems that there's a logical fallacy floating around somewhere > (networks have parts and are complicated, airplanes and flight involve > lots of parts and are also complicated, therefore aircraft are like > networks). I assert that comparing 'packet switching' to an industry > that has its roots in the late 1800's and had its first "hello world" > moment in 1903 isn't terribly fruitful. > As someone with a fair amount of experience with both, I have to disagree with you. Yes, there are differences, and, yes you have to keep comparisons and the like in perspective, but, there are definitely areas where networking could learn from aviation, and, to some extent, vice versa. > Further, aircraft are the asymptotic limit of 'singly homed transit.' > Because of this, I think one could argue that pilots and ATC must be > held to a different professional standard due to the nature of public > trust at risk. At the other end of our strawman spectrum, we have end > users who must accept the risk that their provider will be unable to > connect them to lolcats.com on occasion, perhaps as often as 0.01% per > year, and most are happy to accept this. Four nines survivability on > flights, clearly, won't work. > Correct... As I stated in my earliest posts on this subject, while there is value to be obtained in looking at how aviation has improved its safety/reliability record over the years, there is also value in recognizing the cost/benefit ratio of some of those improvements. If you draw a graph with one curve arcing from bottom left towards upper right, steepening as it goes to the right, that line can be thought of as the amount of cost of achieving additional reliability. A second curve sloping from top left to bottom right, flattening out as it goes to the right can be thought of as the gains achieved from those additional 9s of reliability. Finally, the point where those two curves intersect is defined by the cost of outages and/or downtime. Interestingly, this same diagram will be familiar to most pilots, but, the two arcs will be induced drag (drag from producing lift) and parasite drag (drag from friction with the air). The point where they meet is called "L/D Max" and is the airspeed at which the given aircraft will achieve it's best glide ratio. > What I'm getting at is that after following this thread for a while, > I'm not convinced any amount of process-borrowing is going to solve > problems better, faster, or even avoid them in the first place. At > best, our craft is 1/3rd as "old" (if that's somehow I measure of > maturity) as flight and nobody is being sued to settle 200+ accidental > deaths because of our mistakes. > There are lessons to be learned that are valuable. Both from things aviation has done well that we could emulate, and, from things aviation has done poorly that we should avoid. There are also additional lessons to be learned about the differences in cost/benefit analysis between the two disciplines. Owen From robert at tellurian.com Mon Dec 28 22:18:14 2009 From: robert at tellurian.com (Robert Boyle) Date: Mon, 28 Dec 2009 17:18:14 -0500 Subject: Revisiting the Aviation Safety vs. Networking discussion In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F711A@RWC-EX1.corp.seven.com> <2e9d8ae50912250757h368630d4qea4c05a780777a46@mail.gmail.com> Message-ID: <1262038923_368858@mail1.tellurian.net> At 03:38 PM 12/28/2009, Owen DeLong wrote: >There are lessons to be learned that are valuable. Both from >things aviation has done well that we could emulate, and, from >things aviation has done poorly that we should avoid. There >are also additional lessons to be learned about the differences >in cost/benefit analysis between the two disciplines. Agreed. "You have to learn from the mistakes of others because you won't live long enough to make them all yourself." -Admiral Rickover -Robert "Well done is better than well said." - Benjamin Franklin From Robert_Carlson at siemon.com Mon Dec 28 23:05:42 2009 From: Robert_Carlson at siemon.com (Robert_Carlson at siemon.com) Date: Mon, 28 Dec 2009 18:05:42 -0500 Subject: Robert Carlson/The Siemon Company is out of the office. Message-ID: I will be out of the office starting 12/28/2009 and will not return until 01/04/2010. I will be traveling in Asia and will be checking my emails frequently, but please be aware of the time difference. From bit.gossip at chello.nl Tue Dec 29 11:02:10 2009 From: bit.gossip at chello.nl (Luca Tosolini) Date: Tue, 29 Dec 2009 12:02:10 +0100 Subject: ip-precedence for management traffic Message-ID: <1262084530.4236.7.camel@localhost> Experts, what is the general opinion of using ipp 7 'network control' for management traffic like: telnet ssh snmp ..... The idea is that ipp 0 1 2 3 4 5 are used for user traffic ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ... this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources..... Thanks, Luca. From rdobbins at arbor.net Tue Dec 29 10:07:40 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 29 Dec 2009 10:07:40 +0000 Subject: ip-precedence for management traffic In-Reply-To: <1262084530.4236.7.camel@localhost> References: <1262084530.4236.7.camel@localhost> Message-ID: <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote: > this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources..... Management-plane traffic should be sent/received via your DCN/OOB network, so that it's not competing with customer traffic nor subject to network partitions or other disruptive events. It should not be co-mingled with traffic on the production network. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From mehmet at akcin.net Tue Dec 29 11:03:17 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 29 Dec 2009 03:03:17 -0800 Subject: ip-precedence for management traffic In-Reply-To: <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> References: <1262084530.4236.7.camel@localhost> <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> Message-ID: <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote: > > On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote: > >> this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources..... > > Management-plane traffic should be sent/received via your DCN/OOB network, so that it's not competing with customer traffic nor subject to network partitions or other disruptive events. It should not be co-mingled with traffic on the production network. Agreed, it's very important to have a management network that is reachable while you are under ddos or some kind of mess you or someone else've created. Often having something like an ADSL like connection will save trips to colo and will give you nice abilities to work on stuff when combined with serial management tools. Mehmet From deric.kwok2000 at gmail.com Tue Dec 29 12:56:09 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 29 Dec 2009 07:56:09 -0500 Subject: why it happens short packet. Which network device is problem? Message-ID: <40d8a95a0912290456i211a9b4tae5fc8ca5658ea6f@mail.gmail.com> Hi all I got the following message. UDP: bad checksum. From 67.204.26.203:1054 to 66.49.0.97:55290 ulen 43 UDP: short packet: From 67.55.92.141:23801 30368/46 to 66.49.0.0:24617 What is this meaning? Which network device is problem? Why it happens in the network? Thank you From hiersd at gmail.com Tue Dec 29 13:02:46 2009 From: hiersd at gmail.com (David Hiers) Date: Tue, 29 Dec 2009 05:02:46 -0800 Subject: why it happens short packet. Which network device is problem? In-Reply-To: <40d8a95a0912290456i211a9b4tae5fc8ca5658ea6f@mail.gmail.com> References: <40d8a95a0912290456i211a9b4tae5fc8ca5658ea6f@mail.gmail.com> Message-ID: <2873f3700912290502j19f78538oeee63273392c7779@mail.gmail.com> Send along a capture when you get the chance. David On Tue, Dec 29, 2009 at 4:56 AM, Deric Kwok wrote: > Hi all > > I got the following message. > > UDP: bad checksum. From 67.204.26.203:1054 to 66.49.0.97:55290 ulen 43 > UDP: short packet: From 67.55.92.141:23801 30368/46 to 66.49.0.0:24617 > > What is this meaning? > > Which network device is problem? > > Why it happens in the network? > > Thank you > > From jarruda-gter at jarruda.com Tue Dec 29 14:09:19 2009 From: jarruda-gter at jarruda.com (Julio Arruda) Date: Tue, 29 Dec 2009 09:09:19 -0500 Subject: ip-precedence for management traffic In-Reply-To: <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> References: <1262084530.4236.7.camel@localhost> <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> Message-ID: <15E64549-871F-4759-92A4-A2B75A570E2B@jarruda.com> One note on this :-).. Some time ago, a friend of mine worked in a carrier that had dialup modems for out-of-band access ('lights-out, end-of-world' recovery) They kept the practice in a new NGN Class4/5 replacement.. Detail, the dial-up line went over the NGN.............. On Dec 29, 2009, at 6:03 AM, Mehmet Akcin wrote: > > On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote: > >> >> On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote: >> >>> this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources..... >> >> Management-plane traffic should be sent/received via your DCN/OOB network, so that it's not competing with customer traffic nor subject to network partitions or other disruptive events. It should not be co-mingled with traffic on the production network. > > Agreed, it's very important to have a management network that is reachable while you are under ddos or some kind of mess you or someone else've created. Often having something like an ADSL like connection will save trips to colo and will give you nice abilities to work on stuff when combined with serial management tools. > > Mehmet From jlewis at lewis.org Tue Dec 29 14:16:12 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 29 Dec 2009 09:16:12 -0500 (EST) Subject: why it happens short packet. Which network device is problem? In-Reply-To: <40d8a95a0912290456i211a9b4tae5fc8ca5658ea6f@mail.gmail.com> References: <40d8a95a0912290456i211a9b4tae5fc8ca5658ea6f@mail.gmail.com> Message-ID: On Tue, 29 Dec 2009, Deric Kwok wrote: > Hi all > > I got the following message. > > UDP: bad checksum. From 67.204.26.203:1054 to 66.49.0.97:55290 ulen 43 > UDP: short packet: From 67.55.92.141:23801 30368/46 to 66.49.0.0:24617 > > What is this meaning? Possibly a switch somewhere between the src and dst systems is doing fast-forward switching, and collisions are causing partial packets to be transmitted? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marcus.sachs at verizon.com Tue Dec 29 14:29:12 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 29 Dec 2009 09:29:12 -0500 Subject: ip-precedence for management traffic In-Reply-To: <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> References: <1262084530.4236.7.camel@localhost><1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> Message-ID: <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean 100% exclusion for all customers, but for the average Joe-customer (residential, business, etc., not the researcher, network operator, or clueful content provider) do they really need to have full access to the Internet mechanisms (routing, naming, numbering, etc.)? We already provide lots of proxy services for end users, so why not finish the job and move all of the management mechanisms out of plain sight? Marc -----Original Message----- From: Mehmet Akcin [mailto:mehmet at akcin.net] Sent: Tuesday, December 29, 2009 6:03 AM To: NANOG list Subject: Re: ip-precedence for management traffic On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote: > > On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote: > >> this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources..... > > Management-plane traffic should be sent/received via your DCN/OOB network, so that it's not competing with customer traffic nor subject to network partitions or other disruptive events. It should not be co-mingled with traffic on the production network. Agreed, it's very important to have a management network that is reachable while you are under ddos or some kind of mess you or someone else've created. Often having something like an ADSL like connection will save trips to colo and will give you nice abilities to work on stuff when combined with serial management tools. Mehmet From smb at cs.columbia.edu Tue Dec 29 15:08:54 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 29 Dec 2009 10:08:54 -0500 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> References: <1262084530.4236.7.camel@localhost><1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote: > Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean 100% exclusion for all customers, but for the average Joe-customer (residential, business, etc., not the researcher, network operator, or clueful content provider) do they really need to have full access to the Internet mechanisms (routing, naming, numbering, etc.)? > > We already provide lots of proxy services for end users, so why not finish the job and move all of the management mechanisms out of plain sight? I hope you're joking. If not, I have two questions: how can this be done, and what will the side-effects be? Take BGP, for example. The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. But a multihomed customer *must* speak it. Perhaps you could assert that their ISPs should announce it -- but why trust random ISPs? Is that ISP 12 hops away from you trustworthy, or a front for the Elbonian Business Network? As for side-effects -- how can you proxy everything? Do you know every application your customers are running? Must someone who invents a new app first develop a proxy and persuade every ISP that it's safe, secure, high-enough performance, and worth their while to run? It's worth remembering that most of the innovative applications have come from folks whom no one had ever heard of. --Steve Bellovin, http://www.cs.columbia.edu/~smb From morrowc.lists at gmail.com Tue Dec 29 15:16:45 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 29 Dec 2009 10:16:45 -0500 Subject: ip-precedence for management traffic In-Reply-To: <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> References: <1262084530.4236.7.camel@localhost> <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> Message-ID: <75cb24520912290716i28df4515o873a5118e2cb08b6@mail.gmail.com> On Tue, Dec 29, 2009 at 10:08 AM, Steven Bellovin wrote: > > On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote: > >> Totally out of the box, but here goes: ?why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? ?I don't mean 100% exclusion for all customers, but for the average Joe-customer (residential, business, etc., not the researcher, network operator, or clueful content provider) do they really need to have full access to the Internet mechanisms (routing, naming, numbering, etc.)? >> >> We already provide lots of proxy services for end users, so why not finish the job and move all of the management mechanisms out of plain sight? > > I hope you're joking. ?If not, I have two questions: how can this be done, and what will the side-effects be? > > Take BGP, for example. ?The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. ?But a multihomed customer *must* speak it. ?Perhaps you could assert that their ISPs should announce it -- but why trust random ISPs? ?Is that ISP 12 hops away from you trustworthy, or a front for the Elbonian Business Network? I was going to mute the thread, but.... So for just routing protocols (assume we've already turned off snmp/ssh/telnet/sftp/tftp/etc 'management traffic' to a device) for BGP one 'easy' solution is to have your router only listen on configured addresses, implement the existing bgp security features (GTSH, filtering, iACLs, etc). Arguably this is doable today, it's not 100% OOB, but you COULD model it a little more closely to the TDM world and steal some bw from each eBGP link for just eBGP (say a frame dlci with CAR, or perhaps a sonet/tdm channel, or an atm PVC with a CAR). Of course, we can't seem to do simple bgp filtering, so... For your IGP things get more 'complex', there is some faith that a link's behaviour and health is judged by what the IGP itself sees on the link. If you remove that link from the IGP's view how can the IGP accurately judge health and add/remove that link from it's database? There was some decent thought put into this proposal in ~2001/2002 ... a lot of the time (then) it was simpler to say: "Why not do something like SS7 for the internet?" (not the best analogy, and I'd rather not fixate on that particular thing anyway) -Chris > > As for side-effects -- how can you proxy everything? ?Do you know every application your customers are running? ?Must someone who invents a new app first develop a proxy and persuade every ISP that it's safe, secure, high-enough performance, and worth their while to run? ?It's worth remembering that most of the innovative applications have come from folks whom no one had ever heard of. > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > From marcus.sachs at verizon.com Tue Dec 29 15:22:29 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 29 Dec 2009 10:22:29 -0500 Subject: ip-precedence for management traffic In-Reply-To: <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> References: <1262084530.4236.7.camel@localhost><1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> Message-ID: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> Nope, not joking. Quite serious about this. Glad we agree about the residential customers. Perhaps that's the first place to start and could generate some interesting lessons. Properly dual-homed customers are what I'd lump into the "clueful" category so they are not the ones I'm talking about. Just the basic customers who have no Earthly idea how all of this magic comes together, and who really don't care or have a need to know. New applications, by the way, should not be a problem if they are allowed to adapt to a new networking model. Innovation flourishes when the status quo changes. (I see that Chris Morrow just posted some supportive comments. Thanks Chris!) Marc -----Original Message----- From: Steven Bellovin [mailto:smb at cs.columbia.edu] Sent: Tuesday, December 29, 2009 10:09 AM To: Sachs, Marcus Hans (Marc) Cc: NANOG list Subject: Re: ip-precedence for management traffic On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote: > Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean 100% exclusion for all customers, but for the average Joe-customer (residential, business, etc., not the researcher, network operator, or clueful content provider) do they really need to have full access to the Internet mechanisms (routing, naming, numbering, etc.)? > > We already provide lots of proxy services for end users, so why not finish the job and move all of the management mechanisms out of plain sight? I hope you're joking. If not, I have two questions: how can this be done, and what will the side-effects be? Take BGP, for example. The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. But a multihomed customer *must* speak it. Perhaps you could assert that their ISPs should announce it -- but why trust random ISPs? Is that ISP 12 hops away from you trustworthy, or a front for the Elbonian Business Network? As for side-effects -- how can you proxy everything? Do you know every application your customers are running? Must someone who invents a new app first develop a proxy and persuade every ISP that it's safe, secure, high-enough performance, and worth their while to run? It's worth remembering that most of the innovative applications have come from folks whom no one had ever heard of. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jgreco at ns.sol.net Tue Dec 29 16:00:57 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 29 Dec 2009 10:00:57 -0600 (CST) Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 10:22:29 AM Message-ID: <200912291600.nBTG0vt8015215@aurora.sol.net> > Nope, not joking. Quite serious about this. > > Glad we agree about the residential customers. Perhaps that's the first place to start and could generate some interesting lessons. > > Properly dual-homed customers are what I'd lump into the "clueful" category so they are not the ones I'm talking about. Just the basic customers who have no Earthly idea how all of this magic comes together, and who really don't care or have a need to know. > > New applications, by the way, should not be a problem if they are allowed to adapt to a new networking model. Innovation flourishes when the status quo changes. > > (I see that Chris Morrow just posted some supportive comments. Thanks Chris!) I'm going to skip the "proxy" angle - already addressed by others - and just think about actual OOB management for a second... There's nothing that requires you to make management of most of these services in-band, or in a manner that's accessible to the average user. On the other hand, IP is a least-common denominator and there is no guarantee that a protocol has been made easy to proxy. I realize that the OP was talking about the "Internet management plane" but the problem may be more general than that. There are all sorts of devices that can be managed out of band but shouldn't be accessible to end users. As an example, I was disappointed to discover that HP's iLO2 lights out management implementation is lacking in a variety of ways; for example, it does not appear to be easy to put all your iLO2 devices behind a web proxy (Squid, etc) on a private network. Having the ability to do that, rather than setting up a VPN gateway, would be nice for allowing strict access controls to the management of those devices. To heap on some more unhappiness, HP apparently didn't actually try their own web management interface with SSL; it's impossible to generate a proper cert without mucking around with turning JavaScript on and off to defeat their poorly-coded input sanity checking... sigh But the point is, on one hand, we already have ways to separate the management of networks from the in-band stuff, and at the same time, IP is such an enabling thing, it's useful for management as well. It's great to be able to use a browser to chat with devices, for example. If we really envision separating management out, do we use the same IP protocol for it, to be able to take advantage of existing tools and technologies like SSL for encryption, etc? If so, I'd note that we largely have the ability to separate management into out-of-band networks today, and have had this for many years. If not, I think the proposal's a non-starter, because then you're talking about significant re-engineering of lots of things. Getting back to the OP's message, I keep having these visions of the castrated "Internet" access some hotels provide. You know the ones. The ones where everything goes through a Web proxy and you're forced to have IE6 as a browser. For some people, who just want to log on to Yahoo or Hotmail or whatever to check their e-mail, that's fine. However, some of us might want to be able to VNC somewhere, or do VoIP, or run a VPN connection... these are all well-known Internet capabilities, and yet some providers of so-called "Internet" access at hotels haven't allowed for them. Do we really want to spread that sort of model to the rest of the Internet? All it really encourages is for more and more things to be ported to HTTP, including, amusingly, management of devices... at which point we have not really solved the problem but we have succeeded at doing damage to the potential of the Internet. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Valdis.Kletnieks at vt.edu Tue Dec 29 16:24:16 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 29 Dec 2009 11:24:16 -0500 Subject: ip-precedence for management traffic In-Reply-To: Your message of "Tue, 29 Dec 2009 10:00:57 CST." <200912291600.nBTG0vt8015215@aurora.sol.net> References: <200912291600.nBTG0vt8015215@aurora.sol.net> Message-ID: <5907.1262103856@localhost> On Tue, 29 Dec 2009 10:00:57 CST, Joe Greco said: > Do we really want to spread that sort of model to the rest of the > Internet? All it really encourages is for more and more things to > be ported to HTTP, including, amusingly, management of devices... I can remember at one time, some of the same players who argued against IPv6 adoption because the long addresses would increase network overhead were the same ones championing the insane firewalling that started the "everything over HTTP" insanity. Guess which adds more bits to the total packet? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marcus.sachs at verizon.com Tue Dec 29 16:43:25 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 29 Dec 2009 11:43:25 -0500 Subject: ip-precedence for management traffic In-Reply-To: <200912291600.nBTG0vt8015215@aurora.sol.net> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 10:22:29 AM <200912291600.nBTG0vt8015215@aurora.sol.net> Message-ID: <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> Joe wrote: >Getting back to the OP's message, I keep having these visions of the >castrated "Internet" access some hotels provide. You know the ones. >The ones where everything goes through a Web proxy and you're forced >to have IE6 as a browser. For some people, who just want to log on >to Yahoo or Hotmail or whatever to check their e-mail, that's fine. >However, some of us might want to be able to VNC somewhere, or do >VoIP, or run a VPN connection... these are all well-known Internet >capabilities, and yet some providers of so-called "Internet" access >at hotels haven't allowed for them. > >Do we really want to spread that sort of model to the rest of the >Internet? All it really encourages is for more and more things to >be ported to HTTP, including, amusingly, management of devices... >at which point we have not really solved the problem but we have >succeeded at doing damage to the potential of the Internet. Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos-blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers. Marc From Valdis.Kletnieks at vt.edu Tue Dec 29 17:07:24 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 29 Dec 2009 12:07:24 -0500 Subject: ip-precedence for management traffic In-Reply-To: Your message of "Tue, 29 Dec 2009 11:43:25 EST." <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> "2009 10:22:29 AM" <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <7183.1262106444@localhost> On Tue, 29 Dec 2009 11:43:25 EST, "Sachs, Marcus Hans (Marc)" said: > one-size-fits-all model like the hotels try to do. Imagine a > residential ISP that offers castration at a lower price point than what > is currently charged for monthly "raw" access. The gene pool needed some chlorine anyhow, but this is a creative approach. :) But seriously - would this be significantly different than the model that many ISPs already use, where "consumer" connections get port 25 blocked, no servers allowed, etc, and "business grade" skip those restrictions? Or are you saying that ISPs should go *further* in blocking stuff, and use the resulting support savings to lower the consumer grade price point? Only big stumbling block is what percent of customers will be willing to skip file-sharing networks and online games that use oddball ports? Any ideas there? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jgreco at ns.sol.net Tue Dec 29 17:15:38 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 29 Dec 2009 11:15:38 -0600 (CST) Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 11:43:25 AM Message-ID: <200912291715.nBTHFcAO018752@aurora.sol.net> > Joe wrote: > >Getting back to the OP's message, I keep having these visions of the > >castrated "Internet" access some hotels provide. You know the ones. > >The ones where everything goes through a Web proxy and you're forced > >to have IE6 as a browser. For some people, who just want to log on > >to Yahoo or Hotmail or whatever to check their e-mail, that's fine. > >However, some of us might want to be able to VNC somewhere, or do > >VoIP, or run a VPN connection... these are all well-known Internet > >capabilities, and yet some providers of so-called "Internet" access > >at hotels haven't allowed for them. > > > >Do we really want to spread that sort of model to the rest of the > >Internet? All it really encourages is for more and more things to > >be ported to HTTP, including, amusingly, management of devices... > >at which point we have not really solved the problem but we have > >succeeded at doing damage to the potential of the Internet. > > > Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos-blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers. Then, by all means, approach your management and make a proposal to sell reduced fee "Web only" access. You can already force all such traffic through a transparent HTTP proxy, a DNS server of your choosing, and filter out everything else. I am still failing to see why what you're talking about cannot be done with today's technology. And if it can be done with today's technology, and isn't being done with it, either that's a business opportunity for you, or it says something about the model. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From trejrco at gmail.com Tue Dec 29 17:18:24 2009 From: trejrco at gmail.com (TJ) Date: Tue, 29 Dec 2009 12:18:24 -0500 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 10:22:29 AM <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <00a001ca88aa$f05dfdf0$d119f9d0$@com> > -----Original Message----- > From: Sachs, Marcus Hans (Marc) [mailto:marcus.sachs at verizon.com] > Sent: Tuesday, December 29, 2009 11:43 > To: Joe Greco > Cc: NANOG list > Subject: RE: ip-precedence for management traffic > > Joe wrote: > > >Getting back to the OP's message, I keep having these visions of the > >castrated "Internet" access some hotels provide. You know the ones. > >The ones where everything goes through a Web proxy and you're forced > >to have IE6 as a browser. For some people, who just want to log on > >to Yahoo or Hotmail or whatever to check their e-mail, that's fine. > >However, some of us might want to be able to VNC somewhere, or do > >VoIP, or run a VPN connection... these are all well-known Internet > >capabilities, and yet some providers of so-called "Internet" access > >at hotels haven't allowed for them. > > > >Do we really want to spread that sort of model to the rest of the > >Internet? All it really encourages is for more and more things to > >be ported to HTTP, including, amusingly, management of devices... > >at which point we have not really solved the problem but we have > >succeeded at doing damage to the potential of the Internet. > > > Yes, taking away the mechanisms will result in a "castrated" Internet > experience for the clueful ones which is why I don't think this can be a one- > size-fits-all model like the hotels try to do. Imagine a residential ISP that > offers castration at a lower price point than what is currently charged for > monthly "raw" access. I think that many consumers would opt for that choice, > while those who need access to everything would continue to pay the same rate. > The price drop would be the incentive to get castrated, and what you give up > would be access to things you likely don't use anyway. This castration > process would be a big help to spam-blocking, evilware-blocking, ddos- > blocking, etc. in addition to mitigating attacks against the mechanisms from > hijacked residential computers. > > > Marc My $.02 or so - This "widespread castration" would force application developers to jump through the same NAT-traversal hoops all over again, adding more code-bloat / operational overhead and stifling innovation. Naturally, once created, this lower-class of internet user would probably become the "norm" and force a race to the bottom in terms of capabilities and performance (or perhaps, another "arms race" between the proxy implementations and the proxy avoidance implementations) ... rinse-repeat-fail_to_learn, all over again. /TJ PS - could we choose a different term; "cut-rate castration" brings unpleasant medical-accidents to mind ... From jared at puck.nether.net Tue Dec 29 17:19:32 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Dec 2009 12:19:32 -0500 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 10:22:29 AM <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <08EF11E7-090F-494B-8083-52D30D8DD9E5@puck.nether.net> On Dec 29, 2009, at 11:43 AM, Sachs, Marcus Hans (Marc) wrote: > Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos-blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers. I think there are a few challenges here. What you are describing is a castrated/walled-garden internet. The technical nuances are lost on the average person. The same way that cybersecurity month, or others are lost on the average user. All they care about is the recent panic for the day. I find it impossible to deal with some vendors that are stuck with their lock-in models. The way that the majority of $major_networks is managed is in a method that is not always congruent with their visions. This is true from their ideas on how to manage devices (Hey, everyone sits at a corp controlled windows machine behind a firewall so you can keep the *exact* version of java installed, right?) How does one reach the OOB network when you are not in the office? How do these "SCADA" for the "internet" networks get reached? Some people have implemented DSL or other vpn methods to reach their oob devices. Others use POTS. As others mentioned here the POTS over "NGN" (what marketing crap is that) may have fate sharing properties that are problematic. What if the vendor is horrible and you actually "need" console/video to run their win32 crapware to manage the devices? (Netgear comes to mind, can't upgrade my snmp capable switch at home without booting windoze so it can tftp). The inband management is a direct result of needing a good method to tie the link failure directly into the control plane of the devices. Sure, we could do the DLCI/pvc/DS1 in parallel to each 10G/40G circuit installed, but is that cost-effective? Does it introduce more pain vs less? The average neteng clearly can't configure their devices correctly, while the additional complexity may provide some networks benefits, this does not reduce the systemic risk created by nobody implementing BCPs like simple route filtering. I've watched BCPs be diluted at various companies due to market pressures. $major_provider did not require me to register my routes, why should I have to do that in order to give you $X MRC for the next 12-24-36 months? I was asked recently by someone that operates a small wireless ISP what the deal was with this "Internet2" thing and how was it supposed to interact, etc.. Honestly, I wish we could have a "better" network. One where we have mutually agreed "I will filter my customers if you do". I've not seen many people step-up to improve the systems. It's the same small set of people that are trying to make things better. Apparently I forgot the tag, but really, if you have sane CoPP policies, you are mostly protected. If the vendor does not provide this capability, please STOP BUYING THEIR CRAP. - Jared From marcus.sachs at verizon.com Tue Dec 29 17:20:01 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 29 Dec 2009 12:20:01 -0500 Subject: ip-precedence for management traffic In-Reply-To: <7183.1262106444@localhost> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> "2009 10:22:29 AM" <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> Message-ID: <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> Valdis said: >The gene pool needed some chlorine anyhow, but this is a creative approach. :) > >But seriously - would this be significantly different than the model that >many ISPs already use, where "consumer" connections get port 25 blocked, no >servers allowed, etc, and "business grade" skip those restrictions? Or are >you saying that ISPs should go *further* in blocking stuff, and use the >resulting support savings to lower the consumer grade price point? > >Only big stumbling block is what percent of customers will be willing to >skip file-sharing networks and online games that use oddball ports? Any >ideas there? Better than the typical "block outbound 25" filtering we do now. In fact, in a perfect world ISPs would offer residential customers "reduced experience" versions of castration that decrease the cost along with decreasing what you have access to. At the bottom level it would be essentially a thin client running a terminal service (or an emulated thin client using a web browser) with all applications "in the cloud" and nothing sitting on the home PC; mid-level would be web plus common email clients and chat/IM; high level adds popular apps like Skype, P2P, games, etc. I think that a fairly large percentage of homes that only want access to online content and email would be very happy with the bottom tiers. Many would probably like the cloud approach where all of the crazy updating, rebooting, etc. is taken out of the hands of the consumer. WebTV, meet the 21st century.... :) Marc From marcus.sachs at verizon.com Tue Dec 29 17:21:34 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 29 Dec 2009 12:21:34 -0500 Subject: ip-precedence for management traffic In-Reply-To: <200912291715.nBTHFcAO018752@aurora.sol.net> References: <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 11:43:25 AM <200912291715.nBTHFcAO018752@aurora.sol.net> Message-ID: <81D582C724CA1046A279A7EE1299638B02AC1AB1@FHDP1LUMXCV24.us.one.verizon.com> Joe wrote: >I am still failing to see why what you're talking about cannot be done >with today's technology. > >And if it can be done with today's technology, and isn't being done with >it, either that's a business opportunity for you, or it says something >about the model. The later. It can be done today. So why is it not being offered? There must be other forces at work. Marc From tomb at byrneit.net Tue Dec 29 17:29:24 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 29 Dec 2009 09:29:24 -0800 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> References: <1262084530.4236.7.camel@localhost><1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net><4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net><81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com><74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <72F9A69DCF990443B2CEC064E605CE0625E0@Pascal.zaphodb.org> I actually proposed this (bounced it off Paul Mockapetris and Dave Roberts at the time), and we did it for our internal routing in the co-lo/hosted apps, when I was CTO at American Digital Network (1996-1998). Basically, SNMP and our IGPs as well as IBGP rode a totally private RFC 1918 network that had higher priority at layer 2 if it was on the same physical (always a different VC) circuit. For Ethernet, we used a separate layer 2 network for this internally. If we exposed any IGPs to clients, it was on a per link basis. We also had a hosted firewall service that was provisioned on a per-Radius profile for ISDN clients where the "routing" was handled by some layer 2 tricks in ATM before the arrival of MPLS. We were working on some tests with peers and subscribers when the FirstWorld merger came along, and the rest is history. To answer Steve's questions: 1: Where you can have a different circuit (physical or virtual ) for the mgt/routing traffic, you provision the traffic ONLY on those links (and filter it on all others), and only to peers who speak that particular protocol. Give those VCs highest priority. 2: Where 1 is not possible, use a local-only network, preferably IPV6, for the mgt/routing, and set priority to highest for that source/dest net. This could be provisioned even for those end users who DO need to sprecken BGP, and who do not have separate (virtual) circuits for management. > -----Original Message----- > From: Sachs, Marcus Hans (Marc) [mailto:marcus.sachs at verizon.com] > Sent: Tuesday, December 29, 2009 7:22 AM > To: Steven Bellovin > Cc: NANOG list > Subject: RE: ip-precedence for management traffic > > Nope, not joking. Quite serious about this. > > Glad we agree about the residential customers. Perhaps that's the > first place to start and could generate some interesting lessons. > > Properly dual-homed customers are what I'd lump into the "clueful" > category so they are not the ones I'm talking about. Just the basic > customers who have no Earthly idea how all of this magic comes > together, and who really don't care or have a need to know. > > New applications, by the way, should not be a problem if they are > allowed to adapt to a new networking model. Innovation flourishes when > the status quo changes. > > (I see that Chris Morrow just posted some supportive comments. Thanks > Chris!) > > Marc > > > -----Original Message----- > From: Steven Bellovin [mailto:smb at cs.columbia.edu] > Sent: Tuesday, December 29, 2009 10:09 AM > To: Sachs, Marcus Hans (Marc) > Cc: NANOG list > Subject: Re: ip-precedence for management traffic > > > On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote: > > > Totally out of the box, but here goes: why don't we run the entire > Internet management plane "out of band" so that customers have minimal > ability to interact with routing updates, layer 3/4 protocols, DNS, > etc.? I don't mean 100% exclusion for all customers, but for the > average Joe-customer (residential, business, etc., not the researcher, > network operator, or clueful content provider) do they really need to > have full access to the Internet mechanisms (routing, naming, > numbering, etc.)? > > > > We already provide lots of proxy services for end users, so why not > finish the job and move all of the management mechanisms out of plain > sight? > > I hope you're joking. If not, I have two questions: how can this be > done, and what will the side-effects be? > > Take BGP, for example. The average residential consumer doesn't need > BGP, doesn't speak it, and has no real ability to interfere with it, so > there's no problem. But a multihomed customer *must* speak it. > Perhaps you could assert that their ISPs should announce it -- but why > trust random ISPs? Is that ISP 12 hops away from you trustworthy, or a > front for the Elbonian Business Network? > > As for side-effects -- how can you proxy everything? Do you know every > application your customers are running? Must someone who invents a new > app first develop a proxy and persuade every ISP that it's safe, > secure, high-enough performance, and worth their while to run? It's > worth remembering that most of the innovative applications have come > from folks whom no one had ever heard of. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > From bit.gossip at chello.nl Tue Dec 29 18:37:56 2009 From: bit.gossip at chello.nl (Luca Tosolini) Date: Tue, 29 Dec 2009 19:37:56 +0100 Subject: ip-precedence for management traffic In-Reply-To: <1262084530.4236.7.camel@localhost> References: <1262084530.4236.7.camel@localhost> Message-ID: <1262111876.1752.26.camel@localhost> Experts, my inquiry was very specific and bounded to the following assumptions: - in-band management - not possible to filter customer traffic, certainly not for somebody else's customer. - IP In this case diffserv can help prioritize management plane traffic over user traffic. To do that only ipp6 and ipp7 values are available for non user traffic. IPP6 is used by default for routing protocols, that is control plane; so probably it is better not to mess around with it. This leaves to IPP7 for management plane traffic, value that I can not recall of having seen used by any application/protocol. What is the general opinion about this? Thanks. On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote: > Experts, > what is the general opinion of using ipp 7 'network control' for > management traffic like: telnet ssh snmp ..... > > The idea is that ipp 0 1 2 3 4 5 are used for user traffic > ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ... > > this leaves out only ipp 7 for management traffic, on the premise that > routing and management should not share the same queue and > resources..... > > Thanks, > Luca. > > From dwhite at olp.net Tue Dec 29 17:59:42 2009 From: dwhite at olp.net (Dan White) Date: Tue, 29 Dec 2009 11:59:42 -0600 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <20091229175941.GA21354@dan.olp.net> On 29/12/09?12:20?-0500, Sachs, Marcus Hans (Marc) wrote: >Better than the typical "block outbound 25" filtering we do now. In >fact, in a perfect world ISPs would offer residential customers "reduced >experience" versions of castration that decrease the cost along with >decreasing what you have access to. At the bottom level it would be >essentially a thin client running a terminal service (or an emulated >thin client using a web browser) with all applications "in the cloud" >and nothing sitting on the home PC; mid-level would be web plus common >email clients and chat/IM; high level adds popular apps like Skype, P2P, >games, etc. > >I think that a fairly large percentage of homes that only want access to >online content and email would be very happy with the bottom tiers. >Many would probably like the cloud approach where all of the crazy >updating, rebooting, etc. is taken out of the hands of the consumer. >WebTV, meet the 21st century.... :) The customers in the market for such a service would be least likely to understand your explanation of the service. Do you offer a new lower tier service, or rebrand your residential service, and try to explain how you're taking away services they probably don't need. It's been my experience that if you tell someone you're taking away something, they tend to value it even if they don't know what it is. -- Dan White From marcus.sachs at verizon.com Tue Dec 29 18:17:20 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 29 Dec 2009 13:17:20 -0500 Subject: ip-precedence for management traffic In-Reply-To: <1262111876.1752.26.camel@localhost> References: <1262084530.4236.7.camel@localhost> <1262111876.1752.26.camel@localhost> Message-ID: <81D582C724CA1046A279A7EE1299638B02AC1AF0@FHDP1LUMXCV24.us.one.verizon.com> Sorry, your original query got lost behind the smoke of my out-of-the-box musings. My biggest quarrel with any type of IP precedence is that anybody along the chain can set or reset these bits. There is no assurance that a packet's priority will remain at the level set by the originator unless you have some very well disciplined netadmins between sender and receiver who do not fiddle with header bits. If I knew that I could reliably set ToS bits in the IP header and they would remain unchanged then I would add a shim to my local stack that sets all of my flows at the highest priority thereby making my Internet experience a wee bit faster than somebody who leaves those three bits set to 000. I'm sure others will have widely different opinions. Marc -----Original Message----- From: Luca Tosolini [mailto:bit.gossip at chello.nl] Sent: Tuesday, December 29, 2009 1:38 PM To: nanog Subject: Re: ip-precedence for management traffic Experts, my inquiry was very specific and bounded to the following assumptions: - in-band management - not possible to filter customer traffic, certainly not for somebody else's customer. - IP In this case diffserv can help prioritize management plane traffic over user traffic. To do that only ipp6 and ipp7 values are available for non user traffic. IPP6 is used by default for routing protocols, that is control plane; so probably it is better not to mess around with it. This leaves to IPP7 for management plane traffic, value that I can not recall of having seen used by any application/protocol. What is the general opinion about this? Thanks. On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote: > Experts, > what is the general opinion of using ipp 7 'network control' for > management traffic like: telnet ssh snmp ..... > > The idea is that ipp 0 1 2 3 4 5 are used for user traffic > ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ... > > this leaves out only ipp 7 for management traffic, on the premise that > routing and management should not share the same queue and > resources..... > > Thanks, > Luca. > > From dhetzel at gmail.com Tue Dec 29 18:25:54 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Tue, 29 Dec 2009 13:25:54 -0500 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1AF0@FHDP1LUMXCV24.us.one.verizon.com> References: <1262084530.4236.7.camel@localhost> <1262111876.1752.26.camel@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AF0@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <7db2dcf90912291025tf40cdbdi9ac6822e3385db90@mail.gmail.com> Marc, I don't think that's entirely true. I have in previously run networks that remarked all precedence on inbound traffic at the borders to particular values (mostly zero except where policy dictated other) and then accepted the precedence values internally for priority control. Customers were allowed to send contracted amounts of higher precedence traffic, but anything over was marked down (or dropped). So most traffic got best effort, but marked traffic got a relatively guaranteed QOS. This was quite some time ago (2000-2001), so I'm thinking it ought to still be doable today. You have to be diligent in remarking inbound traffic at all boundaries, but it's not rocket science. Regards, -Dorn On Tue, Dec 29, 2009 at 1:17 PM, Sachs, Marcus Hans (Marc) < marcus.sachs at verizon.com> wrote: > Sorry, your original query got lost behind the smoke of my out-of-the-box > musings. > > My biggest quarrel with any type of IP precedence is that anybody along the > chain can set or reset these bits. There is no assurance that a packet's > priority will remain at the level set by the originator unless you have some > very well disciplined netadmins between sender and receiver who do not > fiddle with header bits. If I knew that I could reliably set ToS bits in > the IP header and they would remain unchanged then I would add a shim to my > local stack that sets all of my flows at the highest priority thereby making > my Internet experience a wee bit faster than somebody who leaves those three > bits set to 000. > > I'm sure others will have widely different opinions. > > Marc > > -----Original Message----- > From: Luca Tosolini [mailto:bit.gossip at chello.nl] > Sent: Tuesday, December 29, 2009 1:38 PM > To: nanog > Subject: Re: ip-precedence for management traffic > > Experts, > my inquiry was very specific and bounded to the following assumptions: > - in-band management > - not possible to filter customer traffic, certainly not for somebody > else's customer. > - IP > > In this case diffserv can help prioritize management plane traffic over > user traffic. To do that only ipp6 and ipp7 values are available for non > user traffic. > IPP6 is used by default for routing protocols, that is control plane; so > probably it is better not to mess around with it. > This leaves to IPP7 for management plane traffic, value that I can not > recall of having seen used by any application/protocol. > > What is the general opinion about this? > > Thanks. > > > On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote: > > Experts, > > what is the general opinion of using ipp 7 'network control' for > > management traffic like: telnet ssh snmp ..... > > > > The idea is that ipp 0 1 2 3 4 5 are used for user traffic > > ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ... > > > > this leaves out only ipp 7 for management traffic, on the premise that > > routing and management should not share the same queue and > > resources..... > > > > Thanks, > > Luca. > > > > > > > > From drc at virtualized.org Tue Dec 29 19:00:56 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 29 Dec 2009 11:00:56 -0800 Subject: ip-precedence for management traffic In-Reply-To: <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> References: <1262084530.4236.7.camel@localhost><1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> <74DF6987-7398-4CAF-AF05-9942677F00A6@cs.columbia.edu> Message-ID: <34E5CCFF-1A07-4D04-A67D-62667BAC4F8D@virtualized.org> On Dec 29, 2009, at 7:08 AM, Steven Bellovin wrote: > On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote: >> Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? > I hope you're joking. If not, I have two questions: how can this be done, and what will the side-effects be? Actually... Some of the models proposed in the IRTF Routing Research Group separate the "access network" from the "transport network". That is, end devices would be numbered from a different "namespace" than the nodes in the transport network. This would allow for the separation of identity from network topology allowing much greater scalability of the routing system (at the cost of requiring a mapping system that maps end point identifiers to/from network topology locators). Think of it as an automated ubiquitous end-to-end tunneling system that tunnels traffic to/from identifiers. A side effect of this approach would be along the lines what Marc is suggesting. > Take BGP, for example. The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. But a multihomed customer *must* speak it. Multihoming in the above model would simply mean the output of the mapping service of an identifier would result in two (or more) locators. Changing ISPs means simply changing the identifier to locator mapping. Ah, the joys of indirection... Of course, I'm a bit doubtful any of the models discussed in RRG or even LISP will gain much traction. > As for side-effects -- how can you proxy everything? Do you know every application your customers are running? Must someone who invents a new app first develop a proxy and persuade every ISP that it's safe, secure, high-enough performance, and worth their while to run? It's worth remembering that most of the innovative applications have come from folks whom no one had ever heard of. I dunno. Seems the vast majority of Internet users are happy with this model, given they are sitting behind a NAT box.... Regards, -drc From tvest at eyeconomics.com Tue Dec 29 19:19:24 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 29 Dec 2009 14:19:24 -0500 Subject: ip-precedence for management traffic In-Reply-To: <20091229175941.GA21354@dan.olp.net> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> <20091229175941.GA21354@dan.olp.net> Message-ID: <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> On Dec 29, 2009, at 12:59 PM, Dan White wrote: > On 29/12/09 12:20 -0500, Sachs, Marcus Hans (Marc) wrote: >> Better than the typical "block outbound 25" filtering we do now. In >> fact, in a perfect world ISPs would offer residential customers >> "reduced >> experience" versions of castration that decrease the cost along with >> decreasing what you have access to. At the bottom level it would be >> essentially a thin client running a terminal service (or an emulated >> thin client using a web browser) with all applications "in the cloud" >> and nothing sitting on the home PC; mid-level would be web plus >> common >> email clients and chat/IM; high level adds popular apps like Skype, >> P2P, >> games, etc. >> >> I think that a fairly large percentage of homes that only want >> access to >> online content and email would be very happy with the bottom tiers. >> Many would probably like the cloud approach where all of the crazy >> updating, rebooting, etc. is taken out of the hands of the consumer. >> WebTV, meet the 21st century.... :) > > The customers in the market for such a service would be least likely > to > understand your explanation of the service. > > Do you offer a new lower tier service, or rebrand your residential > service, and try to explain how you're taking away services they > probably > don't need. It's been my experience that if you tell someone you're > taking > away something, they tend to value it even if they don't know what > it is. As well they should. As well we all should. None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated. TV From jgreco at ns.sol.net Tue Dec 29 20:56:53 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 29 Dec 2009 14:56:53 -0600 (CST) Subject: ip-precedence for management traffic In-Reply-To: <00a001ca88aa$f05dfdf0$d119f9d0$@com> from "TJ" at Dec 29, 2009 12:18:24 PM Message-ID: <200912292056.nBTKur5Z029049@aurora.sol.net> > My $.02 or so - This "widespread castration" would force application > developers to jump through the same NAT-traversal hoops all over again, > adding more code-bloat / operational overhead and stifling innovation. > Naturally, once created, this lower-class of internet user would probably > become the "norm" and force a race to the bottom in terms of capabilities > and performance (or perhaps, another "arms race" between the proxy > implementations and the proxy avoidance implementations) ... > rinse-repeat-fail_to_learn, all over again. That was kind of my point. > /TJ > PS - could we choose a different term; "cut-rate castration" brings > unpleasant medical-accidents to mind ... How about "net neuterality." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Tue Dec 29 21:10:07 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 29 Dec 2009 15:10:07 -0600 (CST) Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1AB1@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 12:21:34 PM Message-ID: <200912292110.nBTLA7RX029489@aurora.sol.net> > Joe wrote: > > >I am still failing to see why what you're talking about cannot be done > >with today's technology. > > > >And if it can be done with today's technology, and isn't being done with > >it, either that's a business opportunity for you, or it says something > >about the model. > > The later. It can be done today. So why is it not being offered? > There must be other forces at work. It is (/was). You had things like WebTV. Spectacularly unsuccessful as time went on. The problem is that the Internet is very powerful and very big. Offer people a basic box that does basic things, and one person will want to (also) pull up a PDF, another will (also) want to be able to install a more modern version of Flash to support the latest video capabilities being offered by $YOUTUBE_LIKE_SITE, a third will (also) want Java support in order to play some trite online game, etc. Offer people a basic Web-only Internet connection, and they'll want to know why their gaming console doesn't work, etc. Fundamentally, we have worked very hard for a very long time to create a sort of baseline level of what is expected as part of "Internet" connectivity. That's a basic IP connection. We've created standards on top of that to allow applications to interoperate. It is hard to dip down below that bar in terms of functionality. Anyone who tries is going to end up eating support costs. How do you offer a "cheaper" level of (let's say) Web-only Internet access, when the support costs will be higher? Where's the value? What's the business plan? Where's the profit in that? I really meant what I said: [I]f it can be done with today's technology, and isn't being done with it, either that's a business opportunity for you, or it says something about the model. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nick at foobar.org Tue Dec 29 21:25:06 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 29 Dec 2009 21:25:06 +0000 Subject: ip-precedence for management traffic In-Reply-To: <200912292110.nBTLA7RX029489@aurora.sol.net> References: <200912292110.nBTLA7RX029489@aurora.sol.net> Message-ID: <4B3A73B2.1050308@foobar.org> On 29/12/2009 21:10, Joe Greco wrote: > How do you offer a "cheaper" level of > (let's say) Web-only Internet access, when the support costs will be > higher? Where's the value? What's the business plan? Where's the profit > in that? As an unrelated footnote, these are questions which will become highly relevant when RIR address space depletion occurs and when providers initially believe that they can create viable product sets based on provider NAT, once their v4 address space can no longer service their customer base. [As a further sub-note, the "believe" bit is not a statement of scepticism, but rather a statement of fact; many providers will almost certainly believe that end-users will swallow provider NAT, regardless of whether the product models turn out to be viable or not.] So, although it's a different context, I think you'll see the answer to these questions in this context in the next couple of years. Nick From randy at psg.com Tue Dec 29 22:19:42 2009 From: randy at psg.com (Randy Bush) Date: Wed, 30 Dec 2009 07:19:42 +0900 Subject: ip-precedence for management traffic In-Reply-To: <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> References: <1262084530.4236.7.camel@localhost> <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: > Totally out of the box, but here goes: why don't we run the entire > Internet management plane "out of band" tread caefully. we have experienced (and some continue to experience) non-linear expansion of management, control, and stability problems when layers are non-congruent. randy From randy at psg.com Tue Dec 29 22:22:05 2009 From: randy at psg.com (Randy Bush) Date: Wed, 30 Dec 2009 07:22:05 +0900 Subject: ip-precedence for management traffic In-Reply-To: <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> <20091229175941.GA21354@dan.olp.net> <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> Message-ID: > None of us knows precisely what we're going to absolutely require, or > merely want/prefer, tomorrow or the next day, much less a year or two > from now. Unless, of course, we choose to optimize (constrain) > functionality so tightly around what we want/need today that the > prospect of getting anything different is effectively eliminated. this is the telco solution to the nasty disruptive technologies spawned by the internet randy From morrowc.lists at gmail.com Tue Dec 29 22:29:50 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 29 Dec 2009 17:29:50 -0500 Subject: ip-precedence for management traffic In-Reply-To: References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> <20091229175941.GA21354@dan.olp.net> <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> Message-ID: <75cb24520912291429v5008180bx65b45d13e275b397@mail.gmail.com> On Tue, Dec 29, 2009 at 5:22 PM, Randy Bush wrote: >> None of us knows precisely what we're going to absolutely require, or >> merely want/prefer, tomorrow or the next day, much less a year or two >> from now. Unless, of course, we choose to optimize (constrain) >> functionality so tightly around what we want/need today that the >> prospect of getting anything different is effectively eliminated. > > this is the telco solution to the nasty disruptive technologies spawned > by the internet I could be mistaken, but I think Tom's point was "we could give people the ebony black bell phone, that'd really suck for us as a business/community." -chris From randy at psg.com Tue Dec 29 22:47:22 2009 From: randy at psg.com (Randy Bush) Date: Wed, 30 Dec 2009 07:47:22 +0900 Subject: ip-precedence for management traffic In-Reply-To: <75cb24520912291429v5008180bx65b45d13e275b397@mail.gmail.com> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> <20091229175941.GA21354@dan.olp.net> <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> <75cb24520912291429v5008180bx65b45d13e275b397@mail.gmail.com> Message-ID: >>> None of us knows precisely what we're going to absolutely require, or >>> merely want/prefer, tomorrow or the next day, much less a year or two >>> from now. Unless, of course, we choose to optimize (constrain) >>> functionality so tightly around what we want/need today that the >>> prospect of getting anything different is effectively eliminated. >> >> this is the telco solution to the nasty disruptive technologies spawned >> by the internet > > I could be mistaken, but I think Tom's point was "we could give people > the ebony black bell phone, that'd really suck for us as a > business/community." sorry, i should have been more clear that i was agreeing with tom. replies might not be assumed to be in opposition. randy From mike at mtcc.com Tue Dec 29 23:15:24 2009 From: mike at mtcc.com (Michael Thomas) Date: Tue, 29 Dec 2009 15:15:24 -0800 Subject: ip-precedence for management traffic In-Reply-To: References: <1262084530.4236.7.camel@localhost> <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <4B3A8D8C.6020403@mtcc.com> Randy Bush wrote: >> Totally out of the box, but here goes: why don't we run the entire >> Internet management plane "out of band" >> > > tread caefully. we have experienced (and some continue to experience) > non-linear expansion of management, control, and stability problems when > layers are non-congruent. > Isn't this just a suggestion to more or less faithfully reproduce the control and bearer planes of the TDM network also? I'd think that this fate sharing aspect of the internet model is a feature rather than a bug. That is, putting everything on the same wire forces you to deal with QoS or get the predictable results. That and building out separate and unequal networks pretty much sucks? Mike From jared at puck.nether.net Tue Dec 29 23:18:07 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Dec 2009 18:18:07 -0500 Subject: ip-precedence for management traffic In-Reply-To: <4B3A8D8C.6020403@mtcc.com> References: <1262084530.4236.7.camel@localhost> <1405A4AA-D83C-4D7B-8352-F399F7EA8EA4@arbor.net> <4C939B99-2BC9-4A54-99B2-467B20841FB6@akcin.net> <81D582C724CA1046A279A7EE1299638B02AC1A04@FHDP1LUMXCV24.us.one.verizon.com> <4B3A8D8C.6020403@mtcc.com> Message-ID: <946D61AB-9FD5-41B3-AE5F-EFDFCF05DA26@puck.nether.net> On Dec 29, 2009, at 6:15 PM, Michael Thomas wrote: > That and building out > separate and unequal networks pretty much sucks? It does create job preservation in old-school telcos, like T. - Jared From tvest at eyeconomics.com Tue Dec 29 23:41:33 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 29 Dec 2009 18:41:33 -0500 Subject: ip-precedence for management traffic In-Reply-To: References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <7183.1262106444@localhost> <81D582C724CA1046A279A7EE1299638B02AC1AAE@FHDP1LUMXCV24.us.one.verizon.com> <20091229175941.GA21354@dan.olp.net> <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> <75cb24520912291429v5008180bx65b45d13e275b397@mail.gmail.com> Message-ID: <74902B35-0305-4BBB-8E0E-BF6A64C6F22E@eyeconomics.com> On Dec 29, 2009, at 5:47 PM, Randy Bush wrote: >>>> None of us knows precisely what we're going to absolutely >>>> require, or >>>> merely want/prefer, tomorrow or the next day, much less a year or >>>> two >>>> from now. Unless, of course, we choose to optimize (constrain) >>>> functionality so tightly around what we want/need today that the >>>> prospect of getting anything different is effectively eliminated. >>> >>> this is the telco solution to the nasty disruptive technologies >>> spawned >>> by the internet >> >> I could be mistaken, but I think Tom's point was "we could give >> people >> the ebony black bell phone, that'd really suck for us as a >> business/community." > > sorry, i should have been more clear that i was agreeing with tom. > replies might not be assumed to be in opposition. I got that ;-) Chris is right, but so is Randy. IMO if the net is ultimately diminished in this manner, either through commission or omission, eating anything other than our own dog food would be neither defensible, nor sustainable for long. The rotary phone was great in its time, but that time has passed -- today there's lot more at stake than handset color. TV From andy at nosignal.org Wed Dec 30 07:54:16 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 30 Dec 2009 07:54:16 +0000 Subject: ip-precedence for management traffic In-Reply-To: <08EF11E7-090F-494B-8083-52D30D8DD9E5@puck.nether.net> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at Dec 29, 2009 10:22:29 AM <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <08EF11E7-090F-494B-8083-52D30D8DD9E5@puck.nether.net> Message-ID: <2EAC7814-F6B6-464D-9B9F-22A27DECC629@nosignal.org> On 29 Dec 2009, at 17:19, Jared Mauch wrote: > I've watched BCPs be diluted at various companies due to market pressures. $major_provider did not require me to register my routes, why should I have to do that in order to give you $X MRC for the next 12-24-36 months? [...] > Honestly, I wish we could have a "better" network. One where we have mutually agreed "I will filter my customers if you do". You can (should) still filter their prefixes - the customer get added pain because changes have to be done by hand, through tickets, maybe as a billable incident. :-) Andy From Andrew.Claybaugh at securian.com Wed Dec 30 12:01:08 2009 From: Andrew.Claybaugh at securian.com (Andrew.Claybaugh at securian.com) Date: Wed, 30 Dec 2009 06:01:08 -0600 Subject: Out of the office Message-ID: I will be out of the office starting 12/30/2009 and will not return until 01/04/2010. If you need immediate assistance please call TechSupport at 651-665-5000. From hiersd at gmail.com Wed Dec 30 13:54:41 2009 From: hiersd at gmail.com (David Hiers) Date: Wed, 30 Dec 2009 05:54:41 -0800 Subject: ip-precedence for management traffic Message-ID: <2873f3700912300554h3eec4220hbf48856fc9143577@mail.gmail.com> > Totally out of the box, but here goes: why don't we run the entire > Internet management plane "out of band" This has been one of my favorite conversation-stoppers for years. The PSTN fought tooth and nail against the need for OOB control, but 2600hz was a problem that they could not solve, so they bucked up and paid for a control plane. Where do you think we'd be now if Phreakers, Inc. still had access to a PSTN with an audio frequency, inband control plane? Don't we insist on, and brag over, data/control seperation within our devices? Isn't it groovy when a frame is never seen by the switch's CPU/SUP? Sure, I'm streching the analogy a bit here to make a point: many of our problems arise from giving bearer traffic access to the control plane. If the world wants an internet that is as predictable and reliable as the PSTN, it'll bear the cost of protecting the control plane. A fundamental choice in the protection scheme is physical architecture. IB or OOB, it's always a good thing to be explicit in design decisions, and not adopt legacy/heritage decisions without consideration. David PS: If you want OOB access to your gear when your core switches freak out, don't let those switches touch any frame between your WAN link and console ports. From a.harrowell at gmail.com Wed Dec 30 14:05:02 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 30 Dec 2009 14:05:02 +0000 Subject: ip-precedence for management traffic In-Reply-To: References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <8BBE56CB-27C3-405F-A044-8F4FB1B40FD9@eyeconomics.com> Message-ID: <200912301405.13169.a.harrowell@gmail.com> On Tuesday 29 December 2009 22:22:05 Randy Bush wrote: > > None of us knows precisely what we're going to absolutely require, or > > merely want/prefer, tomorrow or the next day, much less a year or two > > from now. Unless, of course, we choose to optimize (constrain) > > functionality so tightly around what we want/need today that the > > prospect of getting anything different is effectively eliminated. > > this is the telco solution to the nasty disruptive technologies spawned > by the internet > > randy It surely is. Also, when was the last time you had a customer ring up and ask for a product "like the Internet but with bits missing"? Nobody wants it, and the evidence of this is that nobody asks for it, and further that nobody's started an ISP that provides it, although people have been talking about it for years. The support for "the Internet but not quite" is usually from either: 1) Telcos who secretly wish the Internet would go away 2) Security/morals bureaucrats (who secretly wish it would go away) 3) Engineers noodling on the idea, who don't have a business model for it Note that this list doesn't include "users" or "customers" or anyone willing to offer "money" for it. Also, I don't think it's at all clear that Internet-minus service would be cheaper to provide. Basically, if you have an IP network you can provide all the applications over it by default. Therefore, if you want to get rid of some, you've got to make an effort, which implies cost. There is no such thing as a Web DSL modem or a Web router. In terms of traffic, as over 50% of the total is WWW these days, and a sizable chunk of the rest is Web-video streaming, once you've chucked in the e-mail, it's far from clear that you'd save significant amounts of bandwidth. Obviously, if you were intending to offer proper Internet service as an extra- cost option, you wouldn't have two lots of access lines, backhaul, transit - you'd filter more ports for some subset of your addressing scheme, or put the less-than-Internet customers on a different layer 2 vlan. So you'd still need the extra bandwidth for the other customers. Where is the saving? Fewer support calls due to...what exactly? aren't the biggest malware vectors now web-based drive by download, sql injection and the like? Of course, there'll be a fair few wanting to know why slingbox, skype, IM protocol of choice, work vpns etc don't work. The exercise is pointless. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From rsk at gsp.org Wed Dec 30 14:34:53 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 30 Dec 2009 09:34:53 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> Message-ID: <20091230143453.GA463@gsp.org> On Wed, Dec 23, 2009 at 01:58:47AM -0500, Christopher Morrow wrote: > The ARIN meetings (at least) are open, please come and help guide > policies. I'm sure RIPE also wouldn't mind a discussion, if there > could be some positive policy outcome. Why should I or anyone else do that? It will cost us, personally, a great deal of time and money and hassle and -- as far as I can tell -- will achieve nothing. Let me explain why I say that. The senior people working in the anti-abuse area aren't hard to find. We hang out on spam-l, or funsec, or in various blogs, and we publish comments/reports/essays pointing out what we observe. (Well, at least some of it. I've learned to keep much of what I find back, as it often reveals too much about my methods. And there's been retaliation from time to time, some of it disruptive and expensive.) If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product. And they would have already blacklisted certain individuals/organizations -- permanently -- and revoked all their resources. (I trust everyone is painfully aware than all lesser steps have already failed miserably and will of course fail miserably in the future. This is not a set of problems that can be addressed with half-measures: those are really not worth anyone's time or effort. Even the approach I'm suggesting may well not be sufficient, but it's clearly necessary.) I see no sign that these organizations are taking any such measures, nor any sign that they're even open to the possibility of doing so. Yet this is what must be done if any substantial impact is to be achieved. Bad actors have quite thoroughly gamed the system and have long since provided overwhelming proof that while their tactics may change, their strategy will always be to profit by as much abuse they can possibly manage. They'll never stop, they'll only adapt as old methods cease to work and new ones become available; it's their "career". The only recourse we have is to cut them off for life. ---Rsk From randy at psg.com Wed Dec 30 14:42:06 2009 From: randy at psg.com (Randy Bush) Date: Wed, 30 Dec 2009 23:42:06 +0900 Subject: Article on spammers and their infrastructure In-Reply-To: <20091230143453.GA463@gsp.org> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> Message-ID: > If ARIN and/or RIPE and/or ICANN and/or anyone else were truly > interested in making a dent in the problem, then they would have > already paid attention to our collective work product. the rirs, the ietf, the icann, ... each think they are the top of the mountain. we are supposed to come to them and pray. more likely that the itu will come to them and prey. randy From jmamodio at gmail.com Wed Dec 30 14:48:34 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 30 Dec 2009 08:48:34 -0600 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> Message-ID: <202705b0912300648s274bb6faq51ef30468fa56e69@mail.gmail.com> >> If ARIN and/or RIPE and/or ICANN and/or anyone else were truly >> interested in making a dent in the problem, then they would have >> already paid attention to our collective work product. > > the rirs, the ietf, the icann, ... each think they are the top of the > mountain. ?we are supposed to come to them and pray. ?more likely that > the itu will come to them and prey. I thought the ITU is the owner of the mountain or pretends to be... Jorge From mike at mtcc.com Wed Dec 30 14:50:37 2009 From: mike at mtcc.com (Michael Thomas) Date: Wed, 30 Dec 2009 06:50:37 -0800 Subject: ip-precedence for management traffic In-Reply-To: <2873f3700912300554h3eec4220hbf48856fc9143577@mail.gmail.com> References: <2873f3700912300554h3eec4220hbf48856fc9143577@mail.gmail.com> Message-ID: <4B3B68BD.1040407@mtcc.com> David Hiers wrote: > If the world wants an internet that is as predictable and reliable as > the PSTN, it'll bear the cost of protecting the control plane. A > fundamental choice in the protection scheme is physical architecture. > IB or OOB, it's always a good thing to be explicit in design > decisions, and not adopt legacy/heritage decisions without > consideration. > What's the "control plane" anyway? It includes google, right? Mike From nanog-post at rsuc.gweep.net Wed Dec 30 14:55:57 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 30 Dec 2009 09:55:57 -0500 Subject: ip-precedence for management traffic In-Reply-To: <08EF11E7-090F-494B-8083-52D30D8DD9E5@puck.nether.net> References: <81D582C724CA1046A279A7EE1299638B02AC1A42@FHDP1LUMXCV24.us.one.verizon.com> <200912291600.nBTG0vt8015215@aurora.sol.net> <81D582C724CA1046A279A7EE1299638B02AC1A9A@FHDP1LUMXCV24.us.one.verizon.com> <08EF11E7-090F-494B-8083-52D30D8DD9E5@puck.nether.net> Message-ID: <20091230145557.GA19232@gweep.net> On Tue, Dec 29, 2009 at 12:19:32PM -0500, Jared Mauch wrote: [snip] > Apparently I forgot the tag, but really, if you have sane > CoPP policies, you are mostly protected. If the vendor does not > provide this capability, please STOP BUYING THEIR CRAP. Another fine example of broken fate-sharing when management plane (executives with purse strings) is strictly segmented from control plane (engineers and operators). -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From paul.w.bennett at gmail.com Wed Dec 30 15:49:47 2009 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Wed, 30 Dec 2009 10:49:47 -0500 Subject: Consumer-grade dual-homed connectivity options? Message-ID: Not sure whether this is an appropriate place to post this, but I thought I'd give it a shot, since you're all knowledgeable folks with regard to networking things... At home, I currently run two DSL lines. Right now, we just have two separate LANs, one connected to each line, with my wife's devices attached to one, and my devices attached to the other. For a while now, I've been thinking about setting up a load-balancing routing solution to give both of us access to both lines. I have the opportunity to acquire a refurbed Cisco Catalyst 2960 at a ridiculously low price. I also have access to a (nominally) spare quad-core 64-bit PC with 8GB of RAM. I say "nominally" because I'm thinking about setting it up as a media center / gaming rig connected to the TV in the den. That's largely beside the point, but it bears pointing out that keeping the PC available for my other needs would be a good thing. So. Is it going to be a more-effective solution to drop a few bucks on the 2960 and go through the hassle of learning how to set it up (and then setting it up), or would I be better off putting a secured Linux distro (e.g. gentoo-hardened, or something) on the semi-spare PC and running the load-balancing via iproute2 and friends? Either way, I'm looking at a learning curve, and a good amount of time fannying around getting the damn thing working -- there's a good chance I'd spend almost as much cash on the PC-based solution getting good-quality network cards, and maybe fast HDD tech (though it seems like RAM and cores would be more important than disk IO). What are your opinions? -- Paul From tims at donet.com Wed Dec 30 16:12:59 2009 From: tims at donet.com (Tim Sanderson) Date: Wed, 30 Dec 2009 11:12:59 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: References: Message-ID: <175DA64769AE0F4498D813EDBFB44949876A563715@intexch07.internal.donet.com> Do you control or have access to the provider side-the PPPoE server-and would both PPPoE connections hit the same PPPoE server at the provider? If so, I recommend setting up a PPP multilink with both DSL lines. The DSL provider would have to support that capability. I also recommend something like a Cisco 2691 router with two WIC-1ADSL cards. I have used this hardware for a 2xDSL multilink to my own home and it worked well. -- Tim -----Original Message----- From: Paul Bennett [mailto:paul.w.bennett at gmail.com] Sent: Wednesday, December 30, 2009 10:50 AM To: nanog at nanog.org Subject: Consumer-grade dual-homed connectivity options? Not sure whether this is an appropriate place to post this, but I thought I'd give it a shot, since you're all knowledgeable folks with regard to networking things... At home, I currently run two DSL lines. Right now, we just have two separate LANs, one connected to each line, with my wife's devices attached to one, and my devices attached to the other. For a while now, I've been thinking about setting up a load-balancing routing solution to give both of us access to both lines. I have the opportunity to acquire a refurbed Cisco Catalyst 2960 at a ridiculously low price. I also have access to a (nominally) spare quad-core 64-bit PC with 8GB of RAM. I say "nominally" because I'm thinking about setting it up as a media center / gaming rig connected to the TV in the den. That's largely beside the point, but it bears pointing out that keeping the PC available for my other needs would be a good thing. So. Is it going to be a more-effective solution to drop a few bucks on the 2960 and go through the hassle of learning how to set it up (and then setting it up), or would I be better off putting a secured Linux distro (e.g. gentoo-hardened, or something) on the semi-spare PC and running the load-balancing via iproute2 and friends? Either way, I'm looking at a learning curve, and a good amount of time fannying around getting the damn thing working -- there's a good chance I'd spend almost as much cash on the PC-based solution getting good-quality network cards, and maybe fast HDD tech (though it seems like RAM and cores would be more important than disk IO). What are your opinions? -- Paul THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. From smb at cs.columbia.edu Wed Dec 30 16:13:24 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 30 Dec 2009 11:13:24 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: References: Message-ID: <408FE52C-BF6A-4AA3-B30C-8E414948A932@cs.columbia.edu> On Dec 30, 2009, at 10:49 AM, Paul Bennett wrote: > Not sure whether this is an appropriate place to post this, but I thought I'd give it a shot, since you're all knowledgeable folks with regard to networking things... > > At home, I currently run two DSL lines. Right now, we just have two separate LANs, one connected to each line, with my wife's devices attached to one, and my devices attached to the other. For a while now, I've been thinking about setting up a load-balancing routing solution to give both of us access to both lines. > > I have the opportunity to acquire a refurbed Cisco Catalyst 2960 at a ridiculously low price. I also have access to a (nominally) spare quad-core 64-bit PC with 8GB of RAM. I say "nominally" because I'm thinking about setting it up as a media center / gaming rig connected to the TV in the den. That's largely beside the point, but it bears pointing out that keeping the PC available for my other needs would be a good thing. > > So. > > Is it going to be a more-effective solution to drop a few bucks on the 2960 and go through the hassle of learning how to set it up (and then setting it up), or would I be better off putting a secured Linux distro (e.g. gentoo-hardened, or something) on the semi-spare PC and running the load-balancing via iproute2 and friends? > > Either way, I'm looking at a learning curve, and a good amount of time fannying around getting the damn thing working -- there's a good chance I'd spend almost as much cash on the PC-based solution getting good-quality network cards, and maybe fast HDD tech (though it seems like RAM and cores would be more important than disk IO). > > What are your opinions? I know nothing of how to do this on a Catalyst; for PCs, my own guess is that you're looking far too high-end. If the issue is relaying to the outside, I suspect that a small, dedicated Soekris or the like will do all you need -- there's no point in switching traffic faster than your DSL lines can run. I'm not doing load-balancing, but all traffic from my house to the outside world (I have a cable modem) goes through a Soekris 4801, and I can download large files from my office at 12-13M bps. Further, since the Soekris is bridging some networks, its interfaces are in promiscuous mode, so the box is seeing every packet on my home LAN. Granted, there usually isn't that much traffic, even though the house is wired for GigE -- but I suspect I'm seeing about as much speed, end to end, as the cable modem will give me. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jason at i6ix.com Wed Dec 30 16:14:45 2009 From: jason at i6ix.com (Jason Bertoch) Date: Wed, 30 Dec 2009 11:14:45 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: References: Message-ID: <4B3B7C75.1020208@i6ix.com> Paul Bennett wrote: > > At home, I currently run two DSL lines. Right now, we just have two > separate LANs, one connected to each line, with my wife's devices > attached to one, and my devices attached to the other. For a while now, > I've been thinking about setting up a load-balancing routing solution to > give both of us access to both lines. > Have you looked at a simple dual-WAN router? From math at sizone.org Wed Dec 30 16:46:36 2009 From: math at sizone.org (Ken Chase) Date: Wed, 30 Dec 2009 11:46:36 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <175DA64769AE0F4498D813EDBFB44949876A563715@intexch07.internal.donet.com> References: <175DA64769AE0F4498D813EDBFB44949876A563715@intexch07.internal.donet.com> Message-ID: <20091230164636.GN24092@sizone.org> 2x DSL not so backhoe-resistant. I like mixing cable with dsl. Tasty disparate paths (modulo garden shears applied to the single ingres point to your basement) if not technologies, orgs and methodologies. Or radio + dsl, or pigeon + mule, take your pick. Would be great if you could rate your connections somehow (ToS? packets under 1000 bytes?) and for those with high priority (voip, ssh < 10K/s != scp, etc) spray redundant udp packets containing your data down all links, first packet to the end point wins. Higher speed stuff just gets RR'd for aggregate bandwidth. Could even brute force your way through packetloss (ever try typing into an ssh session with even 10% pl?) with redundant packets down the same links, just use up 10K/s of bandwidth for 1K/s of desired throughput. Nicer with the local cable co *IX'd a few ms away from the DSL endpoints. (I suspect that higher latency differences would make this less viable). Course there's still the issue of a single org at the endpoint - that's your SPOF, but it's easily up more than my dsl at home here is. If it fails, use your base connection to the other provider for internets (unfortunately your ips for inbound connections wont be working during the outtage without more tricks at the far end). Does mulitlink specify any ability such as this, or is this a non existent protocol as yet? Would anyone find it useful? /kc On Wed, Dec 30, 2009 at 11:12:59AM -0500, Tim Sanderson's said: >Do you control or have access to the provider side-the PPPoE server-and would both PPPoE connections hit the same PPPoE server at the provider? If so, I recommend setting up a PPP multilink with both DSL lines. The DSL provider would have to support that capability. I also recommend something like a Cisco 2691 router with two WIC-1ADSL cards. I have used this hardware for a 2xDSL multilink to my own home and it worked well. > >-- >Tim > > >-----Original Message----- >From: Paul Bennett [mailto:paul.w.bennett at gmail.com] >Sent: Wednesday, December 30, 2009 10:50 AM >To: nanog at nanog.org >Subject: Consumer-grade dual-homed connectivity options? > >Not sure whether this is an appropriate place to post this, but I thought >I'd give it a shot, since you're all knowledgeable folks with regard to >networking things... > >At home, I currently run two DSL lines. Right now, we just have two >separate LANs, one connected to each line, with my wife's devices attached >to one, and my devices attached to the other. For a while now, I've been >thinking about setting up a load-balancing routing solution to give both >of us access to both lines. > >I have the opportunity to acquire a refurbed Cisco Catalyst 2960 at a >ridiculously low price. I also have access to a (nominally) spare >quad-core 64-bit PC with 8GB of RAM. I say "nominally" because I'm >thinking about setting it up as a media center / gaming rig connected to >the TV in the den. That's largely beside the point, but it bears pointing >out that keeping the PC available for my other needs would be a good thing. > >So. > >Is it going to be a more-effective solution to drop a few bucks on the >2960 and go through the hassle of learning how to set it up (and then >setting it up), or would I be better off putting a secured Linux distro >(e.g. gentoo-hardened, or something) on the semi-spare PC and running the >load-balancing via iproute2 and friends? > >Either way, I'm looking at a learning curve, and a good amount of time >fannying around getting the damn thing working -- there's a good chance >I'd spend almost as much cash on the PC-based solution getting >good-quality network cards, and maybe fast HDD tech (though it seems like >RAM and cores would be more important than disk IO). > >What are your opinions? > > > >-- >Paul > > >THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From brandon.galbraith at gmail.com Wed Dec 30 16:53:11 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 30 Dec 2009 10:53:11 -0600 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <20091230164636.GN24092@sizone.org> References: <175DA64769AE0F4498D813EDBFB44949876A563715@intexch07.internal.donet.com> <20091230164636.GN24092@sizone.org> Message-ID: <366100670912300853g7e1a48e3k404cf1088249c497@mail.gmail.com> On Wed, Dec 30, 2009 at 10:46 AM, Ken Chase wrote: > 2x DSL not so backhoe-resistant. > > I like mixing cable with dsl. Tasty disparate paths (modulo garden shears > applied to the single ingres point to your basement) if not technologies, > orgs > and methodologies. Or radio + dsl, or pigeon + mule, take your pick. > *snip* I'm using cable and wimax in the Chicago suburbs with a dual-wan router. Works well, would recommend to others, and so forth. > /kc > > > On Wed, Dec 30, 2009 at 11:12:59AM -0500, Tim Sanderson's said: > >Do you control or have access to the provider side-the PPPoE server-and > would both PPPoE connections hit the same PPPoE server at the provider? If > so, I recommend setting up a PPP multilink with both DSL lines. The DSL > provider would have to support that capability. I also recommend something > like a Cisco 2691 router with two WIC-1ADSL cards. I have used this hardware > for a 2xDSL multilink to my own home and it worked well. > > > >-- > >Tim > > > > > >-----Original Message----- > >From: Paul Bennett [mailto:paul.w.bennett at gmail.com] > >Sent: Wednesday, December 30, 2009 10:50 AM > >To: nanog at nanog.org > >Subject: Consumer-grade dual-homed connectivity options? > > > >Not sure whether this is an appropriate place to post this, but I thought > >I'd give it a shot, since you're all knowledgeable folks with regard to > >networking things... > > > >At home, I currently run two DSL lines. Right now, we just have two > >separate LANs, one connected to each line, with my wife's devices > attached > >to one, and my devices attached to the other. For a while now, I've been > >thinking about setting up a load-balancing routing solution to give both > >of us access to both lines. > > > >I have the opportunity to acquire a refurbed Cisco Catalyst 2960 at a > >ridiculously low price. I also have access to a (nominally) spare > >quad-core 64-bit PC with 8GB of RAM. I say "nominally" because I'm > >thinking about setting it up as a media center / gaming rig connected to > >the TV in the den. That's largely beside the point, but it bears pointing > >out that keeping the PC available for my other needs would be a good > thing. > > > >So. > > > >Is it going to be a more-effective solution to drop a few bucks on the > >2960 and go through the hassle of learning how to set it up (and then > >setting it up), or would I be better off putting a secured Linux distro > >(e.g. gentoo-hardened, or something) on the semi-spare PC and running the > >load-balancing via iproute2 and friends? > > > >Either way, I'm looking at a learning curve, and a good amount of time > >fannying around getting the damn thing working -- there's a good chance > >I'd spend almost as much cash on the PC-based solution getting > >good-quality network cards, and maybe fast HDD tech (though it seems like > >RAM and cores would be more important than disk IO). > > > >What are your opinions? > > > > > > > >-- > >Paul > > > > > >THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE > INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION > THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER > APPLICABLE LAW. If the reader of this message is not the intended recipient, > or the employee or agent responsible for delivering the message to the > intended recipient, you are hereby notified that you have received this > message in error and that any review, dissemination, distribution, or > copying of this message is strictly prohibited. If you have received this > message in error, please notify the sender immediately by e-mail or > telephone, and delete the original message immediately. Thank you. > > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > Front St. W. > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From simonchennj at gmail.com Wed Dec 30 17:02:53 2009 From: simonchennj at gmail.com (Simon Chen) Date: Wed, 30 Dec 2009 12:02:53 -0500 Subject: question regarding multi-homing Message-ID: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> Hi all, Happy new year... I have a question regarding multi-homing, mostly from stub network's operational point of view. My big question is: what kind of failures do you usually see from your providers? Link down? Link up, but withdraw some routes? Link up, no route change, but blackholing partial or all traffic? Anything else? Let's say that I have two local routers (Ra and Rb) connecting to two providers, A and B. If router Ra sees provider A with problems of the first two cases (link down, link up but withdraw routes), the Rb can easily step up. My question is, if I am using provider A as the default, but provider A has the third problem (link up, no route change, but blackholing traffic), how can I detect it and switch provider automatically? To state this problem in detail: I use a static default route on Ra to forward traffic to provider A, or receive 0/0 from provider A via BGP. For some reason, provider A can no longer reach a /24. My network cannot be notified (unless, I receive a full internet routing table). In this case, all I know is that my traffic to /24 is blackholed through provider A. In this case, is there an automatic way for my stub network to switch over to provider B? Do I have to do the detection and switch over manually? I don't think VRRP can help here, right? Thanks. -Simon From sethm at rollernet.us Wed Dec 30 17:29:11 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 30 Dec 2009 09:29:11 -0800 Subject: question regarding multi-homing In-Reply-To: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> References: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> Message-ID: <4B3B8DE7.40802@rollernet.us> Simon Chen wrote: > Hi all, > > Happy new year... > > I have a question regarding multi-homing, mostly from stub network's > operational point of view. My big question is: what kind of failures > do you usually see from your providers? Link down? Link up, but > withdraw some routes? Link up, no route change, but blackholing > partial or all traffic? Anything else? > I am a multihomed network with no downstream customers. Speaking only for myself over the last 5 years I have only had loss of link conditions as the majority problem such as: * DLCI deleted (LEC "accidentally canceled" a FRT1 once) * Loss of signal (almost always LEC problems) * Loss of frame (almost always long haul problems) It's worth noting all my circuits are T1, T3, or OC-x and less likely to have an "up/up but not passing traffic" state like an Ethernet handoff could do. And only once: * Sprint vs. Cogent peering spat (I'm a Sprint customer) The last one would have been a huge problem for default route or single homed users - and why I always recommend full tables - but for me I didn't care since the affected paths disappeared via Sprint but were still there via my other upstream. > To state this problem in detail: I use a static default route on Ra to > forward traffic to provider A, or receive 0/0 from provider A via BGP. > For some reason, provider A can no longer reach a /24. My network > cannot be notified (unless, I receive a full internet routing table). > In this case, all I know is that my traffic to /24 is blackholed > through provider A. In this case, is there an automatic way for my > stub network to switch over to provider B? Do I have to do the > detection and switch over manually? I don't think VRRP can help here, > right? You're asking for what BGP does. You could ping every prefix you care about and do it by hand, I guess. If this is a major concern for you I'd say full tables are in your best interest so you can let BGP do what it does best. (Disclaimer: there may be some trick I'm not aware of because I always prefer to let BGP do its job.) ~Seth From dylan.ebner at crlmed.com Wed Dec 30 17:38:28 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 30 Dec 2009 17:38:28 +0000 Subject: question regarding multi-homing In-Reply-To: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> References: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> Message-ID: <017265BF3B9640499754DD48777C3D206717A6EADA@MBX9.EXCHPROD.USA.NET> Simon- We do exactly what you are trying to accomplish. We have two routers and two providers. Provider A is our primary and we receive partial routes from them (no static route). Then Router B is connected to Provider B with no default route (basically it looks like we are not advertising to them). Our AS on router b is prepended several times. Router A and B are connected via iBGP to eachother. Then, using interface tracking (we are a cisco shop) we can fail to provider B. So, about the only failure we cannot automatically recover from is if we have our router A interface / layer1 to provider A start to fail and we get enough traffic through to keep BGP up, but errors make ip traffic fail. This failover has worked server times while in production. Mostly we see our BGP drop from provider A, but we have also seen link down from provider a. In testing we failed links and routers, which always recovered just fine. But we all know the lab can be completely different from the real world. If you want to see how this work for us, go to bgplay.com and enter the following: Network: 67.135.55.0/24 Start: 26/12/2009 20:00:00 End: 27/12/2009 07:00:00 Pull out 19629 (ME) 209 (Qwest, provider A) 7263 (GoFast. Dba Sungard, provider B) At about 20:11 you see the routes start failing to AS7263 and then at about 6:23 the next day they start failing back. This example happened when Qwest lost an edge router in Minnesota. Link status was up, but BGP tables were lost, so we had no router out to qwest. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: Simon Chen [mailto:simonchennj at gmail.com] Sent: Wednesday, December 30, 2009 11:03 AM To: nanog at nanog.org Subject: question regarding multi-homing Hi all, Happy new year... I have a question regarding multi-homing, mostly from stub network's operational point of view. My big question is: what kind of failures do you usually see from your providers? Link down? Link up, but withdraw some routes? Link up, no route change, but blackholing partial or all traffic? Anything else? Let's say that I have two local routers (Ra and Rb) connecting to two providers, A and B. If router Ra sees provider A with problems of the first two cases (link down, link up but withdraw routes), the Rb can easily step up. My question is, if I am using provider A as the default, but provider A has the third problem (link up, no route change, but blackholing traffic), how can I detect it and switch provider automatically? To state this problem in detail: I use a static default route on Ra to forward traffic to provider A, or receive 0/0 from provider A via BGP. For some reason, provider A can no longer reach a /24. My network cannot be notified (unless, I receive a full internet routing table). In this case, all I know is that my traffic to /24 is blackholed through provider A. In this case, is there an automatic way for my stub network to switch over to provider B? Do I have to do the detection and switch over manually? I don't think VRRP can help here, right? Thanks. -Simon From sfischer1967 at gmail.com Wed Dec 30 18:08:27 2009 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 30 Dec 2009 13:08:27 -0500 Subject: question regarding multi-homing In-Reply-To: <017265BF3B9640499754DD48777C3D206717A6EADA@MBX9.EXCHPROD.USA.NET> References: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> <017265BF3B9640499754DD48777C3D206717A6EADA@MBX9.EXCHPROD.USA.NET> Message-ID: <500ffb690912301008q1ac3343an7bf2f6aaec474f65@mail.gmail.com> If you are using Cisco... http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps8787/product_data_sheet0900aecd806c4ee4.html On Wed, Dec 30, 2009 at 12:38 PM, Dylan Ebner wrote: > Simon- > We do exactly what you are trying to accomplish. We have two routers and > two providers. Provider A is our primary and we receive partial routes from > them (no static route). Then Router B is connected to Provider B with no > default route (basically it looks like we are not advertising to them). Our > AS on router b is prepended several times. Router A and B are connected via > iBGP to eachother. Then, using interface tracking (we are a cisco shop) we > can fail to provider B. So, about the only failure we cannot automatically > recover from is if we have our router A interface / layer1 to provider A > start to fail and we get enough traffic through to keep BGP up, but errors > make ip traffic fail. > > This failover has worked server times while in production. Mostly we see > our BGP drop from provider A, but we have also seen link down from provider > a. In testing we failed links and routers, which always recovered just fine. > But we all know the lab can be completely different from the real world. > > If you want to see how this work for us, go to bgplay.com and enter the > following: > > Network: 67.135.55.0/24 > > Start: 26/12/2009 20:00:00 > End: 27/12/2009 07:00:00 > > Pull out 19629 (ME) > 209 (Qwest, provider A) > 7263 (GoFast. Dba Sungard, provider B) > > At about 20:11 you see the routes start failing to AS7263 and then at about > 6:23 the next day they start failing back. > > > This example happened when Qwest lost an edge router in Minnesota. Link > status was up, but BGP tables were lost, so we had no router out to qwest. > > > > > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > > -----Original Message----- > From: Simon Chen [mailto:simonchennj at gmail.com] > Sent: Wednesday, December 30, 2009 11:03 AM > To: nanog at nanog.org > Subject: question regarding multi-homing > > Hi all, > > Happy new year... > > I have a question regarding multi-homing, mostly from stub network's > operational point of view. My big question is: what kind of failures > do you usually see from your providers? Link down? Link up, but > withdraw some routes? Link up, no route change, but blackholing > partial or all traffic? Anything else? > > Let's say that I have two local routers (Ra and Rb) connecting to two > providers, A and B. If router Ra sees provider A with problems of the > first two cases (link down, link up but withdraw routes), the Rb can > easily step up. My question is, if I am using provider A as the > default, but provider A has the third problem (link up, no route > change, but blackholing traffic), how can I detect it and switch > provider automatically? > > To state this problem in detail: I use a static default route on Ra to > forward traffic to provider A, or receive 0/0 from provider A via BGP. > For some reason, provider A can no longer reach a /24. My network > cannot be notified (unless, I receive a full internet routing table). > In this case, all I know is that my traffic to /24 is blackholed > through provider A. In this case, is there an automatic way for my > stub network to switch over to provider B? Do I have to do the > detection and switch over manually? I don't think VRRP can help here, > right? > > Thanks. > -Simon > > > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From info at n-connect.net Wed Dec 30 18:04:20 2009 From: info at n-connect.net (Jerry Pasker) Date: Wed, 30 Dec 2009 12:04:20 -0600 Subject: just...wow. Message-ID: I got this email inquiring about data center space, from the most honest scumbag, *EVER* today. Operational relevance? Well, if everyone would turn these people down, we'd have a lot less problems to deal with. Sadly, requests like these happen far too often, but never have I had someone come right out and explain what they were doing up front like this without having to dig in to it. Scumbag email: ------------ Hello, I need servers to host botnet controller. Botnet controller is software that sends tasks to bots. Bots are hosts which send spam emails to millions of addresses. It's not direct spam but abuses on botnet contoller are received from time to time. What is your policy in case of receiving abuses and what is your policy in case of receiving a lot of abuses? What is policy about spam (not direct from your ips as I mentioned above)? Is it possible to host botnet controller in your datacenter during long-term time? Thank you. -------------- The part that leaves me feeling good is that they do get abuse complaints from time to time. There's hope. From patrick at ianai.net Wed Dec 30 18:12:29 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 30 Dec 2009 13:12:29 -0500 Subject: just...wow. In-Reply-To: References: Message-ID: On Dec 30, 2009, at 1:04 PM, Jerry Pasker wrote: > I got this email inquiring about data center space, from the most honest scumbag, *EVER* today. Operational relevance? Well, if everyone would turn these people down, we'd have a lot less problems to deal with. Sadly, requests like these happen far too often, but never have I had someone come right out and explain what they were doing up front like this without having to dig in to it. They are going around to many providers. Word of warning: At least one provider has commented that www.$COMPANY.com was DoS'ed when he turned down their request, although he said it was a pretty weak DoS. Guess his botnet controller isn't very good. :) -- TTFN, patrick > Scumbag email: > ------------ > Hello, > > I need servers to host botnet controller. Botnet controller is software that sends tasks to bots. Bots are hosts which send spam emails to millions of addresses. It's not direct spam but abuses on botnet contoller are received from time to time. What is your policy in case of receiving abuses and what is your policy in case of receiving a lot of abuses? What is policy about spam (not direct from your ips as I mentioned above)? Is it possible to host botnet controller in your datacenter during long-term time? > > Thank you. > -------------- > > The part that leaves me feeling good is that they do get abuse complaints from time to time. There's hope. > From smb at cs.columbia.edu Wed Dec 30 18:20:34 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 30 Dec 2009 13:20:34 -0500 Subject: just...wow. In-Reply-To: References: Message-ID: On Dec 30, 2009, at 1:04 PM, Jerry Pasker wrote: > I got this email inquiring about data center space, from the most honest scumbag, *EVER* today. Operational relevance? Well, if everyone would turn these people down, we'd have a lot less problems to deal with. Sadly, requests like these happen far too often, but never have I had someone come right out and explain what they were doing up front like this without having to dig in to it. > > Scumbag email: > ------------ > Hello, > > I need servers to host botnet controller. Botnet controller is software that sends tasks to bots. Bots are hosts which send spam emails to millions of addresses. It's not direct spam but abuses on botnet contoller are received from time to time. What is your policy in case of receiving abuses and what is your policy in case of receiving a lot of abuses? What is policy about spam (not direct from your ips as I mentioned above)? Is it possible to host botnet controller in your datacenter during long-term time? > > Thank you. > -------------- > > The part that leaves me feeling good is that they do get abuse complaints from time to time. There's hope. > > Of course, it could also be a joe job to frame the inquirer... --Steve Bellovin, http://www.cs.columbia.edu/~smb From herrin-nanog at dirtside.com Wed Dec 30 18:25:00 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 30 Dec 2009 13:25:00 -0500 Subject: question regarding multi-homing In-Reply-To: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> References: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> Message-ID: <3c3e3fca0912301025p22816282jbb6b1a857817aaa1@mail.gmail.com> On Wed, Dec 30, 2009 at 12:02 PM, Simon Chen wrote: > I have a question regarding multi-homing, mostly from stub network's > operational point of view. My big question is: what kind of failures > do you usually see from your providers? Link down? Link up, but > withdraw some routes? Link up, no route change, but blackholing > partial or all traffic? Anything else? Two more failure modes: Link up, receiving all routes but provider stops propagating your announcement outward. Link up but unusably high packet loss to some or all destinations. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dhetzel at gmail.com Wed Dec 30 19:02:15 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Wed, 30 Dec 2009 14:02:15 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <366100670912300853g7e1a48e3k404cf1088249c497@mail.gmail.com> References: <175DA64769AE0F4498D813EDBFB44949876A563715@intexch07.internal.donet.com> <20091230164636.GN24092@sizone.org> <366100670912300853g7e1a48e3k404cf1088249c497@mail.gmail.com> Message-ID: <7db2dcf90912301102i233dc41fg12e8e66d6fc6d575@mail.gmail.com> I use a T1/26xx for primary and a sprint datacard in a little NAT router for secondary. The two boxes sit on the same LAN but provide different gateway IP addresses. The sprint router does the DHCP, so things that ask for DHCP wind up using that as the primary. Some boxes use the 26xx as default gateway with static IP's outside the DHCP range. A smart enough box could choose paths per conversation by playing with the next hop. If that active path for a box fails I can just change it's default gateway to switch to the other service. I have a routable C I use for the LAN, the sprint connections just NAT's it anyway, the other connection is firewalled but not NAT'd. Seems to work ok for me. Could be made fancier. On Wed, Dec 30, 2009 at 11:53 AM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > On Wed, Dec 30, 2009 at 10:46 AM, Ken Chase wrote: > > > 2x DSL not so backhoe-resistant. > > > > I like mixing cable with dsl. Tasty disparate paths (modulo garden shears > > applied to the single ingres point to your basement) if not technologies, > > orgs > > and methodologies. Or radio + dsl, or pigeon + mule, take your pick. > > > > *snip* > > I'm using cable and wimax in the Chicago suburbs with a dual-wan router. > Works well, would recommend to others, and so forth. > > > > > /kc > > > > > > On Wed, Dec 30, 2009 at 11:12:59AM -0500, Tim Sanderson's said: > > >Do you control or have access to the provider side-the PPPoE server-and > > would both PPPoE connections hit the same PPPoE server at the provider? > If > > so, I recommend setting up a PPP multilink with both DSL lines. The DSL > > provider would have to support that capability. I also recommend > something > > like a Cisco 2691 router with two WIC-1ADSL cards. I have used this > hardware > > for a 2xDSL multilink to my own home and it worked well. > > > > > >-- > > >Tim > > > > > > > > >-----Original Message----- > > >From: Paul Bennett [mailto:paul.w.bennett at gmail.com] > > >Sent: Wednesday, December 30, 2009 10:50 AM > > >To: nanog at nanog.org > > >Subject: Consumer-grade dual-homed connectivity options? > > > > > >Not sure whether this is an appropriate place to post this, but I > thought > > >I'd give it a shot, since you're all knowledgeable folks with regard to > > >networking things... > > > > > >At home, I currently run two DSL lines. Right now, we just have two > > >separate LANs, one connected to each line, with my wife's devices > > attached > > >to one, and my devices attached to the other. For a while now, I've > been > > >thinking about setting up a load-balancing routing solution to give > both > > >of us access to both lines. > > > > > >I have the opportunity to acquire a refurbed Cisco Catalyst 2960 at a > > >ridiculously low price. I also have access to a (nominally) spare > > >quad-core 64-bit PC with 8GB of RAM. I say "nominally" because I'm > > >thinking about setting it up as a media center / gaming rig connected > to > > >the TV in the den. That's largely beside the point, but it bears > pointing > > >out that keeping the PC available for my other needs would be a good > > thing. > > > > > >So. > > > > > >Is it going to be a more-effective solution to drop a few bucks on the > > >2960 and go through the hassle of learning how to set it up (and then > > >setting it up), or would I be better off putting a secured Linux distro > > >(e.g. gentoo-hardened, or something) on the semi-spare PC and running > the > > >load-balancing via iproute2 and friends? > > > > > >Either way, I'm looking at a learning curve, and a good amount of time > > >fannying around getting the damn thing working -- there's a good chance > > >I'd spend almost as much cash on the PC-based solution getting > > >good-quality network cards, and maybe fast HDD tech (though it seems > like > > >RAM and cores would be more important than disk IO). > > > > > >What are your opinions? > > > > > > > > > > > >-- > > >Paul > > > > > > > > >THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE > > INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION > > THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER > > APPLICABLE LAW. If the reader of this message is not the intended > recipient, > > or the employee or agent responsible for delivering the message to the > > intended recipient, you are hereby notified that you have received this > > message in error and that any review, dissemination, distribution, or > > copying of this message is strictly prohibited. If you have received this > > message in error, please notify the sender immediately by e-mail or > > telephone, and delete the original message immediately. Thank you. > > > > -- > > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > > Front St. W. > > > > > > > -- > Brandon Galbraith > Mobile: 630.400.6992 > FNAL: 630.840.2141 > From jared at puck.nether.net Wed Dec 30 19:03:32 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 30 Dec 2009 14:03:32 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: References: Message-ID: On Dec 30, 2009, at 10:49 AM, Paul Bennett wrote: > Is it going to be a more-effective solution to drop a few bucks on the 2960 and go through the hassle of learning how to set it up (and then setting it up), or would I be better off putting a secured Linux distro (e.g. gentoo-hardened, or something) on the semi-spare PC and running the load-balancing via iproute2 and friends? Back at the Toronto NANOG I bumped into someone who had an interesting solution to the multihoming problem. What they had was a machine that would key/sequence the packets and send them out each connection (so if they had 2, it would send a copy out each). Whichever got there first, was decapsulated and forwarded on. Any duplicates/late packets were dropped. This meant that they would always have the speed of the fastest link for either up or down. They also had a method to load-share to bond the two (or more) links together. It was some custom solution they built, but something I would like to see a link to or open-sourced. - Jared From dhetzel at gmail.com Wed Dec 30 19:08:18 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Wed, 30 Dec 2009 14:08:18 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: References: Message-ID: <7db2dcf90912301108t7a6ba2f1ve59d845ce5797c5e@mail.gmail.com> On Wed, Dec 30, 2009 at 2:03 PM, Jared Mauch wrote: > > On Dec 30, 2009, at 10:49 AM, Paul Bennett wrote: > > > Is it going to be a more-effective solution to drop a few bucks on the > 2960 and go through the hassle of learning how to set it up (and then > setting it up), or would I be better off putting a secured Linux distro > (e.g. gentoo-hardened, or something) on the semi-spare PC and running the > load-balancing via iproute2 and friends? > > Back at the Toronto NANOG I bumped into someone who had an interesting > solution to the multihoming problem. > > What they had was a machine that would key/sequence the packets and send > them out each connection (so if they had 2, it would send a copy out each). > > Whichever got there first, was decapsulated and forwarded on. Any > duplicates/late packets were dropped. This meant that they would always > have the speed of the fastest link for either up or down. > > They also had a method to load-share to bond the two (or more) links > together. > > It was some custom solution they built, but something I would like to see a > link to or open-sourced. > > I guess that method presume some cooperating box out there on the net somewhere to coordinate the far end? > - Jared > From ip at ioshints.info Wed Dec 30 19:54:57 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 30 Dec 2009 20:54:57 +0100 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: References: Message-ID: <003301ca8989$f7954440$e6bfccc0$@info> > At home, I currently run two DSL lines. Right now, we just have two > separate LANs, one connected to each line, with my wife's devices attached > to one, and my devices attached to the other. For a while now, I've been > thinking about setting up a load-balancing routing solution to give both > of us access to both lines. If you decide to use an IOS-based router, you'll find most what you need here: http://wiki.nil.com/Small_site_multihoming Ivan Pepelnjak blog.ioshints.info / www.ioshints.info From math at sizone.org Wed Dec 30 20:35:36 2009 From: math at sizone.org (Ken Chase) Date: Wed, 30 Dec 2009 15:35:36 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <7db2dcf90912301108t7a6ba2f1ve59d845ce5797c5e@mail.gmail.com> References: <7db2dcf90912301108t7a6ba2f1ve59d845ce5797c5e@mail.gmail.com> Message-ID: <20091230203536.GS24092@sizone.org> >On Wed, Dec 30, 2009 at 2:03 PM, Jared Mauch wrote: >> Back at the Toronto NANOG I bumped into someone who had an interesting >> solution to the multihoming problem. >> >> What they had was a machine that would key/sequence the packets and send >> them out each connection (so if they had 2, it would send a copy out each). That's exactly what I was alluding to and you may have spoken to the person that wrote the tool I was thinking of, as that's pretty much what I described. (He and I both operate out of Toronto.) >> Whichever got there first, was decapsulated and forwarded on. Any >> duplicates/late packets were dropped. This meant that they would always >> have the speed of the fastest link for either up or down. With similar links (my allusion to low latency between the far ends of the upstreams across a local *IX), you really reduce jitter as well. Happy voip. I've used it, it works, just need to get it out there. Esp out here, for my voip because my latencies go up and down, so I'd rather have my packets go out twice and first one wins. (I've assisted with customers that have this service running today and have for a couple years, but I havent set it up locally here yet as I havent had a real need for reliability til I went all VOIP. I used to use plain mpppd across multi providers mainly for agg bw, but that's not nearly as good as this solution for reliability.) >> They also had a method to load-share to bond the two (or more) links >> together. As I mentioned, I think based on ToS or packet size. And can even pound through packetloss with duplicate packets down the same link (though I dont think that's implimented yet). >> It was some custom solution they built, but something I would like to see a >> link to or open-sourced. Still is and still hasnt been moved into a proper wide-deploy testing and marketing phase. I think it would be useful, but wanted to gauge your reaction. In fact, Im not sure what the next proper step in the whole endeavour is. If anyone is intersted in testing/using/assisting with marketing/selling it, contact me off list and Ill describe the particulars. Note it aint my tech, I just work closely with the developer. On Wed, Dec 30, 2009 at 02:08:18PM -0500, Dorn Hetzel said: >I guess that method presume some cooperating box out there on the net >somewhere to coordinate the far end? Also what I alluded to, you need a provider running the COE side of things (and if they go down you lose everything except your basic links, assuming the same one isnt responsible for both links). But we're looking at colo reliability for the COE - done right should be up into the mutli-9s. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jared at puck.nether.net Wed Dec 30 20:35:43 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 30 Dec 2009 15:35:43 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <7db2dcf90912301108t7a6ba2f1ve59d845ce5797c5e@mail.gmail.com> References: <7db2dcf90912301108t7a6ba2f1ve59d845ce5797c5e@mail.gmail.com> Message-ID: On Dec 30, 2009, at 2:08 PM, Dorn Hetzel wrote: > I guess that method presume some cooperating box out there on the net somewhere to coordinate the far end? > Yes. This allowed the provider to use a variety of different technologies to reach a site, eg: IP over CATV, DSL, Fiber, Wireless, etc with built-in backup. - Jared From mike at m5computersecurity.com Wed Dec 30 20:58:38 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Wed, 30 Dec 2009 12:58:38 -0800 Subject: InterNAP FCP (again?) Message-ID: <1262206718.6137.968.camel@mike-desktop> All, I know this has been discussed to some degree before and I have searched the archives. However is it seems in my previous posts to this list about anything, the truly useful replies are the private replies ones that don't make it to this list. We are considering the InterNAP Flow Control Platform. Currently we have 3 transit providers but are adding one or two more and will also be adding a connection to the Any2 exchange at One Wilshire. The price is manageable, the reporting seems quite useful, but I haven't seen it actually in action on my network. If it works as claimed for managing commit levels, performance, etc. then I expect we'd be very happy. The problem is that InterNAP does not want to do any acceptance testing... all sales are final... and in my research on the web, I see a few companies that have implemented the FCP and have either removed it or switched to Avaya CNA (yes, I know it's going away). Since InterNAP has pulled way from any kind of happiness guarantee, I'd very much like to hear from actual users of the FCP, happy and unhappy, to help me feel better about signing the PO. Does it do what it says it does for performance and managing commit levels? Do you feel it was worth the integration and money? Are you happy with it? What size and shape is the network you used it on? Do you have any additional thoughts to share regarding the FCP? Thanks! Mike -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From rmoseley at softlayer.com Wed Dec 30 21:17:19 2009 From: rmoseley at softlayer.com (Ric Moseley) Date: Wed, 30 Dec 2009 15:17:19 -0600 Subject: InterNAP FCP (again?) In-Reply-To: <1262206718.6137.968.camel@mike-desktop> References: <1262206718.6137.968.camel@mike-desktop> Message-ID: <98E72206041B1B408D3F92E91E80BF180766C393@slmail101.softlayer.local> Call me offline. Ric. 214-442-0555 -----Original Message----- From: Michael J McCafferty [mailto:mike at m5computersecurity.com] Sent: Wednesday, December 30, 2009 2:59 PM To: nanog Subject: InterNAP FCP (again?) All, I know this has been discussed to some degree before and I have searched the archives. However is it seems in my previous posts to this list about anything, the truly useful replies are the private replies ones that don't make it to this list. We are considering the InterNAP Flow Control Platform. Currently we have 3 transit providers but are adding one or two more and will also be adding a connection to the Any2 exchange at One Wilshire. The price is manageable, the reporting seems quite useful, but I haven't seen it actually in action on my network. If it works as claimed for managing commit levels, performance, etc. then I expect we'd be very happy. The problem is that InterNAP does not want to do any acceptance testing... all sales are final... and in my research on the web, I see a few companies that have implemented the FCP and have either removed it or switched to Avaya CNA (yes, I know it's going away). Since InterNAP has pulled way from any kind of happiness guarantee, I'd very much like to hear from actual users of the FCP, happy and unhappy, to help me feel better about signing the PO. Does it do what it says it does for performance and managing commit levels? Do you feel it was worth the integration and money? Are you happy with it? What size and shape is the network you used it on? Do you have any additional thoughts to share regarding the FCP? Thanks! Mike -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From williams.bruce at gmail.com Wed Dec 30 22:02:25 2009 From: williams.bruce at gmail.com (Bruce Williams) Date: Wed, 30 Dec 2009 14:02:25 -0800 Subject: RBN and it's spin-offs Message-ID: <775e001a0912301402h1fc005awc829e843e82276af@mail.gmail.com> Interesting article about RBN, it's spin-offs and the global network infrastructure used for cybercrime. Has a passing mention of Atrivo's place in the global picture. http://www.newsweek.com/id/228674 Reportedly started by someone operating under the name "Flyman," RBN is known as the mother of cybercrime among online investigators. Fran?ois Paget, senior expert for the McAfee company, says that RBN began as an Internet provider and offered "impenetrable" hosting for $600 a month. This meant a guarantee that it would not give out information about its clients, no matter what business they were in. Aleksandr Gostev, director of Kaspersky Labs, a global research and threat analysis center, believes that RBN's servers are located in Panama. "Confidential data about clients can be obtained only by a court decision," a Newsweek source familiar with the situation says. "But what court do you apply to if criminal ties are discovered? A Panamanian court?" -- Bruce Williams ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From kmedcalf at dessus.com Wed Dec 30 22:30:13 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 30 Dec 2009 17:30:13 -0500 Subject: RBN and it's spin-offs In-Reply-To: <775e001a0912301402h1fc005awc829e843e82276af@mail.gmail.com> Message-ID: <250cb16c0cf7e34cb28f86a1f41a92a5@mail.dessus.com> > Reportedly started by someone operating under the name "Flyman," RBN is > known as the mother of cybercrime among online investigators. Fran?ois > Paget, senior expert for the McAfee company, says that RBN began as an > Internet provider and offered "impenetrable" hosting for $600 a month. > This meant a guarantee that it would not give out information about > its clients, no matter what business they were in. This is a commendable position and one that should be the default for all businesses. Severe penalties (such as cutting out of the tongue or cutting off hands) should be dealt to anyone who releases private information without having first ensured that such disclosure is in accordance with a properly obtained court order issued by a competent court in a public hearing (and no, administrative tribunals are not courts of law). From rbf+nanog at panix.com Wed Dec 30 23:08:25 2009 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 30 Dec 2009 17:08:25 -0600 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <408FE52C-BF6A-4AA3-B30C-8E414948A932@cs.columbia.edu> References: <408FE52C-BF6A-4AA3-B30C-8E414948A932@cs.columbia.edu> Message-ID: <20091230230824.GA13442@panix.com> On Wed, Dec 30, 2009 at 11:13:24AM -0500, Steven Bellovin wrote: > > I know nothing of how to do this on a Catalyst; for PCs, my own guess > is that you're looking far too high-end. If the issue is relaying to > the outside, I suspect that a small, dedicated Soekris or the like > will do all you need -- there's no point in switching traffic faster > than your DSL lines can run. I'm not doing load-balancing, but all > traffic from my house to the outside world (I have a cable modem) > goes through a Soekris 4801, and I can download large files from my > office at 12-13M bps. Further, since the Soekris is bridging some > networks, its interfaces are in promiscuous mode, so the box is > seeing every packet on my home LAN. Really? If it's connected to a switch, I'd expect it to only see broadcast/multicast/unknown destination MACs, as well as traffic actually flowing through the Soekris. -- Brett From tvarriale at comcast.net Wed Dec 30 23:18:30 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 30 Dec 2009 17:18:30 -0600 Subject: just...wow. References: Message-ID: Would it be possible to string along and coordinate with the appropriate law enforcement entity? tv ----- Original Message ----- From: "Jerry Pasker" To: Sent: Wednesday, December 30, 2009 12:04 PM Subject: just...wow. >I got this email inquiring about data center space, from the most honest >scumbag, *EVER* today. Operational relevance? Well, if everyone would >turn these people down, we'd have a lot less problems to deal with. Sadly, >requests like these happen far too often, but never have I had someone come >right out and explain what they were doing up front like this without >having to dig in to it. > > Scumbag email: > ------------ > Hello, > > I need servers to host botnet controller. Botnet controller is software > that sends tasks to bots. Bots are hosts which send spam emails to > millions of addresses. It's not direct spam but abuses on botnet contoller > are received from time to time. What is your policy in case of receiving > abuses and what is your policy in case of receiving a lot of abuses? What > is policy about spam (not direct from your ips as I mentioned above)? Is > it possible to host botnet controller in your datacenter during long-term > time? > > Thank you. > -------------- > > The part that leaves me feeling good is that they do get abuse complaints > from time to time. There's hope. > From joelja at bogus.com Wed Dec 30 23:23:26 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 30 Dec 2009 15:23:26 -0800 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <20091230230824.GA13442@panix.com> References: <408FE52C-BF6A-4AA3-B30C-8E414948A932@cs.columbia.edu> <20091230230824.GA13442@panix.com> Message-ID: <4B3BE0EE.7090007@bogus.com> Brett Frankenberger wrote: > On Wed, Dec 30, 2009 at 11:13:24AM -0500, Steven Bellovin wrote: >> I know nothing of how to do this on a Catalyst; for PCs, my own guess >> is that you're looking far too high-end. If the issue is relaying to >> the outside, I suspect that a small, dedicated Soekris or the like >> will do all you need -- there's no point in switching traffic faster >> than your DSL lines can run. I'm not doing load-balancing, but all >> traffic from my house to the outside world (I have a cable modem) >> goes through a Soekris 4801, and I can download large files from my >> office at 12-13M bps. Further, since the Soekris is bridging some >> networks, its interfaces are in promiscuous mode, so the box is >> seeing every packet on my home LAN. > > Really? If it's connected to a switch, I'd expect it to only see > broadcast/multicast/unknown destination MACs, as well as traffic > actually flowing through the Soekris. I believe he's refering to the situation where the soekris is doing the bridging, since the soekris only has 4 ethernet ports and two pci slots max it's likely that if you need greater than quantity 3 plus wireless internal interfaces that you'll need a switch. given the performance limits of even a 5501 I tend to disagree that the switching traffic internally in software bridge at less than line rate at 100Mb/s is a great trade-off vs say using a cheapo gig-e switch. > -- Brett > From info at n-connect.net Wed Dec 30 23:57:27 2009 From: info at n-connect.net (Jerry Pasker) Date: Wed, 30 Dec 2009 17:57:27 -0600 Subject: just...wow. In-Reply-To: References: Message-ID: >Would it be possible to string along and coordinate with the >appropriate law enforcement entity? > >tv Probably, but the fourth basic law of human stupidity (google it, and have a laugh) promisees that I would suffer for doing so. It's why I've never ever attempted to deal with any of these types of requests beyond just figuring out what the game is. Once you know the game, any intelligent person quickly concludes that the only way to win at that game is to not play. From tvarriale at comcast.net Thu Dec 31 00:39:52 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 30 Dec 2009 18:39:52 -0600 Subject: just...wow. References: Message-ID: <7743FD85920D4BFFBFAD4BED3F501F3E@flamdt01> LOL! That was purty good and mostly true. Well, I was thinking from the standpoint of 1) They are going somewhere, maybe not you 2) breaking law(s) 3) someone has to intervene, eventually. You could apply the above to any crime really. And they essentially told you they are going to commit it...sort of like our recent plane story. I don't think it's a question of intelligence. It's more a question of risk and whether or not it fits your profile. If not, turn your head the other way and cough. :) tv ----- Original Message ----- From: "Jerry Pasker" To: Sent: Wednesday, December 30, 2009 5:57 PM Subject: Re: just...wow. > >Would it be possible to string along and coordinate with the appropriate > >law enforcement entity? >> >>tv > > Probably, but the fourth basic law of human stupidity (google it, and have > a laugh) promisees that I would suffer for doing so. It's why I've never > ever attempted to deal with any of these types of requests beyond just > figuring out what the game is. Once you know the game, any intelligent > person quickly concludes that the only way to win at that game is to not > play. > > From smb at cs.columbia.edu Thu Dec 31 01:07:50 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 30 Dec 2009 20:07:50 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <4B3BE0EE.7090007@bogus.com> References: <408FE52C-BF6A-4AA3-B30C-8E414948A932@cs.columbia.edu> <20091230230824.GA13442@panix.com> <4B3BE0EE.7090007@bogus.com> Message-ID: <5B7A2C78-D877-4627-80F6-69BB67BE5150@cs.columbia.edu> On Dec 30, 2009, at 6:23 PM, Joel Jaeggli wrote: > > > Brett Frankenberger wrote: >> On Wed, Dec 30, 2009 at 11:13:24AM -0500, Steven Bellovin wrote: >>> I know nothing of how to do this on a Catalyst; for PCs, my own guess >>> is that you're looking far too high-end. If the issue is relaying to >>> the outside, I suspect that a small, dedicated Soekris or the like >>> will do all you need -- there's no point in switching traffic faster >>> than your DSL lines can run. I'm not doing load-balancing, but all >>> traffic from my house to the outside world (I have a cable modem) >>> goes through a Soekris 4801, and I can download large files from my >>> office at 12-13M bps. Further, since the Soekris is bridging some >>> networks, its interfaces are in promiscuous mode, so the box is >>> seeing every packet on my home LAN. >> >> Really? If it's connected to a switch, I'd expect it to only see >> broadcast/multicast/unknown destination MACs, as well as traffic >> actually flowing through the Soekris. > > I believe he's refering to the situation where the soekris is doing the > bridging, since the soekris only has 4 ethernet ports and two pci slots > max it's likely that if you need greater than quantity 3 plus wireless > internal interfaces that you'll need a switch. given the performance > limits of even a 5501 I tend to disagree that the switching traffic > internally in software bridge at less than line rate at 100Mb/s is a > great trade-off vs say using a cheapo gig-e switch. Correct, except that my Soekris has only 3 100Mbps ports. My house is wired with COTS GigE switches. Outbound traffic passes through the Soekris, which bridges to an older 100M bps switch. That, in turn, is connected to the cable modem and a few older devices that don't need much bandwidth and only have 100baseT ports themselves, like a wireless access point and a printer. I have that setup for several reasons. First, I want a point from which I can monitor outbound traffic -- home "routers" and switches don't have monitoring ports. I wanted a DHCP server that supported static allocations. I contemplated (but never implemented) putting an IPsec gateway there; I still may do that. I'm about to move my IPv6 tunnel endpoint to the Soekris. I have contemplated multihoming my house, though I might conclude that that would incur too many spousal points. Finally, at one point I had a more complex topology for my home network -- certain locations in the house were separated, to permit imposition of restrictions for, shall we say, violations of the house AUP... --Steve Bellovin, http://www.cs.columbia.edu/~smb From randy at psg.com Thu Dec 31 02:11:54 2009 From: randy at psg.com (Randy Bush) Date: Thu, 31 Dec 2009 11:11:54 +0900 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <4B3BE0EE.7090007@bogus.com> References: <408FE52C-BF6A-4AA3-B30C-8E414948A932@cs.columbia.edu> <20091230230824.GA13442@panix.com> <4B3BE0EE.7090007@bogus.com> Message-ID: > I believe he's refering to the situation where the soekris is doing > the bridging, since the soekris only has 4 ethernet ports and two pci > slots max it's likely that if you need greater than quantity 3 plus > wireless internal interfaces that you'll need a switch. given the > performance limits of even a 5501 I tend to disagree that the > switching traffic internally in software bridge at less than line rate > at 100Mb/s is a great trade-off vs say using a cheapo gig-e switch. i am not sure this is the forum for home networking (in fact, i am pretty sure it's not), but wtf. i have a 5501 with 8g flash running freebsd 8.0 on a 100/100 b-flets looking kinda like .----------------. | | | b --wlan0| | r | 192.168.0.0/24 ext iij | i --- vr1| LAN hosts, PPP/NAT ---|vr0--- d | DHCP Clients WAN | g --- vr2| pptp 200-209 | e | ... | 0 --- vr3| | | `----------------' there is a gige switch on one of the vr ports, but i currently do not use it (lack of white gaffers' tape to hide cabling). my plan is to use it for ethers to the mac mini by the tv and the mbps on the desktops so that file transfers to/from the mini do not go through the soekris. randy From ops.lists at gmail.com Thu Dec 31 02:48:12 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Dec 2009 08:18:12 +0530 Subject: RBN and it's spin-offs In-Reply-To: <250cb16c0cf7e34cb28f86a1f41a92a5@mail.dessus.com> References: <775e001a0912301402h1fc005awc829e843e82276af@mail.gmail.com> <250cb16c0cf7e34cb28f86a1f41a92a5@mail.dessus.com> Message-ID: On Thu, Dec 31, 2009 at 4:00 AM, Keith Medcalf wrote: > >> Reportedly started by someone operating under the name "Flyman," RBN is >> known as the mother of cybercrime among online investigators. Fran?ois >> Paget, senior expert for the McAfee company, says that RBN began as an >> Internet provider and offered "impenetrable" hosting for $600 a month. >> This meant a guarantee that it would not give out information about >> its clients, no matter what business they were in. > > This is a commendable position and one that should be the default for all businesses. ?Severe penalties (such as cutting out of the tongue or cutting off hands) should be dealt to anyone who releases private information without having first ensured that such disclosure is in accordance with a properly obtained court order issued by a competent court in a public hearing (and no, administrative tribunals are not courts of law). > Wow. I always knew there existed some alternate universe where the RBN were actually the good guys. Didn't expect to find it so fast, and on nanog at that. -- Suresh Ramasubramanian (ops.lists at gmail.com) From kmedcalf at dessus.com Thu Dec 31 04:05:19 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 30 Dec 2009 23:05:19 -0500 Subject: RBN and it's spin-offs In-Reply-To: Message-ID: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> >>> Reportedly started by someone operating under the name >>> "Flyman," RBN is known as the mother of cybercrime among >>> online investigators. Fran?ois Paget, senior expert for >>> the McAfee company, says that RBN began as an Internet >>> provider and offered "impenetrable" hosting for $600 a >>> month. This meant a guarantee that it would not give >>> out information about its clients, no matter what >>> business they were in. >> This is a commendable position and one that should be the >> default for all businesses. ?Severe penalties (such as cutting >> out of the tongue or cutting off hands) should be dealt to >> anyone who releases private information without having first >> ensured that such disclosure is in accordance with a properly >> obtained court order issued by a competent court in a public >> hearing (and no, administrative tribunals are not courts of law). > Wow. I always knew there existed some alternate universe where the > RBN were actually the good guys. Didn't expect to find it so fast, > and on nanog at that. Wasn't it Larry Flynt that said: "Because if its good enough to protect a scumbag like me its sure darn good enough to protect all of you". Without a warrant, there is an absolute right to privacy. It continues to exist right up until either (a) one party chooses to give up that privacy or (b) a third party arrives with a Court Order. This is simply a covenant between two parties to preserve that "private" state unless lawfully compelled by lawful process otherwise. In other words, a covenant to adhere to the rule of law and the courts in the event of any dispute between the parties or any third party. It sure seems like a good thing to me -- and a covenant I would hope anyone I do business adheres to. -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From fergdawgster at gmail.com Thu Dec 31 04:12:11 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 30 Dec 2009 20:12:11 -0800 Subject: RBN and it's spin-offs In-Reply-To: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> Message-ID: <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 30, 2009 at 8:05 PM, Keith Medcalf wrote: > > Without a warrant, there is an absolute right to privacy. > It continues to exist right up until either (a) one party chooses > to give up that privacy or (b) a third party arrives with a Court > Order. This is simply a covenant between two parties to preserve > that "private" state unless lawfully compelled by lawful process > otherwise. In other words, a covenant to adhere to the rule of > law and the courts in the event of any dispute between the parties > or any third party. It sure seems like a good thing to me -- and a > covenant I would hope anyone I do business adheres to. > That's funny. You're assuming that the MLAT [1] process works -- it doesn't. - - ferg [1] http://en.wikipedia.org/wiki/Mutual_Legal_Assistance_Treaty -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPCSVq1pz9mNUZTMRAmtnAKCMrUkoeVmgHf+4z5/os5zfuVKLkwCgkE1G cq4Iv0qlUZD6V6/txAPoh3Q= =4RZt -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nenolod at systeminplace.net Thu Dec 31 04:13:45 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 30 Dec 2009 22:13:45 -0600 Subject: RBN and it's spin-offs In-Reply-To: <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> Message-ID: <1262232825.14004.45.camel@petrie> On Wed, 2009-12-30 at 20:12 -0800, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Dec 30, 2009 at 8:05 PM, Keith Medcalf wrote: > > > > > Without a warrant, there is an absolute right to privacy. > > It continues to exist right up until either (a) one party chooses > > to give up that privacy or (b) a third party arrives with a Court > > Order. This is simply a covenant between two parties to preserve > > that "private" state unless lawfully compelled by lawful process > > otherwise. In other words, a covenant to adhere to the rule of > > law and the courts in the event of any dispute between the parties > > or any third party. It sure seems like a good thing to me -- and a > > covenant I would hope anyone I do business adheres to. > > > > That's funny. > > You're assuming that the MLAT [1] process works -- it doesn't. It "worked" against Indymedia UK: http://www.indymedia.org/fbi/ William From ops.lists at gmail.com Thu Dec 31 04:14:39 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Dec 2009 09:44:39 +0530 Subject: RBN and it's spin-offs In-Reply-To: <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> Message-ID: Ferg nailed it. I'll shut up now as he's made my point and its new year's eve .. On Thu, Dec 31, 2009 at 9:42 AM, Paul Ferguson wrote: > > That's funny. > > You're assuming that the MLAT [1] process works -- it doesn't. > > - - ferg > > [1] http://en.wikipedia.org/wiki/Mutual_Legal_Assistance_Treaty -- Suresh Ramasubramanian (ops.lists at gmail.com) From curupas at gmail.com Thu Dec 31 04:16:29 2009 From: curupas at gmail.com (Ricardo Tavares) Date: Thu, 31 Dec 2009 02:16:29 -0200 Subject: RBN and it's spin-offs In-Reply-To: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> Message-ID: <670333fe0912302016r8a658e7ue56426483ade6f76@mail.gmail.com> Hey, I am not sure if this is the question asked in the first email. If I found a RBN fishing site, and ask RBN to shutdown the site, appears to me that this will not be done...so I need to block all the RBN cyber space, or initiate a fight for a warrant? I would prefer just block RBN sites... On Thu, Dec 31, 2009 at 2:05 AM, Keith Medcalf wrote: > > >>> Reportedly started by someone operating under the name > >>> "Flyman," RBN is known as the mother of cybercrime among > >>> online investigators. Fran?ois Paget, senior expert for > >>> the McAfee company, says that RBN began as an Internet > >>> provider and offered "impenetrable" hosting for $600 a > >>> month. This meant a guarantee that it would not give > >>> out information about its clients, no matter what > >>> business they were in. > > >> This is a commendable position and one that should be the > >> default for all businesses. Severe penalties (such as cutting > >> out of the tongue or cutting off hands) should be dealt to > >> anyone who releases private information without having first > >> ensured that such disclosure is in accordance with a properly > >> obtained court order issued by a competent court in a public > >> hearing (and no, administrative tribunals are not courts of law). > > > Wow. I always knew there existed some alternate universe where the > > RBN were actually the good guys. Didn't expect to find it so fast, > > and on nanog at that. > > Wasn't it Larry Flynt that said: "Because if its good enough to > protect a scumbag like me its sure darn good enough to protect > all of you". > > Without a warrant, there is an absolute right to privacy. > It continues to exist right up until either (a) one party chooses > to give up that privacy or (b) a third party arrives with a Court > Order. This is simply a covenant between two parties to preserve > that "private" state unless lawfully compelled by lawful process > otherwise. In other words, a covenant to adhere to the rule of > law and the courts in the event of any dispute between the parties > or any third party. It sure seems like a good thing to me -- and a > covenant I would hope anyone I do business adheres to. > > -- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > > From morrowc.lists at gmail.com Thu Dec 31 04:25:50 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 30 Dec 2009 23:25:50 -0500 Subject: RBN and it's spin-offs In-Reply-To: <1262232825.14004.45.camel@petrie> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <1262232825.14004.45.camel@petrie> Message-ID: <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> On Wed, Dec 30, 2009 at 11:13 PM, William Pitcock wrote: > It "worked" against Indymedia UK: http://www.indymedia.org/fbi/ indymedia is in texas, no mlat required. rbn was actually, for a good portion of their existence, in Russia (I believe St Petersburg, but my memory is fuzzy). -chris From vixie at isc.org Thu Dec 31 04:26:31 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 31 Dec 2009 04:26:31 +0000 Subject: Article on spammers and their infrastructure In-Reply-To: (Randy Bush's message of "Wed\, 30 Dec 2009 23\:42\:06 +0900") References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> Message-ID: Randy Bush writes: >> If ARIN and/or RIPE and/or ICANN and/or anyone else were truly >> interested in making a dent in the problem, then they would have already >> paid attention to our collective work product. > > the rirs, the ietf, the icann, ... each think they are the top of the > mountain. we are supposed to come to them and pray. more likely that > the itu will come to them and prey. ARIN (an RIR) does not think in terms of mountains. the staff and company does what members and the elected board and elected advisory council ask. ARIN is a 501(c)(6) and sticks to its knitting, which thus far means no distinguished role in "spammers and their infrastructure" but that could change if someone writes a policy proposal which is adopted after the normal policy development process. please do consider whether ARIN could help with "spammers and their infrastructure" and if so, write a policy draft to that effect. ARIN is responsive to community input, and has well established and well publicized mechanisms for receiving and processing community input. nobody has to come and pray, but likewise, nobody should expect ARIN to look for mission creep opportunities. ARIN will go on doing what the community asks, no less, no more. ARIN has no mechanism, as a company, for "[paying] attention to [your] collective work product". our members, and the public at large who participates in ARIN's policy development process, do that. -- Paul Vixie Chairman, ARIN BoT KI6YSY From fergdawgster at gmail.com Thu Dec 31 04:36:27 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 30 Dec 2009 20:36:27 -0800 Subject: RBN and it's spin-offs In-Reply-To: <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <1262232825.14004.45.camel@petrie> <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> Message-ID: <6cd462c00912302036v3ca7539fwef9e931c04f330c4@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 30, 2009 at 8:25 PM, Christopher Morrow wrote: > On Wed, Dec 30, 2009 at 11:13 PM, William Pitcock > wrote: > >> It "worked" against Indymedia UK: http://www.indymedia.org/fbi/ > > indymedia is in texas, no mlat required. > Exactly. > rbn was actually, for a good portion of their existence, in Russia (I > believe St Petersburg, but my memory is fuzzy). > Yes, their original "bullet-proof" hosting was located there [AS40989] until they received too much publicity, and then they "diversified" into hosting facilities all over the world. If anything, their criminal "partnerka" networks have grown and thrived, for the most part out of the reach of the "long arm of the law" enforcement, due to geopolitical issues, sheer protectionist corruption, and clever (albeit illegal) business practices. Brian Krebs at The Washington Post did an excellent job of reporting on the ongoing Russkrainian organized online criminal operations, et al: http://voices.washingtonpost.com/cgi-bin/mt/mt-search.cgi?search=russian+bu siness+network&blog_id=66&MaxResults=100 ...but as of the first of the year, alas, Krebs is no longer working for WaPo: http://voices.washingtonpost.com/securityfix/2009/12/farewell_2009_and_the_ washingt.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPCpEq1pz9mNUZTMRAk9DAKCvwK5ZhVu/n1jBX9rcsFpG3uYmFQCdE5C7 eYDC7w8NXWD+0xJ9SpcR+xw= =l7A1 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nenolod at systeminplace.net Thu Dec 31 04:36:29 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 30 Dec 2009 22:36:29 -0600 Subject: RBN and it's spin-offs In-Reply-To: <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <1262232825.14004.45.camel@petrie> <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> Message-ID: <1262234189.14004.47.camel@petrie> On Wed, 2009-12-30 at 23:25 -0500, Christopher Morrow wrote: > On Wed, Dec 30, 2009 at 11:13 PM, William Pitcock > wrote: > > > It "worked" against Indymedia UK: http://www.indymedia.org/fbi/ > > indymedia is in texas, no mlat required. It was an MLAT initiated by the Dutch government because someone posted pictures of a Dutch policeman breaking the law that they wanted removed. Yes, the M in MLAT stands for *Mutual*. As in, it goes both ways. William From fergdawgster at gmail.com Thu Dec 31 04:42:56 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 30 Dec 2009 20:42:56 -0800 Subject: RBN and it's spin-offs In-Reply-To: <1262234189.14004.47.camel@petrie> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <1262232825.14004.45.camel@petrie> <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> <1262234189.14004.47.camel@petrie> Message-ID: <6cd462c00912302042y1e2955a2k99b20f1b41ac6bd@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 30, 2009 at 8:36 PM, William Pitcock wrote: > On Wed, 2009-12-30 at 23:25 -0500, Christopher Morrow wrote: >> On Wed, Dec 30, 2009 at 11:13 PM, William Pitcock >> wrote: >> >> > It "worked" against Indymedia UK: http://www.indymedia.org/fbi/ >> >> indymedia is in texas, no mlat required. > > It was an MLAT initiated by the Dutch government because someone posted > pictures of a Dutch policeman breaking the law that they wanted removed. > > Yes, the M in MLAT stands for *Mutual*. As in, it goes both ways. > The IndyMedia incident illustrates the problem, in my opinion -- going after child's play instead of hardcore criminals. Que Sera... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPCvKq1pz9mNUZTMRAtw+AKCYeFfcDgVjV+ORdarSX14s9+u5AACfQYFw L2ADUqhnIdTcTqFPGy6L+KE= =OpnR -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fred at cisco.com Thu Dec 31 05:06:18 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 30 Dec 2009 21:06:18 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> Message-ID: One might say the same about the IETF, which Randy likes to lampoon. Not sure how it comes up in this context, as (as Randy loves to remind us) while many operators attend, it is not first-and-foremost an operational community. As to ICANN, I think Rich may be talking about the registries and registrars for their DNS names, but not the agency that coordinates them. At most, ICANN can give them suggestions. And as for addresses, they get them from their local ISPs. What ICANN and many of the registries have in fact done is make an issue of domain name "tasting", which is a means by which some forms of abusers change names rapidly to evade filters. That is a matter of having the fox guard the henhouse, however; the registries make money on names being sold, and "tasting" is a means of making a lot of sales. So while some have good efforts there, not all are motivated to fight abuse. As to addresses, we can point to at least one entire ISP shut down as most of the traffic coming from it was abusive. But for ISPs, it becomes at least in part a matter of the amount of trouble they cause their immediate neighbors. If they can link to other ISPs, who they sell their services too is somewhat opaque to the wider world. And since the abusers are not above "owning" systems, every network has some subset of its subscribers to think about. I agree with your sentiment, Rich, and empathize with your frustration. Writing comments in blogs doesn't get the hard work of tools and policy done, though. You have to take the next step. On Dec 30, 2009, at 8:26 PM, Paul Vixie wrote: > Randy Bush writes: >>> If ARIN and/or RIPE and/or ICANN and/or anyone else were truly >>> interested in making a dent in the problem, then they would have >>> already >>> paid attention to our collective work product. >> >> the rirs, the ietf, the icann, ... each think they are the top of the >> mountain. we are supposed to come to them and pray. more likely >> that >> the itu will come to them and prey. > > ARIN (an RIR) does not think in terms of mountains. the staff and > company > does what members and the elected board and elected advisory council > ask. > ARIN is a 501(c)(6) and sticks to its knitting, which thus far means > no > distinguished role in "spammers and their infrastructure" but that > could > change if someone writes a policy proposal which is adopted after the > normal policy development process. > > please do consider whether ARIN could help with "spammers and their > infrastructure" and if so, write a policy draft to that effect. > ARIN is > responsive to community input, and has well established and well > publicized > mechanisms for receiving and processing community input. nobody has > to > come and pray, but likewise, nobody should expect ARIN to look for > mission > creep opportunities. ARIN will go on doing what the community asks, > no > less, no more. ARIN has no mechanism, as a company, for "[paying] > attention to [your] collective work product". our members, and the > public > at large who participates in ARIN's policy development process, do > that. > -- > Paul Vixie > Chairman, ARIN BoT > KI6YSY > http://www.ipinc.net/IPv4.GIF From fergdawgster at gmail.com Thu Dec 31 05:15:12 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 30 Dec 2009 21:15:12 -0800 Subject: RBN and it's spin-offs In-Reply-To: <6cd462c00912302042y1e2955a2k99b20f1b41ac6bd@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <1262232825.14004.45.camel@petrie> <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> <1262234189.14004.47.camel@petrie> <6cd462c00912302042y1e2955a2k99b20f1b41ac6bd@mail.gmail.com> Message-ID: <6cd462c00912302115x1442f6act4f6bf09537b6fa0b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 30, 2009 at 8:42 PM, Paul Ferguson wrote: > > On Wed, Dec 30, 2009 at 8:36 PM, William Pitcock > wrote: > >> On Wed, 2009-12-30 at 23:25 -0500, Christopher Morrow wrote: >>> On Wed, Dec 30, 2009 at 11:13 PM, William Pitcock >>> wrote: >>> >>> > It "worked" against Indymedia UK: http://www.indymedia.org/fbi/ >>> >>> indymedia is in texas, no mlat required. >> >> It was an MLAT initiated by the Dutch government because someone posted >> pictures of a Dutch policeman breaking the law that they wanted removed. >> >> Yes, the M in MLAT stands for *Mutual*. As in, it goes both ways. >> > > The IndyMedia incident illustrates the problem, in my opinion -- going > after child's play instead of hardcore criminals. > > Que Sera... > I apologize for deviating from the original issue at hand -- which I almost forgot. :-) And (I believe) it had something to do with something along the lines of (paraphrased) "What are ISPs supposed to do about $WHATEVER activities within their realm of responsibility?" -- where $WHATEVER could be spammers, criminal malware purveyors, or something else equally illegal. I would suggest following the lead of two other ISPs who have found themselves in similar positions in the past -- Hurricane Electric and GLBX - -- that, when presented with hard, documented evidence of criminal activity, disconnected downstream parties for violating their Term of Service agreements. You don't always have to have a Fed knocking on your door with a subpoena to do The Right Thing. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPDNbq1pz9mNUZTMRAhlZAKD0AkSTnva4PCaMo1fawaid/aGfKgCg1qwG 7kiDiuflc4X6xeYJDBU4eYQ= =+kNv -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From tomb at byrneit.net Thu Dec 31 05:47:18 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 30 Dec 2009 21:47:18 -0800 Subject: RBN and it's spin-offs In-Reply-To: <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> Message-ID: <72F9A69DCF990443B2CEC064E605CE062606@Pascal.zaphodb.org> He's also assuming that US on-shore law applies, which it doesn't when any one party is a non-US person, at which point it passes to the real of National Security. -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Wednesday, December 30, 2009 8:12 PM To: Keith Medcalf Cc: nanog at nanog.org Subject: Re: RBN and it's spin-offs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 30, 2009 at 8:05 PM, Keith Medcalf wrote: > > Without a warrant, there is an absolute right to privacy. > It continues to exist right up until either (a) one party chooses > to give up that privacy or (b) a third party arrives with a Court > Order. This is simply a covenant between two parties to preserve > that "private" state unless lawfully compelled by lawful process > otherwise. In other words, a covenant to adhere to the rule of > law and the courts in the event of any dispute between the parties > or any third party. It sure seems like a good thing to me -- and a > covenant I would hope anyone I do business adheres to. > That's funny. You're assuming that the MLAT [1] process works -- it doesn't. - - ferg [1] http://en.wikipedia.org/wiki/Mutual_Legal_Assistance_Treaty -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPCSVq1pz9mNUZTMRAmtnAKCMrUkoeVmgHf+4z5/os5zfuVKLkwCgkE1G cq4Iv0qlUZD6V6/txAPoh3Q= =4RZt -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Thu Dec 31 05:58:58 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 30 Dec 2009 21:58:58 -0800 Subject: RBN and it's spin-offs In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062606@Pascal.zaphodb.org> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <72F9A69DCF990443B2CEC064E605CE062606@Pascal.zaphodb.org> Message-ID: <6cd462c00912302158j201979c9w59deae9729746ee7@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 30, 2009 at 9:47 PM, Tomas L. Byrnes wrote: > > That's funny. > > You're assuming that the MLAT [1] process works -- it doesn't. > > He's also assuming that US on-shore law applies, which it doesn't when > any one party is a non-US person, at which point it passes to the real > of National Security. > Well, that's another issue entirely, but you are right. :-) Unfortunately, folks in charge of "national security" with regards to cyber issues don't realize that if that they can't stop sophisticated Eastern European criminals from their ongoing pillage & plunder, they will *never* stop determined attempts at critical infrastructure, espionage, etc., because they will simply use similar techniques. This is serious stuff, and it is so damned pervasive, and happening right in plain sight. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPD2eq1pz9mNUZTMRAq7iAKCLDdKPRBp1EkrkIcQRG04pJZwmqgCfSA2k jmEF+raHPkEGUsp6n5ZfgoI= =UVPA -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fred at cisco.com Thu Dec 31 08:08:18 2009 From: fred at cisco.com (Fred Baker) Date: Thu, 31 Dec 2009 00:08:18 -0800 Subject: ip-precedence for management traffic In-Reply-To: <1262084530.4236.7.camel@localhost> References: <1262084530.4236.7.camel@localhost> Message-ID: <10C961EF-7DE3-4D4B-8432-193F2F08F3BF@cisco.com> RFC 4594 would suggest using DSCP CS2 (010000xx in the TOS byte; xx is the ECN flags). Section 3.1 discusses the issues with CS7, which is the DSCP counterpart to the deprecated IP Precedence 7. RFCs 2474/2475 discuss the Differentiated Services Architecture and its implementation. http://www.ietf.org/rfc/rfc4594.txt 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc2474.txt 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998. (Format: TXT=50576 bytes) (Obsoletes RFC1455, RFC1349) (Updated by RFC3168, RFC3260) (Status: PROPOSED STANDARD) http://www.ietf.org/rfc/rfc2475.txt 2475 An Architecture for Differentiated Service. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: TXT=94786 bytes) (Updated by RFC3260) (Status: INFORMATIONAL) On Dec 29, 2009, at 3:02 AM, Luca Tosolini wrote: > Experts, > what is the general opinion of using ipp 7 'network control' for > management traffic like: telnet ssh snmp ..... > > The idea is that ipp 0 1 2 3 4 5 are used for user traffic > ipp = 6 is used by default by routing protocols like BGP, OSPF, > LDP ... > > this leaves out only ipp 7 for management traffic, on the premise that > routing and management should not share the same queue and > resources..... > > Thanks, > Luca. > > http://www.ipinc.net/IPv4.GIF From fergdawgster at gmail.com Thu Dec 31 08:15:25 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 31 Dec 2009 00:15:25 -0800 Subject: ip-precedence for management traffic In-Reply-To: <10C961EF-7DE3-4D4B-8432-193F2F08F3BF@cisco.com> References: <1262084530.4236.7.camel@localhost> <10C961EF-7DE3-4D4B-8432-193F2F08F3BF@cisco.com> Message-ID: <6cd462c00912310015q5ef20d4av2ebb66d6bdef6d65@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Dec 31, 2009 at 12:08 AM, Fred Baker wrote: > RFC 4594 would suggest using DSCP CS2 (010000xx in the TOS byte; xx is > the ECN flags). Section 3.1 discusses the issues with CS7, which is the > DSCP counterpart to the deprecated IP Precedence 7. RFCs 2474/2475 > discuss the Differentiated Services Architecture and its implementation. > > http://www.ietf.org/rfc/rfc4594.txt > 4594 Configuration Guidelines for DiffServ Service Classes. J. > Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes) > (Status: INFORMATIONAL) > > http://www.ietf.org/rfc/rfc2474.txt > 2474 Definition of the Differentiated Services Field (DS Field) in the > IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. > December 1998. (Format: TXT=50576 bytes) (Obsoletes RFC1455, RFC1349) > (Updated by RFC3168, RFC3260) (Status: PROPOSED STANDARD) > > http://www.ietf.org/rfc/rfc2475.txt > 2475 An Architecture for Differentiated Service. S. Blake, D. Black, > M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: > TXT=94786 bytes) (Updated by RFC3260) (Status: INFORMATIONAL) > I feel compelled to say that once a packet leaves you administrative control, all bets are off, of course. IP Precedence flagging is not an honored "bit" in The Internet. Of course, if you own the end-to-end path, anything is possible. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPF2Yq1pz9mNUZTMRAhv/AKCNk2WiQt+zhO3o9EI/aOR2IMgvzwCgwSkQ ueQBckYm/1cTx5/atLaFd0A= =ooNM -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From Even.Endresen at bkk.no Thu Dec 31 08:40:42 2009 From: Even.Endresen at bkk.no (Endresen Even) Date: Thu, 31 Dec 2009 09:40:42 +0100 Subject: Restrictions on Ethernet L2 circuits? Message-ID: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Hello, Anyone with opinions on what restrictions a service provider should and should not impose on Ethernet L2 circuits provided to business customers wanting to connect several offices? The service provider's MPLS core network doesn't mind what traffic flows through the EoMPLS tunnel, but the L2 access network do mind and can be vulnerable to several layer 2 issues. Broadcast storm control and BPDU filter will protect the access network to a certain degree, but there are still potential layer 2 problems that can affect the switches, for example MAC address spoofing/flooding. Not to mention potentially difficult troubleshooting if a business customer connects two large LANs through the ISP's Ethernet layer 2 circuit, and then experience some occult layer 2 problem. Should business customers expect to be able to connect several LANs through an Ethernet L2 ciruit and build a layer 2 network spanning several locations? Or should the service provider implement port security and limit the number of MAC addresses on the access ports, forcing the customer to connect a router in both ends and segment their network? Also, do you see a demand for multi-point layer 2 networks (requiring VPLS), or are point-to-point layer 2 circuits sufficient to meet market demand? The most important argument for customers that choose Ethernet L2 over MPLS IP-VPN is that they want full control over their routing, they don't want the involvement from the service provider. Some customers also argue that a flat layer 2 network spanning several locations is a simpler and better design for them, and they don't want the "hassle" with routers and network segmentation. But IMO the customer (and the service provider) is far better off by segmenting their network in the vast majority of cases. What do you think? Regards, Even ___________________________________________________ This message and any attachment is intended for the person(s) named above only. It may contain information that is confidential or legally privileged. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank You. This footnote confirms that the email and attachment(s) has been swept by our anti-virus solution for the presence of known computer viruses. From nils.kolstein at sscplus.nl Thu Dec 31 09:34:40 2009 From: nils.kolstein at sscplus.nl (Nils Kolstein) Date: Thu, 31 Dec 2009 10:34:40 +0100 (CET) Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Message-ID: <1174631558.523411262252080294.JavaMail.root@webmail> ----- "Endresen Even" schreef: > Hello, > > Anyone with opinions on what restrictions a service provider should > and > should not impose on Ethernet L2 circuits provided to business > customers > wanting to connect several offices? Although different in concept, but somehwat similair in issues regarding L2, this description from the Amsterdam IX can give some pointers as to which issues need or can be adressed to minimize L2 issues. See: http://www.ams-ix.net/specifications-descriptions/ Regards, Nils Kolstein SSCPlus B.V. From Andrew.Claybaugh at securian.com Thu Dec 31 09:51:07 2009 From: Andrew.Claybaugh at securian.com (Andrew.Claybaugh at securian.com) Date: Thu, 31 Dec 2009 03:51:07 -0600 Subject: Out of the office Message-ID: I will be out of the office starting 12/30/2009 and will not return until 01/04/2010. If you need immediate assistance please call TechSupport at 651-665-5000. From xaerni at pop.ch Thu Dec 31 10:55:42 2009 From: xaerni at pop.ch (Xaver Aerni) Date: Thu, 31 Dec 2009 11:55:42 +0100 Subject: Are the Servers of Spamhaus.rg and blackholes.us down? Message-ID: <000001ca8a07$cc3749a0$8262d15b@Asus> Hello, Are this Blacklistservers since x-mas down. We receive in the last days many errors from this servers... Exemple enclosed Anonymsed. Greeting Xaver Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.cn-kr.blackholes.us/A' (in 'cn-kr.blackholes.us'?): disabling EDNS Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.korea.blackholes.us/A' (in 'korea.blackholes.us'?): disabling EDNS Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.china.blackholes.us/A' (in 'china.blackholes.us'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.cn-kr.blackholes.us/A' (in 'cn-kr.blackholes.us'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.korea.blackholes.us/A' (in 'korea.blackholes.us'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.china.blackholes.us/A' (in 'china.blackholes.us'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.sbl.spamhaus.org/A' (in 'sbl.spamhaus.org'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.sbl.spamhaus.org/A' (in 'sbl.spamhaus.org'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.sbl.spamhaus.org/A' (in 'sbl.spamhaus.org'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving 'XXX.sbl.spamhaus.org/A' (in 'sbl.spamhaus.org'?): disabling EDNS D ********************************************** Xaver Aerni Z?richstrasse 10a 8340 Hinwil Tel. 001 707 361 68 39 From raymond at prolocation.net Thu Dec 31 11:28:41 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 31 Dec 2009 12:28:41 +0100 (CET) Subject: Are the Servers of Spamhaus.rg and blackholes.us down? In-Reply-To: <000001ca8a07$cc3749a0$8262d15b@Asus> References: <000001ca8a07$cc3749a0$8262d15b@Asus> Message-ID: Hi! > Are this Blacklistservers since x-mas down. We receive in the last days many > errors from this servers... > Exemple enclosed Anonymsed. > Greeting > Xaver > > Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving > 'XXX.cn-kr.blackholes.us/A' (in 'cn-kr.blackholes.us'?): disabling EDNS > Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving > 'XXX.korea.blackholes.us/A' (in 'korea.blackholes.us'?): disabling EDNS > Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving > 'XXX.china.blackholes.us/A' (in 'china.blackholes.us'?): disabling EDNS > Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving Is your queuery volume not too high so they simply blocked your servers? Bye, Raymond. From john-nanog at johnpeach.com Thu Dec 31 13:11:24 2009 From: john-nanog at johnpeach.com (John Peach) Date: Thu, 31 Dec 2009 08:11:24 -0500 Subject: Are the Servers of Spamhaus.rg and blackholes.us down? In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> Message-ID: <20091231081124.18fa9f53@jpeach-desktop.1425mad.mountsinai.org> On Thu, 31 Dec 2009 12:28:41 +0100 (CET) Raymond Dijkxhoorn wrote: > Hi! > > > Are this Blacklistservers since x-mas down. We receive in the last > > days many errors from this servers... > > > Exemple enclosed Anonymsed. > > Greeting > > Xaver > > > > Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving > > 'XXX.cn-kr.blackholes.us/A' (in 'cn-kr.blackholes.us'?): disabling > > EDNS Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts > > resolving 'XXX.korea.blackholes.us/A' (in 'korea.blackholes.us'?): > > disabling EDNS Dec 31 10:12:37 linux-1ij2 named[14306]: too many > > timeouts resolving 'XXX.china.blackholes.us/A' (in > > 'china.blackholes.us'?): disabling EDNS Dec 31 10:12:38 linux-1ij2 > > named[14306]: too many timeouts resolving > > Is your queuery volume not too high so they simply blocked your > servers? blackholes.us has been non-existent for over a year. Their netblocks were re-allocated and the new owners were getting extremely upset over people trying to resolve yyy.blackholes.us against their servers. Looks like it now returns NXDOMAIN. Can't help you with spamhaus... -- John From jshearer at amedisys.com Thu Dec 31 14:00:20 2009 From: jshearer at amedisys.com (Jason Shearer) Date: Thu, 31 Dec 2009 08:00:20 -0600 Subject: question regarding multi-homing In-Reply-To: <3c3e3fca0912301025p22816282jbb6b1a857817aaa1@mail.gmail.com> References: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com><3c 3e3fca0912301025p22816282jbb6b1a857817aaa1@mail.gmail.com> Message-ID: >>Link up, receiving all routes but provider stops propagating your announcement outward. Longer AS path prepending on your secondary connection should take care of this, eh? Might end up with asymmetric routing but better than no traffic being returned. >>Link up but unusably high packet loss to some or all destinations. Assuming Cisco hardware what is the best way to handle this? Setup some IP SLA and bind them to a tracking objects? Use EEM and TCL scripting? Thanks! Jason -----Original Message----- From: William Herrin [mailto:herrin-nanog at dirtside.com] Sent: Wednesday, December 30, 2009 12:25 PM To: Simon Chen Cc: nanog at nanog.org Subject: Re: question regarding multi-homing On Wed, Dec 30, 2009 at 12:02 PM, Simon Chen wrote: > I have a question regarding multi-homing, mostly from stub network's > operational point of view. My big question is: what kind of failures > do you usually see from your providers? Link down? Link up, but > withdraw some routes? Link up, no route change, but blackholing > partial or all traffic? Anything else? Two more failure modes: Link up, receiving all routes but provider stops propagating your announcement outward. Link up but unusably high packet loss to some or all destinations. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. *** From jason at i6ix.com Thu Dec 31 14:22:12 2009 From: jason at i6ix.com (Jason Bertoch) Date: Thu, 31 Dec 2009 09:22:12 -0500 Subject: Are the Servers of Spamhaus.rg and blackholes.us down? In-Reply-To: <000001ca8a07$cc3749a0$8262d15b@Asus> References: <000001ca8a07$cc3749a0$8262d15b@Asus> Message-ID: <4B3CB394.6010604@i6ix.com> Xaver Aerni wrote: > > Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving > 'XXX.YYY.ZZZ/A' (in 'YYY.ZZZ'?): disabling EDNS Do you have a firewall in front of this server that limits DNS packets to 512 bytes? From simon.leinen at switch.ch Thu Dec 31 16:29:11 2009 From: simon.leinen at switch.ch (Simon Leinen) Date: Thu, 31 Dec 2009 17:29:11 +0100 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> (Endresen Even's message of "Thu, 31 Dec 2009 09:40:42 +0100") References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Message-ID: Interesting questions. Here are a few thoughts from the perspective of an education/research backbone operator that used to be IP only but has also been offering L2 point-to-point circuits for a few years. > Should business customers expect to be able to connect several LANs > through an Ethernet L2 ciruit and build a layer 2 network spanning > several locations? At least for our customers, that is indeed important. The most popular application here is for a customer to connect a remote location to their campus network, and that want to (at least be able to) use any of their existing VLANs at the remote site. > Or should the service provider implement port security and limit the > number of MAC addresses on the access ports, forcing the customer to > connect a router in both ends and segment their network? That would make the service less attractive, and also more complex to set up and maintain. For point-to-point service, there is really no reason for the network to care about customers' MAC addresses, VLAN tags and such. As you said, EoMPLS doesn't care. (Ethernet over L2TPv3 shouldn't care either. If I had cost-effective edge routers that did L2TPv3 encapsulation/decapsulation at line rate, I'd switch off MPLS in our core tomorrow.) Couldn't PBB or even Q-in-Q provide that isolation as well, at least for point-to-point services? I must say that I don't personally have much experience with those, because we tend to connect our customers to EoMPLS-capable routers directly. > Also, do you see a demand for multi-point layer 2 networks (requiring > VPLS), or are point-to-point layer 2 circuits sufficient to meet > market demand? That's a big question for us right now... we're not sure yet. I'd like to hear others' opinions on this. > The most important argument for customers that choose Ethernet L2 over > MPLS IP-VPN is that they want full control over their routing, they > don't want the involvement from the service provider. Some customers > also argue that a flat layer 2 network spanning several locations is a > simpler and better design for them, and they don't want the "hassle" > with routers and network segmentation. I have a good deal of sympathy for customers who think this way. Also from the service provider point of view, I like the simplicity of the offering - basically we're providing an emulation of a very long piece of Ethernet cable. (My worry with multipoint L2 VPNs is that they can't have such a simple service model.) > But IMO the customer (and the service provider) is far better off by > segmenting their network in the vast majority of cases. What do you > think? Maybe they already have a segmented network, but don't want to segment it based on geography/topology. As far as I'm concerned, enterprises should just connect their various sites to the Internet independently, and use VPN techniques if and where necessary to provide the illusion of a unified network. In practice, this illusion of a single large LAN (or rather, multiple organization-wide LANs) is very important to the typical enterprise, because so much security policy is enforced based on IP addresses. And the typical enterprise wants a central chokepoint that all traffic must go through, for reasons that might have to do with security, or support costs, or with (illusions of) control. This bridging function required to maintain the illusion of a unified network is something that most enterprises prefer to outsource. I'd hope that at some point, better security mechanisms and/or better VPN technologies make these kinds of VPN services less relevant. Until that happens, there's going to be demand for them. Of course the telcos have known that for eons and provided many generations of expensive and hard-to-use services to address this. Point-to-point Ethernet services are interesting because they are relatively easy to provide for folks like us who only really know IP (and maybe some MPLS). And the more transparent they are, the easier it is for customers to use them. -- Simon. From brunner at nic-naa.net Thu Dec 31 16:32:20 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 31 Dec 2009 11:32:20 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> Message-ID: <4B3CD214.30101@nic-naa.net> At the Montevideo ICANN meeting, in August, 2001, I was surprised, and disapointed, that the ISP Constituency had reduced to ... a couple of IP attorneys. So, as a point of departure, were one going to advocate policy which affects ISPs as ISPs, as opposed to ISPs as trademark portfolio managers, one would first have to, as Shakespeare put it, kill all the lawyers. Well, perhaps it would be sufficient to inform the lawyers the ISPs do send, who are nice enough people, that ISPs have operational issues other than protecting their brand portfolios. At the Paris meeting two years ago there was a charming presentation on GNSO constituency voting behavior, which showed that on the order of all the time less noise, the ISP Constituency, voted indistinguishably from the Intellectual Property Constituency. Of course, the same result was shown for the Business Constituency, but there I wouldn't bother to inform the incumbents of the end of their tenure, should real business ever take an interest in policy formation at ICANN. I agree with Fred, IETF has use case requirements such as providing competitors with a means to create standards without risk of competition policy complications, as well as more benign requirements that fit on the backs of tee shirts. Where the chain of delegation Paul mentions, by way of inviting NANOG contributors to do more than suggest ARIN do something, of addresses, and the chain of delegation Fred mentions, commenting on registries, registrars, and the Add Grace Period (AGP) exploit (aka "domain tasting"), or domains, share an anchor is in the IANA function. I've mentioned this previously, the delegation of trust down the BGP bunny trail and the delegation of trust down the DNS bunny trail, are an area where delegation of trust, as a policy issue, is common to both the numbers and the names operators. The back of the envelope for the AGP exploit is that it contributed a substantial part of the 35,000,000 monitized domains registrations. With that assumption, and using the dominant pricing (.COM), this means on the order of $6 to the registries and their operators, on the order of $1 to the registrars, and on the order of $0.20 to ICANN. That is $100m to COM/NET/ORG (VGRS and PIR/Afilias), and $35m to eNom, Moniker, Directi, ... and $6m to ICANN, per year, recurring, for quite a few years to come. NOTE WELL: As a registry operator CORE does not allow, and as a registrar, CORE does not pursue AGP exploits. Where Fred errs is in characterizing the AGP exploit as a means to provide operational agility to spammers. Of course it was used that way, but the entire point of agility is not avoiding a $6 cost of asset, it is having an asset that for some number of weeks, recently days, now hours, which allows each particular exploit to meet its ROI goals. The overwhelming use case for the AGP exploit was to acquire static, recurring revenue resources, monitized by advertizing, and a mature market in these assets exists. Greater agility arises from flux and double flux, exploits of the rapid update property Paul, and I, commented on back in August 2004. In a nutshell, domainers need low cost means to discover low marginal cost to acquire strings exceeding some low multiple of $6/year gross recurring revenue. Spammers (and other rational economic actors, e.g., the Conficker .C rendezvous mechanism author(s)) create value in excess of some low multiple of $6/day non-recurring revenue through arbitrary string registration. Domainers are not the same as spammers, and I've written a draft section here (http://wampum.wabanaki.net/vault/2009/12/005462.html, a contribution to a Bolt techlaw paper in progress) that there is at least one frame of reference other than trademark interest to view domain name speculation as harmful to public policy goals, in particular, IPv4 address exhaustion. I'd be grateful for informed comments on that note. It does take more than writing blog posts, and outcomes are not a given. I am, at year's end, very disappointed in the registries as a constituency, and very disappointed in the registrars as a constituency, and profoundly concerned that the ICANN Board has been successfully mobbed by domainers moving up the food chain to registry applicants. This will either mean "four eyes and more" on deltas to the IANA root become a thing of the past, or applications like the Catalan application in 2004 will be served after the last monitization exploit, and the last brand name, has been stuffed into the anything-for-a-dollar-or-a-laugh root. The only thing remotely "good" to come out of ICANN is bidi (Arabic and Hebew scripts) and Cyrillic and CJK strings, as a presentation layer hack (IDNAbis), as TLDs, enabling root-to-leaf script consistency, for some 40 ccTLD operators and their user bases. The bulk of the 100 or so non-shell registrars [1] were not AGP exploiters, and the CAT, COOP, and MUSEUM registries and their operators, do not pursue secondary revenue exploits. Randy suggests the ITU may prey on ICANN. I'm sorry to say that I see more likelihood of failure of the mostly private system now then I did prior to the transition from the MoU to the AoJ regimes, though not because of any change innate to these as legal regimes, but through institutional capture by private interest, naturally excluding addressing and protocol interests, and unrelated, the executive, Board and some staff preference for large for-profit corporations, possibly linked to status and individual career choices. My New Year's resolution is to spend the first week of the year coding, and to pick up my old OSF RI work, mk++, like knitting, as therapy. Eric CTO, CORE IANA Registrar ID 15 http://iana.org/assignments/registrar-ids/registrar-ids.xhtml operator, .CAT http://iana.org/reports/2005/cat-report-18nov2005.html operator, .MUSEUM http://iana.org/reports/2001/museum-report-30oct01.html [1] shell registrars exist for another exploit, to maximize race contention results for the VGRS drop pool, the acquisition of expired names which have "name" value or residual traffic monitization value. Four companies control 318 US domiciled ICANN accreditations: eNom (116), Directi/PDR (47), Dotster (51), and Snapnames (104). Source: http://www.knujon.com/registrars/ On 12/31/09 12:06 AM, Fred Baker wrote: > One might say the same about the IETF, which Randy likes to lampoon. > Not sure how it comes up in this context, as (as Randy loves to remind > us) while many operators attend, it is not first-and-foremost an > operational community. As to ICANN, I think Rich may be talking about > the registries and registrars for their DNS names, but not the agency > that coordinates them. At most, ICANN can give them suggestions. And > as for addresses, they get them from their local ISPs. > > What ICANN and many of the registries have in fact done is make an > issue of domain name "tasting", which is a means by which some forms > of abusers change names rapidly to evade filters. That is a matter of > having the fox guard the henhouse, however; the registries make money > on names being sold, and "tasting" is a means of making a lot of > sales. So while some have good efforts there, not all are motivated to > fight abuse. > > As to addresses, we can point to at least one entire ISP shut down as > most of the traffic coming from it was abusive. But for ISPs, it > becomes at least in part a matter of the amount of trouble they cause > their immediate neighbors. If they can link to other ISPs, who they > sell their services too is somewhat opaque to the wider world. And > since the abusers are not above "owning" systems, every network has > some subset of its subscribers to think about. > > I agree with your sentiment, Rich, and empathize with your > frustration. Writing comments in blogs doesn't get the hard work of > tools and policy done, though. You have to take the next step. > > > On Dec 30, 2009, at 8:26 PM, Paul Vixie wrote: > >> Randy Bush writes: >>>> If ARIN and/or RIPE and/or ICANN and/or anyone else were truly >>>> interested in making a dent in the problem, then they would have >>>> already >>>> paid attention to our collective work product. >>> >>> the rirs, the ietf, the icann, ... each think they are the top of the >>> mountain. we are supposed to come to them and pray. more likely that >>> the itu will come to them and prey. >> >> ARIN (an RIR) does not think in terms of mountains. the staff and >> company >> does what members and the elected board and elected advisory council >> ask. >> ARIN is a 501(c)(6) and sticks to its knitting, which thus far means no >> distinguished role in "spammers and their infrastructure" but that could >> change if someone writes a policy proposal which is adopted after the >> normal policy development process. >> >> please do consider whether ARIN could help with "spammers and their >> infrastructure" and if so, write a policy draft to that effect. ARIN is >> responsive to community input, and has well established and well >> publicized >> mechanisms for receiving and processing community input. nobody has to >> come and pray, but likewise, nobody should expect ARIN to look for >> mission >> creep opportunities. ARIN will go on doing what the community asks, no >> less, no more. ARIN has no mechanism, as a company, for "[paying] >> attention to [your] collective work product". our members, and the >> public >> at large who participates in ARIN's policy development process, do that. >> -- >> Paul Vixie >> Chairman, ARIN BoT >> KI6YSY >> > > http://www.ipinc.net/IPv4.GIF > > > > From simonchennj at gmail.com Thu Dec 31 17:48:01 2009 From: simonchennj at gmail.com (Simon Chen) Date: Thu, 31 Dec 2009 12:48:01 -0500 Subject: question regarding multi-homing In-Reply-To: <3c3e3fca0912301025p22816282jbb6b1a857817aaa1@mail.gmail.com> References: <237854710912300902h74e1c426w47c37c9ac0c766e1@mail.gmail.com> <3c3e3fca0912301025p22816282jbb6b1a857817aaa1@mail.gmail.com> Message-ID: <237854710912310948r725100ccja07274d8291b79c@mail.gmail.com> On Wed, Dec 30, 2009 at 1:25 PM, William Herrin wrote: > On Wed, Dec 30, 2009 at 12:02 PM, Simon Chen wrote: >> I have a question regarding multi-homing, mostly from stub network's >> operational point of view. My big question is: what kind of failures >> do you usually see from your providers? Link down? Link up, but >> withdraw some routes? Link up, no route change, but blackholing >> partial or all traffic? Anything else? > > Two more failure modes: > > Link up, receiving all routes but provider stops propagating your > announcement outward. > > Link up but unusably high packet loss to some or all destinations. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > Thank you all for the reply! It seems to me that Cisco performance based routing and other commercial solutions can probably handle the potential problems. How about operators that deal with this on their own? Is there a standard detection and recovery procedure? How long does it usually take, with or without scripting? Thanks! -Simon From bzs at world.std.com Thu Dec 31 18:16:27 2009 From: bzs at world.std.com (Barry Shein) Date: Thu, 31 Dec 2009 13:16:27 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> Message-ID: <19260.60027.605340.161994@world.std.com> The obvious change RIRs could make would be to make sure the contracts they allocate resources under give them the latitude to cancel those contracts if certain boundaries of behavior are breached. YES I REALIZE EASIER SAID THAN DONE. But just as allocation of resources is not a transfer of ownership to the allocatee by the same reasoning cancellation of that allocation for breach of contract is just a withdrawal of said license, not a "taking". What's difficult is establishing a system of reasonable due process within which to assert breaches, particularly given the many jurisdictions involved. ICANN is certainly building a model just like this with the UDRP etc. so perhaps that's something to follow. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From tomb at byrneit.net Thu Dec 31 18:39:41 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 31 Dec 2009 10:39:41 -0800 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Message-ID: <72F9A69DCF990443B2CEC064E605CE06260B@Pascal.zaphodb.org> The MEF has a set of specs for this. http://metroethernetforum.org/ In general, it's built as a "dumb pipe" virtual circuit, IE your client BPDUs and other IEEE 802.* signaling are ignored, as they are encapsulated, and forwarded explicitly to a given port. What you do on the switch that gets the deencapsualted traffic is your business. -----Original Message----- From: Endresen Even [mailto:Even.Endresen at bkk.no] Sent: Thursday, December 31, 2009 12:41 AM To: nanog at nanog.org Subject: Restrictions on Ethernet L2 circuits? Hello, Anyone with opinions on what restrictions a service provider should and should not impose on Ethernet L2 circuits provided to business customers wanting to connect several offices? The service provider's MPLS core network doesn't mind what traffic flows through the EoMPLS tunnel, but the L2 access network do mind and can be vulnerable to several layer 2 issues. Broadcast storm control and BPDU filter will protect the access network to a certain degree, but there are still potential layer 2 problems that can affect the switches, for example MAC address spoofing/flooding. Not to mention potentially difficult troubleshooting if a business customer connects two large LANs through the ISP's Ethernet layer 2 circuit, and then experience some occult layer 2 problem. Should business customers expect to be able to connect several LANs through an Ethernet L2 ciruit and build a layer 2 network spanning several locations? Or should the service provider implement port security and limit the number of MAC addresses on the access ports, forcing the customer to connect a router in both ends and segment their network? Also, do you see a demand for multi-point layer 2 networks (requiring VPLS), or are point-to-point layer 2 circuits sufficient to meet market demand? The most important argument for customers that choose Ethernet L2 over MPLS IP-VPN is that they want full control over their routing, they don't want the involvement from the service provider. Some customers also argue that a flat layer 2 network spanning several locations is a simpler and better design for them, and they don't want the "hassle" with routers and network segmentation. But IMO the customer (and the service provider) is far better off by segmenting their network in the vast majority of cases. What do you think? Regards, Even ___________________________________________________ This message and any attachment is intended for the person(s) named above only. It may contain information that is confidential or legally privileged. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank You. This footnote confirms that the email and attachment(s) has been swept by our anti-virus solution for the presence of known computer viruses. From sthaug at nethelp.no Thu Dec 31 18:55:42 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 31 Dec 2009 19:55:42 +0100 (CET) Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Message-ID: <20091231.195542.74746906.sthaug@nethelp.no> > > Or should the service provider implement port security and limit the > > number of MAC addresses on the access ports, forcing the customer to > > connect a router in both ends and segment their network? > > That would make the service less attractive, and also more complex to > set up and maintain. For point-to-point service, there is really no > reason for the network to care about customers' MAC addresses, VLAN tags > and such. *If* the customer connects directly to a router which terminates EoMPLS, I agree. But router ports are usually expensive, which often means that the customer connects to a switch. And switches definitely care about MAC addresses. > Couldn't PBB or even Q-in-Q provide that isolation as well, at least for > point-to-point services? I must say that I don't personally have much > experience with those, because we tend to connect our customers to > EoMPLS-capable routers directly. QinQ does nothing to reduce the number of MAC addresses required. PBB can do this, but there is still not a lot of PBB equipment available. > > Also, do you see a demand for multi-point layer 2 networks (requiring > > VPLS), or are point-to-point layer 2 circuits sufficient to meet > > market demand? > > That's a big question for us right now... we're not sure yet. I'd like to > hear others' opinions on this. There is some demand there. Whether that makes it worth it implementing as a product is another question. Trouybleshooting multipoint is more difficult than troubleshooting point to point circuits. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From paul at telcodata.us Thu Dec 31 19:32:21 2009 From: paul at telcodata.us (Paul Timmins) Date: Thu, 31 Dec 2009 14:32:21 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: <19260.60027.605340.161994@world.std.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <19260.60027.605340.161994@world.std.com> Message-ID: <4B3CFC45.6020201@telcodata.us> Barry Shein wrote: > The obvious change RIRs could make would be to make sure the contracts > they allocate resources under give them the latitude to cancel those > contracts if certain boundaries of behavior are breached. > > YES I REALIZE EASIER SAID THAN DONE. > > But just as allocation of resources is not a transfer of ownership to > the allocatee by the same reasoning cancellation of that allocation > for breach of contract is just a withdrawal of said license, not a > "taking". > Cool. Then you just have to figure out how to unilaterally withdraw a resource that doesn't have a centralized automated verification system. Taking you out of whois doesn't automatically take you out of people's BGP tables, after all. -Paul From drc at virtualized.org Thu Dec 31 19:44:03 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 31 Dec 2009 11:44:03 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <4B3CFC45.6020201@telcodata.us> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <19260.60027.605340.161994@world.std.com> <4B3CFC45.6020201@telcodata.us> Message-ID: <04CC26E0-F64E-498A-BB9D-C5C2B55A8154@virtualized.org> On Dec 31, 2009, at 11:32 AM, Paul Timmins wrote: > Cool. Then you just have to figure out how to unilaterally withdraw a resource that doesn't have a centralized automated verification system. Taking you out of whois doesn't automatically take you out of people's BGP tables, after all. See http://www.ietf.org/dyn/wg/charter/sidr-charter.html Regards, -drc From gbonser at seven.com Thu Dec 31 20:06:36 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 31 Dec 2009 12:06:36 -0800 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7129@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Simon Leinen > Sent: Thursday, December 31, 2009 8:29 AM > Subject: Re: Restrictions on Ethernet L2 circuits? > > Should business customers expect to be able to connect several LANs > > through an Ethernet L2 ciruit and build a layer 2 network spanning > > several locations? > > At least for our customers, that is indeed important. The most popular > application here is for a customer to connect a remote location to > their > campus network, and that want to (at least be able to) use any of their > existing VLANs at the remote site. That is what I currently expect from a layer 2 solution. One that does not allow VLAN tagging across the span is of much less utility. > > Or should the service provider implement port security and limit the > > number of MAC addresses on the access ports, forcing the customer to > > connect a router in both ends and segment their network? > > That would make the service less attractive, and also more complex to > set up and maintain. For point-to-point service, there is really no > reason for the network to care about customers' MAC addresses, VLAN > tags > and such. As you said, EoMPLS doesn't care. (Ethernet over L2TPv3 > shouldn't care either. If I had cost-effective edge routers that did > L2TPv3 encapsulation/decapsulation at line rate, I'd switch off MPLS in > our core tomorrow.) I don't want my provider enforcing such things on me provided it doesn't blow up their network. If I break my stuff, I expect to own all the pieces. I don't want them to nanny me and enforce policy that they determine is "for my own good" but are of no consequence in maintaining their own network. I want the pipe to be basically a long ethernet cable. My traffic should be sufficiently isolated as not to cause a problem in their network no matter what I do. > > Also, do you see a demand for multi-point layer 2 networks (requiring > > VPLS), or are point-to-point layer 2 circuits sufficient to meet > > market demand? > > That's a big question for us right now... we're not sure yet. I'd like > to > hear others' opinions on this. I once had such a solution in a network and it worked quite well. It was the (now defunct) Yipes! NAN (National Area Network) product. We used it for OSPF area 0 between all of our US facilities (several offices and two production colos). It worked quite well for the amount of traffic that went between facilities and it was stable for the approx. two years we had it deployed. In that case we had only a single VLAN that acted as a flat layer2 network that spanned the country with a pair of layer 2/3 switches at each office acting as routers for each facility area. This solution turned out to be cheaper and more efficient than running dedicated links to each facility and getting everything meshed over point-to-point circuts. If someone else already has a nationwide mesh, it probably makes good sense to lease some of that capacity than to try and build your own. From sronan at fattoc.com Thu Dec 31 20:23:44 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 31 Dec 2009 15:23:44 -0500 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7129@RWC-EX1.corp.seven.com> References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> <5A6D953473350C4B9995546AFE9939EE081F7129@RWC-EX1.corp.seven.com> Message-ID: <7484EC7C-DA1C-43C6-9078-E74DD8252FC1@fattoc.com> > (now defunct) Yipes! NAN (National Area Network) product They don't offer this anymore? From gbonser at seven.com Thu Dec 31 20:30:36 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 31 Dec 2009 12:30:36 -0800 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F712A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Endresen Even > Sent: Thursday, December 31, 2009 12:41 AM > Subject: Restrictions on Ethernet L2 circuits? > > Hello, > > Anyone with opinions on what restrictions a service provider should and > should not impose on Ethernet L2 circuits provided to business > customers > wanting to connect several offices? One thing I *really* miss from about a decade back is the Telseon model. It was completely self-managed. They would place a switch at the customer's location and if I wanted to change the bandwidth allocation on a port, it was as easy as logging in to a management portal and changing it. So if a port usually required only 10Meg but I needed to do something different for a few days, I could bump the bandwidth of the port up to 100Meg and then set it back down when I was done and I was billed based on what each day's bandwidth setting was. We paid only for what we had configured for each day. The other benefit of it was that if someone else also had the same service, we could self-provision a "logical wire" between us. So if I wanted to peer or somehow partner with another network that also had a Telseon switch, we simply logged in to the management portal and configured it, jacked in to the appropriate port on our respective switches, and it was done. It didn't even take a phone call, the provisioning process could be done on the web. I don't think anyone offers such a MAN service these days and I really wish it had stayed around. From gbonser at seven.com Thu Dec 31 20:32:36 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 31 Dec 2009 12:32:36 -0800 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <7484EC7C-DA1C-43C6-9078-E74DD8252FC1@fattoc.com> References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> <5A6D953473350C4B9995546AFE9939EE081F7129@RWC-EX1.corp.seven.com> <7484EC7C-DA1C-43C6-9078-E74DD8252FC1@fattoc.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F712B@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Shane Ronan > Sent: Thursday, December 31, 2009 12:24 PM > Subject: Re: Restrictions on Ethernet L2 circuits? > > > > (now defunct) Yipes! NAN (National Area Network) product > > They don't offer this anymore? > Yipes! Doesn't exist anymore. They were taken over by Reliance Globalcom and I am not sure what their offerings are. I would expect them to offer something similar but possibly under a different name. From ALanstein at FireEye.com Thu Dec 31 21:23:56 2009 From: ALanstein at FireEye.com (Alex Lanstein) Date: Thu, 31 Dec 2009 13:23:56 -0800 Subject: Article on spammers and their infrastructure In-Reply-To: <4B3CFC45.6020201@telcodata.us> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <19260.60027.605340.161994@world.std.com>, <4B3CFC45.6020201@telcodata.us> Message-ID: <60B0F2124D07B942988329B5B7CA393D020BE8763B@mail2.FireEye.com> >>>From: Paul Timmins [paul at telcodata.us] >>>Cool. Then you just have to figure out how to unilaterally withdraw a >>>resource that doesn't have a centralized automated verification system. >>>Taking you out of whois doesn't automatically take you out of people's >>>BGP tables, after all. That's step two of the problem - enforcement. Enforcement may seem "hard", but it's impossible without a policy. If there is no policy clearly violated, enforcement cannot happen. Regards, Alex Lanstein From sronan at fattoc.com Thu Dec 31 21:38:42 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 31 Dec 2009 16:38:42 -0500 Subject: Restrictions on Ethernet L2 circuits? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F712B@RWC-EX1.corp.seven.com> References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> <5A6D953473350C4B9995546AFE9939EE081F7129@RWC-EX1.corp.seven.com> <7484EC7C-DA1C-43C6-9078-E74DD8252FC1@fattoc.com> <5A6D953473350C4B9995546AFE9939EE081F712B@RWC-EX1.corp.seven.com> Message-ID: <4A92520E-8F48-47B0-9EC5-FABF1052D0F1@fattoc.com> Yipes is still offering services under the Yipes, name, at least in the NY Metro Area. On Dec 31, 2009, at 3:32 PM, George Bonser wrote: >> -----Original Message----- >> From: Shane Ronan >> Sent: Thursday, December 31, 2009 12:24 PM >> Subject: Re: Restrictions on Ethernet L2 circuits? >> >> >>> (now defunct) Yipes! NAN (National Area Network) product >> >> They don't offer this anymore? >> > > Yipes! Doesn't exist anymore. They were taken over by Reliance > Globalcom and I am not sure what their offerings are. I would expect > them to offer something similar but possibly under a different name. > From jmamodio at gmail.com Thu Dec 31 22:56:29 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 31 Dec 2009 16:56:29 -0600 Subject: Article on spammers and their infrastructure In-Reply-To: <60B0F2124D07B942988329B5B7CA393D020BE8763B@mail2.FireEye.com> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <19260.60027.605340.161994@world.std.com> <4B3CFC45.6020201@telcodata.us> <60B0F2124D07B942988329B5B7CA393D020BE8763B@mail2.FireEye.com> Message-ID: <202705b0912311456s7573226cl862cf00b57a13100@mail.gmail.com> >>>>Cool. Then you just have to figure out how to unilaterally withdraw a >>>>resource that doesn't have a centralized automated verification system. >>>>Taking you out of whois doesn't automatically take you out of people's >>>>BGP tables, after all. > > That's step two of the problem - enforcement. ?Enforcement may seem "hard", but it's impossible without a policy. ?If there is no policy clearly violated, enforcement cannot happen. You are right, without a policy there is not what to enforce, but on the other hand even with a policy you need somebody with police powers to enforce the policy. Then who do we want (if we do, which I don't believe we do) to play the net-police role ? ICANN ? the RIRs ? the ISPs ? ITU ? X invaders ? three letter agency of your choice ? local law enforcement ? I truly believe that if many service providers (access, domain, hosting, etc) reduce just a notch the profit making greed and start to close some doors for the bad guys we may be able to mitigate some problems. Time for new year resolutions ... Cheers Jorge