Re: Linux shaping packet loss
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 ni...@mnet.bg На Wed, 09 Dec 2009 06:38:31 + gordon b slater gordsla...@ieee.org написа: 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
Re: Arrogant RBL list maintainers
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 :-(
Re: Arrogant RBL list maintainers
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 d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: Arrogant RBL list maintainers
On Thu, Dec 10, 2009 at 8:20 AM, Tony Finch d...@dotat.at 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 d...@dotat.at 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.
RE: Arrogant RBL list maintainers
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, msulli...@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
Re: Arrogant RBL list maintainers
On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: As previously noted in this thread, msulli...@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
Linux Network Generator
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.
Re: Arrogant RBL list maintainers
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 wy 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
best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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, msulli...@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/
Re: Linux shaping packet loss
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
Re: Arrogant RBL list maintainers
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/
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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
Re: Arrogant RBL list maintainers
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, msulli...@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/
Re: best practices for PTR naming and whois (was, sadly, Re: ArrogantRBL list maintainers)
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 m...@mtcc.com 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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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/
Re: Arrogant RBL list maintainers
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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
In message 4b211da6.9000...@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: ma...@isc.org
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 08:38 AM, Mark Andrews wrote: In message4b211da6.9000...@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
Re: Arrogant RBL list maintainers
On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: As previously noted in this thread, msulli...@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
Re: Arrogant RBL list maintainers
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.
Re: Arrogant RBL list maintainers
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: s...@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
Re: Arrogant RBL list maintainers
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.
Re: Arrogant RBL list maintainers
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.
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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:
Optical fiber question
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
Re: Optical fiber question
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
More ASN collissions
As always, good research by renesys. http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml - Jared
Re: More ASN collissions
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Qwest mail admin contact?
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
Re: More ASN collissions
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 rdobb...@arbor.netwrote: 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
RE: Optical fiber question
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
Re: Optical fiber question
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
Re: Optical fiber question
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
Re: More ASN collissions
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpfdfIlRSdjm.pgp Description: PGP signature
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
--On Wednesday, December 02, 2009 6:23 PM -0800 Mehmet Akcin meh...@akcin.net 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.
Re: Arrogant RBL list maintainers
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
RE: Linux shaping packet loss
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
Re: More ASN collissions
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: domainmas...@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: domainmas...@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=AS3745stime=2000-01-01etime=2009-12-09type=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
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Dec 10, 2009, at 4:56 PM, Michael Loftis wrote: --On Wednesday, December 02, 2009 6:23 PM -0800 Mehmet Akcin meh...@akcin.net 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
Looking for MIX/NOTA members
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
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
Once upon a time, Owen DeLong o...@delong.com 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 cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Qwest mail admin contact?
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 na...@data102.com 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.li...@gmail.com)
Re: news from Google
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 - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.
Re: news from Google
--- m...@sizone.org wrote: From: Ken Chase m...@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. Um, yeah. Them there micro$loth folks is W more privacy oriented than them google rascals. DBS scott
