From no.spam at comcast.net Sat Mar 1 02:14:28 2014 From: no.spam at comcast.net (Keegan Holley) Date: Fri, 28 Feb 2014 21:14:28 -0500 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> Message-ID: <35E3BB4D-8C6B-4A8A-AEC1-FF729124ABEB@comcast.net> +1 in my experience uRPF get?s enabled, breaks something or causes confusion (usually related to multi-homing) and then get?s disabled. On Feb 28, 2014, at 11:49 AM, Christopher Morrow wrote: > On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy wrote: >> If you have uRPF enabled on all your access routers then you can >> configure routing policy such that advertising a route for a specific >> host system will trigger uRPF to drop the traffic at the first hop, in >> hardware. > > note that 'in hardware' is dependent upon the model used... > note that stuffing 2k (or 5 or 10 or...) extra routes into your edge > device could make it super unhappy. > > your points are valid for your designed network... they may not work everywhere. > making the features you point out work better or be more widely known > seems like a great idea though :) From me at staticsafe.ca Sat Mar 1 02:19:33 2014 From: me at staticsafe.ca (staticsafe) Date: Fri, 28 Feb 2014 21:19:33 -0500 Subject: Are DomainKeys for e-mail signing dead? In-Reply-To: References: Message-ID: <531143B5.3050506@staticsafe.ca> On 2/28/2014 18:36, Suresh Ramasubramanian wrote: > On Saturday, March 1, 2014, Matthew Black wrote: > >> Apologies if I slept through prior discussions on the topic. >> E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the >> following error: > > > Alive and well after the standard evolved. Google DKIM and then DMARC. > > I doubt anything as antique as listserv supports either, so route its > inbound / outbound mail through a gateway running postfix / sendmail etc. > > --srs > > opendkim[0] does this job beautifully. [0] - http://www.opendkim.org/ -- staticsafe From dwcarder at wisc.edu Sat Mar 1 02:19:40 2014 From: dwcarder at wisc.edu (Dale W. Carder) Date: Fri, 28 Feb 2014 20:19:40 -0600 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: <20140301021939.GN815@havarti.local> Thus spake Ryan Shea (ryanshea at google.com) on Thu, Feb 27, 2014 at 09:38:33AM -0500: > > Now, I hand you the 'show run' output and ask you if version 77 of the vty > config is on this device. Can you answer the question? Now I hand you the > 'show run' from 10,000 more device configs - and 100 more configuration > chunks from revision control. Can you still answer the question? Assume a > magical revision-history-aware configuration cross reference parser (while > a noble and lovely goal) is not available. Hi Ryan, If I'm understanding what you're trying to do, you could script around our rather unsophisticated 'sgrep' (stanza grep) tool combined with scripting around rancid & rcs to do what I think you are looking for. http://net.doit.wisc.edu/~dwcarder/scripts/sgrep sgrep can dump out a "stanza" of ios-like config, then you can rcsdiff that to your master, per 'chunk' of config. ex: > sgrep -s "vty" r-cssc-b280c-1-core.conf Found stanza in r-cssc-b280c-1-core.conf size:9 line vty 0 4 access-class G-A-AdminAccess in exec-timeout 30 0 ipv6 access-class G-A-v6AdminAccess in line vty 5 24 access-class G-A-AdminAccess in exec-timeout 30 0 ipv6 access-class G-A-v6AdminAccess in ! See the -s and -e options for our sgrep. Add 'xargs -P' around your glue, and I think you'd be in luck. If you were building configs around this model, you could use m4. Dale From dwcarder at wisc.edu Sat Mar 1 02:35:21 2014 From: dwcarder at wisc.edu (Dale W. Carder) Date: Fri, 28 Feb 2014 20:35:21 -0600 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: <20140301023520.GA3667@havarti.local> Thus spake Keegan Holley (no.spam at comcast.net) on Fri, Feb 28, 2014 at 09:49:19AM -0500: > I wasn?t saying just fix it. I was saying that router configs don?t lend well to versioning. Um, what? $> rlog r-cssc-b280c-1-core.conf | grep 'total revision' total revisions: 2009; selected revisions: 2009 > When it?s a router config chances are someone fat-fingered something. Most of the time the best thing to do is to fix or at least alert on the error, not to record it as a valid config version. We have our operators manually check in revisions (think in rcs terms: co -l router, go do work, verify it, ci -u router) rather than unsolicited / cron-triggered checkins. Then the check-in message contains the operator's description text of the change and often a ticket number. So there slightly fewer fat-finger configs checked in. Dale From johnl at iecc.com Sat Mar 1 02:41:58 2014 From: johnl at iecc.com (John Levine) Date: 1 Mar 2014 02:41:58 -0000 Subject: Are DomainKeys for e-mail signing dead? In-Reply-To: Message-ID: <20140301024158.35110.qmail@joyce.lan> >If your LISTSERV > -- gets mail from somebody with a domain that requires their mail to be >validly signed (for instance, via DMARC) > -- leaves that sender's address in the From: line > -- and breaks the DKIM signature Ah, that problem. I'd strongly suggest a shim in front of LISTSERV that checks for DMARC policies other than p=none and rejects the incoming mail, simply to protect other members of the list. Otherwise people who follow DMARC advice will reject list mail and get bounced off the list. Yes, this actually happens. R's, John From rdobbins at arbor.net Sat Mar 1 02:41:39 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 1 Mar 2014 02:41:39 +0000 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: <35E3BB4D-8C6B-4A8A-AEC1-FF729124ABEB@comcast.net> References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> <35E3BB4D-8C6B-4A8A-AEC1-FF729124ABEB@comcast.net> Message-ID: On Mar 1, 2014, at 9:14 AM, Keegan Holley wrote: > +1 in my experience uRPF get?s enabled, breaks something or causes confusion (usually related to multi-homing) and then get?s disabled. Enabling loose-check - even with allow-default - is useful solely for S/RTBH, if nothing else. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From no.spam at comcast.net Sat Mar 1 03:20:11 2014 From: no.spam at comcast.net (Keegan Holley) Date: Fri, 28 Feb 2014 22:20:11 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <20140301023520.GA3667@havarti.local> References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> <20140301023520.GA3667@havarti.local> Message-ID: <2F9FFD46-355A-4EBD-9380-E033B8650670@comcast.net> On Feb 28, 2014, at 9:35 PM, Dale W. Carder wrote: > Thus spake Keegan Holley (no.spam at comcast.net) on Fri, Feb 28, 2014 at 09:49:19AM -0500: >> I wasn?t saying just fix it. I was saying that router configs don?t lend well to versioning. > > Um, what? > > $> rlog r-cssc-b280c-1-core.conf | grep 'total revision' > total revisions: 2009; selected revisions: 2009 I wish you were here to see my eyes rolling.. 2009 versions of something are no more grok-able than one current version. Congrats, you have a config backup system. > >> When it?s a router config chances are someone fat-fingered something. Most of the time the best thing to do is to fix or at least alert on the error, not to record it as a valid config version. > > We have our operators manually check in revisions (think in rcs terms: > co -l router, go do work, verify it, ci -u router) rather than > unsolicited / cron-triggered checkins. Then the check-in message > contains the operator's description text of the change and often a > ticket number. So there slightly fewer fat-finger configs checked in. That?s not what the OP was looking for AFAIK. This is just change management. > > Dale From jra at baylink.com Sat Mar 1 04:48:02 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Feb 2014 23:48:02 -0500 (EST) Subject: Any experience with Comcast digital voice for OOB (offlist is fine) In-Reply-To: <03cf01cf34bb$1127e670$3377b350$@truenet.com> Message-ID: <18881252.10452.1393649282503.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: eric-list at truenet.com > Subject: Any experience with Comcast digital voice for OOB (offlist is fine) You're asking if a VoIP link could be used with traditional modems to do OOB management? I'm pretty sure the answer is a flat no: any modems faster than 1200 bps depend on phase change modulations that VoIP codecs can't begin to deal with; FoIP is implemented by spoofing: the TA detects CNG tone, and spoofs a datalink. I don't know of any TAs that will do that with regular data modems. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jared at puck.nether.net Sat Mar 1 11:51:01 2014 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 1 Mar 2014 06:51:01 -0500 Subject: Any experience with Comcast digital voice for OOB (offlist is fine) In-Reply-To: <03cf01cf34bb$1127e670$3377b350$@truenet.com> References: <03cf01cf34bb$1127e670$3377b350$@truenet.com> Message-ID: <70B7B15A-7E23-43E5-91CA-68D89526D107@puck.nether.net> I've had problems with DTMF originating from comcast voice in the past (going into t1/pri from xo terminated on Cisco-ISR with voice modules). Was a pain to troubleshoot. I would be interested to hear your results, much depends on how they implement the service. - Jared > On Feb 28, 2014, at 2:27 PM, wrote: > > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > > From no.spam at comcast.net Sat Mar 1 18:49:00 2014 From: no.spam at comcast.net (Keegan Holley) Date: Sat, 1 Mar 2014 13:49:00 -0500 Subject: Any experience with Comcast digital voice for OOB (offlist is fine) In-Reply-To: <03cf01cf34bb$1127e670$3377b350$@truenet.com> References: <03cf01cf34bb$1127e670$3377b350$@truenet.com> Message-ID: <7D29A187-1DC1-481D-8E52-5205290EF1D6@comcast.net> As others have said modems require POTS or at least a PBX line. Also isn?t the hand-off fog VoIP ethernet? You wouldn?t be able to stick that into the RJ-11 port in the modem. It would be easier to use the comcast internet connection with some sort of IPsec tunnel for OOB. It?s cheap and mostly reliable. If you?re looking for a better solution see the thread on OOB gear RE: opengear. They are multi-port and support, POTS, wifi and 3G for access. On Feb 28, 2014, at 2:27 PM, eric-list at truenet.com wrote: > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > > > From eric-list at truenet.com Sat Mar 1 20:20:29 2014 From: eric-list at truenet.com (Eric Tykwinski) Date: Sat, 1 Mar 2014 15:20:29 -0500 Subject: Any experience with Comcast digital voice for OOB (offlist is fine) In-Reply-To: <7D29A187-1DC1-481D-8E52-5205290EF1D6@comcast.net> References: <03cf01cf34bb$1127e670$3377b350$@truenet.com> <7D29A187-1DC1-481D-8E52-5205290EF1D6@comcast.net> Message-ID: Thanks all, Jared, sorry I forgot about out-of-band touch tones and should of specified better, the client was looking to use a modem like most guessed. I suggested using a cellular option since POTS wasn't available, as most gear usually has that as an option, and it looks like US Robotics makes a serial connection modem at that. I do remember though something about a modem over VoIP protocol being developed, something like Jay was saying about Faxing over VoIP, but I guess it never took off. My guess being relying on the same line as an internet connection would be about that smart anyways. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 On Mar 1, 2014, at 1:49 PM, Keegan Holley wrote: > As others have said modems require POTS or at least a PBX line. Also isn?t the hand-off fog VoIP ethernet? You wouldn?t be able to stick that into the RJ-11 port in the modem. It would be easier to use the comcast internet connection with some sort of IPsec tunnel for OOB. It?s cheap and mostly reliable. > > If you?re looking for a better solution see the thread on OOB gear RE: opengear. They are multi-port and support, POTS, wifi and 3G for access. > > On Feb 28, 2014, at 2:27 PM, eric-list at truenet.com wrote: > >> >> Sincerely, >> >> Eric Tykwinski >> TrueNet, Inc. >> P: 610-429-8300 >> F: 610-429-3222 >> >> >> >> >> > From mark.tinka at seacom.mu Sat Mar 1 21:39:27 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 1 Mar 2014 23:39:27 +0200 Subject: Any experience with Comcast digital voice for OOB (offlist is fine) In-Reply-To: References: <03cf01cf34bb$1127e670$3377b350$@truenet.com> <7D29A187-1DC1-481D-8E52-5205290EF1D6@comcast.net> Message-ID: <201403012339.30677.mark.tinka@seacom.mu> On Saturday, March 01, 2014 10:20:29 PM Eric Tykwinski wrote: > I do remember though something about a modem over VoIP > protocol being developed, something like Jay was saying > about Faxing over VoIP, but I guess it never took off. > My guess being relying on the same line as an internet > connection would be about that smart anyways. FoIP (Fax over IP) is "dodgy" for a couple of key reasons: a) Different call capabilities, during setup, of SIP and T.30, where a portion of the segment is TDM. b) Different FoIP modes, during setup, where one end uses SIP and the other uses T.38, with an inability to propagate these capabilities across the circuit. c) Signaling delay between initial INVITE and 200 OK, introduced due to SIP-SS7-SIP conversion. d) TDM-IP-TDM conversions causing incorrect training across the circuit. e) Low-rate codecs in the transit path that are not signaled to the end points, e.g., end points running at g.711 while an intermediate device runs at g.729. My guess is modems would have the same issues. In general, FoIP solutions have a better chance of working if a circuit provisioned to transmit a fax is all-IP (or, at the very least, limits the TDM-IP conversions). If all else fails, scan and e-mail. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From adam.vitkovsky at swan.sk Sun Mar 2 12:45:13 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Sun, 2 Mar 2014 12:45:13 +0000 Subject: Filter on IXP In-Reply-To: <5310C145.6080402@ceriz.fr> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> <5310BEEA.9070403@foobar.org> <5310C145.6080402@ceriz.fr> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011CCF4E@EX01.swan.local> > On the other hand, if a member provides transit, he will add its > customer prefixes to RaDB / RIPEdb with appropriate route > objects and the ACL will be updated accordingly. Shouldn't break there. And that's a really nice side effect. However in case of transit providers the problem is that RaDB /RIPE lists what prefixes you are allowed to advertise. But that does not necessarily fully match with what source IPs can leave your network. I mean ISP-A can have a customer that uses PA range of other ISP-B and only has a static route towards ISP-A for some TE purposes. I'm not well versed with RIPE myself so I'm not sure whether there's a way to handle this situation. adam -----Original Message----- From: J?r?me Nicolle [mailto:jerome at ceriz.fr] Sent: Friday, February 28, 2014 6:03 PM To: Nick Hilliard; nanog at nanog.org Subject: Re: Filter on IXP Le 28/02/2014 17:52, Nick Hilliard a ?crit : > this will break horribly as soon as you have an IXP member which > provides transit to other multihomed networks. It could break if filters are based on announced prefixes. That's preciselly why uRPF is often useless. On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. -- J?r?me Nicolle +33 6 19 31 27 14 From nick at foobar.org Sun Mar 2 13:00:51 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 02 Mar 2014 13:00:51 +0000 Subject: Filter on IXP In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011CCF4E@EX01.swan.local> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> <5310BEEA.9070403@foobar.org> <5310C145.6080402@ceriz.fr> <61DC6BC4ABA10E4489D4A73EBABAC18B011CCF4E@EX01.swan.local> Message-ID: <53132B83.7020707@foobar.org> On 02/03/2014 12:45, Vitkovsk? Adam wrote: >> On the other hand, if a member provides transit, he will add its >> customer prefixes to RaDB / RIPEdb with appropriate route >> objects and the ACL will be updated accordingly. Shouldn't break there. > > And that's a really nice side effect. and it only works for leaf networks. The moment your ixp supports larger networks, it will break things horribly. It also assumes that: - all your IXP members use route servers (not generally true) - the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true) - the IXP port ASICs can handle large L2 access lists (not generally true) - there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain) - there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement) - the IXP participants keep their IRRDB information fully up-to-date (not generally true) - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Last but not least: - there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case) There are many places where automated RPF makes a lot of sense. An IXP is not one of them. Nick From royce at techsolvency.com Sun Mar 2 16:34:49 2014 From: royce at techsolvency.com (Royce Williams) Date: Sun, 2 Mar 2014 07:34:49 -0900 Subject: Filter on IXP In-Reply-To: <53132B83.7020707@foobar.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> <5310BEEA.9070403@foobar.org> <5310C145.6080402@ceriz.fr> <61DC6BC4ABA10E4489D4A73EBABAC18B011CCF4E@EX01.swan.local> <53132B83.7020707@foobar.org> Message-ID: On Sun, Mar 2, 2014 at 4:00 AM, Nick Hilliard wrote: > There are many places where automated RPF makes a lot of sense. An IXP is > not one of them. That make sense. Everyone is rightly resistant to automated filtering. But could we automate getting the word out instead? Can obvious BCP38 cluelessness be measured? Maybe as a ratio of advertised to unadvertised egressing ASes, etc. ? If so, then if your downstream/peer is even *partially* BCP38, give them a pass. They are at least somewhat aware of the problem. Otherwise: - Visually red-flag their BCP38 stats/percentage in RADb; - Send them an automatic email once a week; - Let upstreams *optionally* not automatically update their routes via RADb until they call to ask why; etc. Can we combat the awareness problem in bulk -- without *filtering* in bulk? Royce From rdrake at direcpath.com Sun Mar 2 18:13:41 2014 From: rdrake at direcpath.com (Robert Drake) Date: Sun, 2 Mar 2014 13:13:41 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <20140301021939.GN815@havarti.local> References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> <20140301021939.GN815@havarti.local> Message-ID: <531374D5.1030700@direcpath.com> On 2/28/2014 9:19 PM, Dale W. Carder wrote: > If I'm understanding what you're trying to do, you could script around > our rather unsophisticated 'sgrep' (stanza grep) tool combined with > scripting around rancid & rcs to do what I think you are looking for. > > http://net.doit.wisc.edu/~dwcarder/scripts/sgrep > > sgrep can dump out a "stanza" of ios-like config, then you can rcsdiff > that to your master, per 'chunk' of config. > Dale > > I'm digging the idea of your command. Along the same lines I've got this awk snippet that I made and then forgot about. It functions like the cisco pipe begin/end commands: #!/bin/sh if [ "x${2}" = "x" ]; then awk "/${1}/{temp=1}; temp==1{print}" else awk "/${1}/{temp=1};/${2}/{temp=0}; temp==1{print}" fi Usage: cat router-confg | begin_regex 'line vty' '!' If you omit the second argument it just shows you from your match until the end of file. From plato at wisc.edu Sun Mar 2 20:56:10 2014 From: plato at wisc.edu (Elle Janet Plato) Date: Sun, 02 Mar 2014 14:56:10 -0600 Subject: Managing IOS Configuration Snippets Message-ID: <1910E7FF-9EE9-4CAE-AB1F-0DBD585D202D@wisc.edu> Robert, >> sgrep can dump out a "stanza" of ios-like config, then you can rcsdiff >> that to your master, per 'chunk' of config. >> Dale >> > > I'm digging the idea of your command. Along the same lines I've got this > awk snippet that I made and then forgot about. It functions like the cisco > pipe begin/end commands: > The clever part comes when you write something to tweak sgrep to spit out files with the commands you need to run to reconfigure multiple devices, and then use the "make" command to invoke clogin in parallel to push those changes. Showing a complete example would get tedious, I have a tarball of the minimum fileset needed to do this lying around somewhere. Dale probably has one as well. The basic workflow is as follows: 1) Given a set of configuration files named device.conf, generate a set of configuration changes to be made, and place those changes in a set of files named device.cmd. Device is the valid hostname of a router/switch you need to configure. Device.conf is the configuration file for that device, for example from rancid. The contents of device.cmd are valid config commands including "config term", "exit" and "write mem", that you intend to run on the device. We will talk about what to do with those command files in a later step. So if you wanted to edit the name of vlan100 on all of your routers, you might do this: for device in `ls r-*.conf | cut -d. -f1`; do sgrep -is "^vlan 10\n" $device.conf | sed -e 's/name .*/name new-name/' | grep -v Found > $device.cmd; done r-myrouter-100.cmd might contain: vlan 10 name new-name ! So you would need to make your loop more complex to add the "conf t", "exit" and "wr mem" parts, or just use a script. I write a script called mkcmdfile to wrap sgrep every time I need to do work like this. mkcmdfile means "make command file". If you want to work from the command line, add a second sed rule to look for "Found" and replace it with "conf t", eliminate the trailing grep -v "Found" and edit the original sed to replace vlan new-name with vlan new-name\nexit\nwr mem/. I don't recommend doing that, but you could. I put that into a wrapper script, or I post process the cmd files with a second for loop. Now that is the less hard way to change 4,000 devices. Except for made up examples like renaming a vlan on 4,000 devices, that is only a little less complicated than just doing it by hand, but hopefully you get the idea. One huge win though, even when doing it by hand as above, I can generate the files ahead of time, ensure they are correct, and then when I push them at 4AM I do not have to worry about typographic errors. If you have change approval boards, the CAB can examine the .cmd files if they choose to, this is a great way to sanity check your work at 2PM when your mind is clear. Loops are cool, but in reality, I am far more likely to edit sgrep with some reasonable defaults, hand it a list of filenames, and then rely on $ARGV changing to reflect the name of the file it is currently working on, so I know that when I have a diamond loop (for (<>) { do stuff }) in my Perl, $ARGV.conf is what sgrep is reading from, and $ARGV.cmd is the file sgrep should be writing to. In fact, I have something I call mkcmdfile that does pretty much that. Writing a custom sgrep for each change allows me to consider the entire contents of the router, including its name, the business rules associated with it, anything I keep in a database, etc, when making configuration changes to it. Don't worry too much about how to do step 1. The lesson you must understand, is that step 1 is finished when you have a directory full of files, all named device.cmd, where device is the name of the device to work on, and the contents are the commands to execute. 2) Given a directory full of command files (named device.cmd) invoke clogin on each file: The hard way would be another for loop: for device in `ls *.cmd | cut -d. -f1`; do clogin -s $device.cmd $device > $device.log; done I go into how to do this easily using make later. 3) Look at the resulting $device.log files you generated, and make sure nothing crazy happened. It really is that simple. I can create cmd files for 4,000 devices, ensure the cmd files are changing the correct interface properties, ntp server names or whatever, and push them to all 4,000 devices, in a few hours. Doing that by hand would take a week. In some cases, I can push them in 30 minutes. I have the minimum fileset you need to do that lying around somewhere, but basically that is it. When I wrote sgrep, I was asking myself, what would happen if I make a tool that had more computing power than a tool that works on regular expressions? grep gets its name from: global - 'regular expression' - print. But regular expressions are limited in the computing complexity they can reflect. I really wanted something turing complete. But I never found a way to do it, that was less complex than inventing a new language. Eventually I decided to have it think in terms of stanzas, and the operations you could perform on a stanza. I started thinking about structure. When you understand structure, you can look at things with more finesse. Thanks to Dale, sgrep understands networks, so this means you can look for OSPF stanzas with network statements that contain a network range that would include a specific IP address. If you grep for 10.1.2.3 in a router, you won't find the OSPF stanza with network 10.1.2.0 255.255.255.0, but sgrep will. I am thinking about a template language for sgrep, and once I write it I will let Dale know and he can put it on his page. The thing is, start with grep, and ask what has more power than a regular expression? Adding context is a logical next step, REs are context free. Then ask, does using this structure with more capability result in clarity in how I express my will, and is it easy to understand, especially for people familiar with normal unix tools. Anyway, to expand on automating this with make a little. Dave Plonka made some cool makefiles, and we've been tweaking them every since. Step 1 is always figuring out how to generate command files. I have a mkcmdfile script I use and customize often for anything more complicated than a password change, or vlan edit. Step 2 is always pushing those device.cmd files to the various devices they refer to. Step 3 is always validating your work. Let us expand on step 2. When done with step 1, you have a bunch of device.cmd files, but you are no closer to getting work done than when you started. But you need to understand the first step before the second step makes sense. So given a directory full of .cmd files, you want to run those commands on the associated devices. - The hard way would be to invoke clogin directly (ensuring the file has conf t and write mem in it). for $device in `ls *.cmd | cut -d. -f1`; do clogin -s $device.cmd; done - The slightly less hard way would be to create a makefile with the following in it, and by hand add a rule to make all the .log files: cat > Makefile clogin = path-to/clogin2 -f path-to/.cloginrc .SUFFIXES: .cmd .log DIR = /home/netconfig-user/cms TMPupgrade: device1.log, device2.log, device3.log, repeat for several thousand devices, hire an intern, a typist, whatever. .cmd.log: @echo BEGIN .cmd.log $@ base='$*'; \ $(clogin) $${clogin_timeout:+-t$${clogin_timeout}} -x $< $${base%%_*} > $@ || (rm -f $@; exit 1) @echo END .cmd.log $@ ctrl-D Sure, that looks easy to read. Did my modem disconnect? It just says, if you run "make device.log" it will look for a command file named device.cmd, and compile it using the 'clogin' compiler, with the options: clogin -t timeout -x device.cmd device > device.log, the or (||) means, if the command fails, instead of crashing just rm the .log file and continue with the next file. Given that, you could invoke make and it would be off and running, but that gets awfully tedious for one thousand devices. $configbox> make -j 20 TMPupgrade. Boom, 20 at a time your system is clogin-ing into devices and pushing commmands. So the better way is you add an extra rule to make the makefile you want, and then use that to invoke clogin: cat > Makefile clogin = path-to/clogin2 -f path-to/.cloginrc .SUFFIXES: .cmd .log DIR = /home/netconfig-user/cms upgrade.make: @print "TMPupgrade: " $$($(ls) *.cmd | sed -e 's/\.cmd$$/.log/')" \ \n\nupgrade: " $$($(ls) *.cmd | sed -e 's/\.cmd$$/.log/')" \ \n\ninclude ~net/cms/Makefile" > $@ .cmd.log: @echo BEGIN .cmd.log $@ base='$*'; \ $(clogin) $${clogin_timeout:+-t$${clogin_timeout}} -x $< $${base%%_*} > $@ || (rm -f $@; exit 1) @echo END .cmd.log $@ ctrl-D Given the above makefile, you can make a new makefile with the correct targets. $configbox> make upgrade This will use sed to replace the .cmd with a .log for every device.cmd file, and create a new makefile with a rule to make all the .log files. Again, I should have the correct minimum fileset lying around somewhere, if someone wants help I can try and make a better explanation and post it. Once you have the new makefile, just use it. $configbox> make -f upgrade.make -j 20 The process really is pretty damn simple, but the details are kind of tedious. Once you get used to it, you can whip out scripts to do complex validation rules in no time flat. On Dale's page you will also find some code I got from Cisco to merge catos/IOS configs from a 6500 in hybrid mode to a unified IOS only mode, and merge them with a template. I fixed some small bugs in it, and got permission to open source it. That code parses IOS configs fairly elegantly and shoves them into Perl data structures, which you can then use to make savvy choices with respect to configuration auditing. The code is open source, have at it. You can validate the configs on your devices, and best of all, you can validate your business logic. If you name all your primary routers something odd, and your backups something even, you can validate the ospf metrics on primary are different than the ospf metrics on the secondary, because the script understands not only the configuration, but how the device fits into the network, and what business logic applies to the configuration. I hope this makes things clearer, instead of less clear. Cheers, Elle Janet Plato NS Application Developer/Consultant Network Engineer University of Wisconsin, Madison -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7348 bytes Desc: not available URL: From pauldotwall at gmail.com Sun Mar 2 21:47:55 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Sun, 2 Mar 2014 16:47:55 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: Message-ID: On Thu, Feb 27, 2014 at 8:03 PM, Justin M. Streiner wrote: > I've heard all sorts of BS answers as to why there is no v6 for FIOS, Step 1. Ask an ALU sales droid about their IPv6 support on PON Step 2. Be disappointed by the answer Step 3. Stroke chin or beard thoughtfully while enjoying the epiphany about why FiOS doesn't do IPv6 yet Bonus - enjoy complementary epiphany about why AT&T uVerse uses 6RD Drive Slow, Paul From adam.vitkovsky at swan.sk Mon Mar 3 09:25:18 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Mon, 3 Mar 2014 09:25:18 +0000 Subject: Filter on IXP In-Reply-To: <53132B83.7020707@foobar.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> <5310BEEA.9070403@foobar.org> <5310C145.6080402@ceriz.fr> <61DC6BC4ABA10E4489D4A73EBABAC18B011CCF4E@EX01.swan.local> <53132B83.7020707@foobar.org> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011CD059@EX01.swan.local> > - the IXP participants keep their IRRDB information fully up-to-date Geez anything else but the fully up-to-date IRRDB please. That just won't fly. That's why I said that an up to date IRRDB would have been a nice side effect of IXP filtering. > - the IXP operators put in mechanisms to stop both route-leakages > and incorrect IRRDB as-set additions from causing things to explode. Yes this is a valid point I think the technicalities of how to implement this kind of filtering at the IXP equipment is out of scope for this discussion. Anyways I believe IXPs should not be responsible for this mess and that BCP38 should be implemented by the participants of an IXP. As Saku Ytti mentioned several times Tier2 ISPs are in the best position for a successful BCP38 filtering at their network boundaries. adam -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Sunday, March 02, 2014 2:01 PM To: Vitkovsk? Adam; J?r?me Nicolle; nanog at nanog.org Subject: Re: Filter on IXP On 02/03/2014 12:45, Vitkovsk? Adam wrote: >> On the other hand, if a member provides transit, he will add its >> customer prefixes to RaDB / RIPEdb with appropriate route objects and >> the ACL will be updated accordingly. Shouldn't break there. > > And that's a really nice side effect. and it only works for leaf networks. The moment your ixp supports larger networks, it will break things horribly. It also assumes that: - all your IXP members use route servers (not generally true) - the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true) - the IXP port ASICs can handle large L2 access lists (not generally true) - there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain) - there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement) - the IXP participants keep their IRRDB information fully up-to-date (not generally true) - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Last but not least: - there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case) There are many places where automated RPF makes a lot of sense. An IXP is not one of them. Nick From andrea at ripe.net Mon Mar 3 09:32:19 2014 From: andrea at ripe.net (Andrea Cima) Date: Mon, 03 Mar 2014 10:32:19 +0100 Subject: New AS Number Blocks allocated to the RIPE NCC Message-ID: <53144C23.5050203@ripe.net> Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA in February 2014. 200192-201215 201216-202239 You may want to update your records accordingly. Best regards, Andrea Cima Registration Services Manager RIPE NCC From nick at flhsi.com Mon Mar 3 20:40:35 2014 From: nick at flhsi.com (Nick Olsen) Date: Mon, 3 Mar 2014 15:40:35 -0500 Subject: DSLAM Message-ID: <215e56f0$3f0d873b$72147b2e$@flhsi.com> Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. And I need it by tomorrow. Normal channels seem to be impacted by weather. Not to mention we've been pretty unhappy with our current models (Versa, And Planet). Any options? Unicast is acceptable. Nick Olsen Network Operations (855) FLSPEED x106 From Valdis.Kletnieks at vt.edu Mon Mar 3 21:04:58 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Mar 2014 16:04:58 -0500 Subject: DSLAM In-Reply-To: Your message of "Mon, 03 Mar 2014 15:40:35 -0500." <215e56f0$3f0d873b$72147b2e$@flhsi.com> References: <215e56f0$3f0d873b$72147b2e$@flhsi.com> Message-ID: <59921.1393880698@turing-police.cc.vt.edu> On Mon, 03 Mar 2014 15:40:35 -0500, "Nick Olsen" said: > Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. > And I need it by tomorrow. Bonus points if you tell us what continent/timezone you need this in. Getting said device to 60 Hudson and to Nowhere Island, Tahiti are 2 very different things... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nick at flhsi.com Mon Mar 3 21:06:35 2014 From: nick at flhsi.com (Nick Olsen) Date: Mon, 3 Mar 2014 16:06:35 -0500 Subject: DSLAM Message-ID: <36527962$11044943$1ad3ba0d$@flhsi.com> Cocoa, Florida. Sorry. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: Valdis.Kletnieks at vt.edu Sent: Monday, March 03, 2014 4:05 PM To: nick at flhsi.com Cc: nanog at nanog.org Subject: Re: DSLAM On Mon, 03 Mar 2014 15:40:35 -0500, "Nick Olsen" said: > Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. > And I need it by tomorrow. Bonus points if you tell us what continent/timezone you need this in. Getting said device to 60 Hudson and to Nowhere Island, Tahiti are 2 very different things... From nick at flhsi.com Mon Mar 3 21:41:25 2014 From: nick at flhsi.com (Nick Olsen) Date: Mon, 3 Mar 2014 16:41:25 -0500 Subject: DSLAM Message-ID: <4f94e37b$368082bc$293e104b$@flhsi.com> Thanks to all that replied. Specially Eric @ Luma Optics. We've reached the cut off date for day. We're working on fixing the DSLAM we have on hand for use. I appreciate all the replies. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nick Olsen" Sent: Monday, March 03, 2014 3:40 PM To: nanog at nanog.org Subject: DSLAM Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. And I need it by tomorrow. Normal channels seem to be impacted by weather. Not to mention we've been pretty unhappy with our current models (Versa, And Planet). Any options? Unicast is acceptable. Nick Olsen Network Operations (855) FLSPEED x106 From elouie at yahoo.com Tue Mar 4 01:11:07 2014 From: elouie at yahoo.com (Eric A Louie) Date: Mon, 3 Mar 2014 17:11:07 -0800 (PST) Subject: ISP inbound failover without BGP Message-ID: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> This may sound like dumb question, but... I'm used to asking those. Here's the scenario Another ISP, say AT&T, is the primary ISP for a customer. Customer has publicly accessible servers in their office, using the AT&T address space. I am the customer's secondary ISP. Now, if AT&T link fails, I can provide the customer outbound Internet access fairly easily.? So they can surf and get to the Internet. What about the publicly accessible servers that have AT&T addresses, though? One thought I had was having them use Dynamic DNS service.? Are there any other solutions, short of using BGP multihoming and having them try to get their own ASN and IPv4 /24 block? It looks like a few router manufacturers have devices that might work, but it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary ISP fails, the secondary ISP address is advertised. From jgreco at ns.sol.net Mon Mar 3 21:27:50 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 3 Mar 2014 15:27:50 -0600 (CST) Subject: ISP inbound failover without BGP In-Reply-To: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <201403032127.s23LRokW073208@aurora.sol.net> > This may sound like dumb question, but... I'm used to asking those.=0A=0AHe= > re's the scenario=0A=0AAnother ISP, say AT&T, is the primary ISP for a cust= > omer.=0A=0ACustomer has publicly accessible servers in their office, using = > the AT&T address space.=0A=0AI am the customer's secondary ISP.=0A=0ANow, i= > f AT&T link fails, I can provide the customer outbound Internet access fair= > ly easily.=A0 So they can surf and get to the Internet.=0A=0AWhat about the= > publicly accessible servers that have AT&T addresses, though?=0A=0AOne tho= > ught I had was having them use Dynamic DNS service.=A0 =0A=0AAre there any = > other solutions, short of using BGP multihoming and having them try to get = > their own ASN and IPv4 /24 block?=0A=0A=0AIt looks like a few router manufa= > cturers have devices that might work, but it looks like a short DNS TTL (or= > Dynamic DNS) needs to be set so when the primary ISP fails, the secondary = > ISP address is advertised. The usual solution is to get the public servers stuck in a colo that's multihomed. Most of the other solutions tend to be a bit dodgy. If your gear is sufficiently competent, you can hack up a solution with multiple addresses for each of the servers (one on each ISP) and then use a short TTL to fail over, but this has more of "fail" than "fail over" about it, because there are a bunch of issues that typically result. ... 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 matthew at corp.crocker.com Tue Mar 4 01:50:26 2014 From: matthew at corp.crocker.com (Matthew Crocker) Date: Mon, 3 Mar 2014 20:50:26 -0500 Subject: ISP inbound failover without BGP In-Reply-To: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <5CE853F6-C5FB-46A9-94D9-11E4617CA849@corp.crocker.com> Depends on the application, SIP, VPN, SMTP, etc just setup both IPs and let the end-user application figure it out (SIP-UA register to both IPs for example) HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend the requests. Then it can load balance traffic over both IPs. DNS TTL ?tricks? are just that, they work ?kinda? Fatpipe? Crazy expensive IMHO but I hear they work ok. -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Mar 3, 2014, at 8:11 PM, Eric A Louie wrote: > This may sound like dumb question, but... I'm used to asking those. > > Here's the scenario > > Another ISP, say AT&T, is the primary ISP for a customer. > > Customer has publicly accessible servers in their office, using the AT&T address space. > > I am the customer's secondary ISP. > > Now, if AT&T link fails, I can provide the customer outbound Internet access fairly easily. So they can surf and get to the Internet. > > What about the publicly accessible servers that have AT&T addresses, though? > > One thought I had was having them use Dynamic DNS service. > > Are there any other solutions, short of using BGP multihoming and having them try to get their own ASN and IPv4 /24 block? > > > It looks like a few router manufacturers have devices that might work, but it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary ISP fails, the secondary ISP address is advertised. > From eric at lumaoptics.net Mon Mar 3 20:48:31 2014 From: eric at lumaoptics.net (Eric) Date: Mon, 3 Mar 2014 12:48:31 -0800 Subject: DSLAM In-Reply-To: <215e56f0$3f0d873b$72147b2e$@flhsi.com> References: <215e56f0$3f0d873b$72147b2e$@flhsi.com> Message-ID: <9D3FD033-6E2D-4082-8E85-3F91FABDE157@lumaoptics.net> I can do it. Sent from my iPhone > On Mar 3, 2014, at 12:40 PM, "Nick Olsen" wrote: > > Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. > And I need it by tomorrow. > > Normal channels seem to be impacted by weather. Not to mention we've been > pretty unhappy with our current models (Versa, And Planet). > > Any options? Unicast is acceptable. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > From sixsigma44 at hotmail.com Tue Mar 4 02:31:56 2014 From: sixsigma44 at hotmail.com (Ray) Date: Mon, 3 Mar 2014 21:31:56 -0500 Subject: ISP inbound failover without BGP In-Reply-To: <5CE853F6-C5FB-46A9-94D9-11E4617CA849@corp.crocker.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com>, <5CE853F6-C5FB-46A9-94D9-11E4617CA849@corp.crocker.com> Message-ID: Depending on their business, using dynamic DNS providers could be a really bad idea. If they deal only with home users who won't even know, it'll probably work. If their customers are security-aware businesses, they probably block all sites hosted with dynamic DNS systems. Ray > Subject: Re: ISP inbound failover without BGP > From: matthew at corp.crocker.com > Date: Mon, 3 Mar 2014 20:50:26 -0500 > To: elouie at yahoo.com > CC: nanog at nanog.org > > > > Depends on the application, > > SIP, VPN, SMTP, etc just setup both IPs and let the end-user application figure it out (SIP-UA register to both IPs for example) > > HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend the requests. Then it can load balance traffic over both IPs. > > DNS TTL ?tricks? are just that, they work ?kinda? > > Fatpipe? Crazy expensive IMHO but I hear they work ok. > > -Matt > > -- > Matthew S. Crocker > President > Crocker Communications, Inc. > PO BOX 710 > Greenfield, MA 01302-0710 > > E: matthew at crocker.com > P: (413) 746-2760 > F: (413) 746-3704 > W: http://www.crocker.com > > > > On Mar 3, 2014, at 8:11 PM, Eric A Louie wrote: > > > This may sound like dumb question, but... I'm used to asking those. > > > > Here's the scenario > > > > Another ISP, say AT&T, is the primary ISP for a customer. > > > > Customer has publicly accessible servers in their office, using the AT&T address space. > > > > I am the customer's secondary ISP. > > > > Now, if AT&T link fails, I can provide the customer outbound Internet access fairly easily. So they can surf and get to the Internet. > > > > What about the publicly accessible servers that have AT&T addresses, though? > > > > One thought I had was having them use Dynamic DNS service. > > > > Are there any other solutions, short of using BGP multihoming and having them try to get their own ASN and IPv4 /24 block? > > > > > > It looks like a few router manufacturers have devices that might work, but it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary ISP fails, the secondary ISP address is advertised. > > > > From cciehelps at gmail.com Tue Mar 4 03:16:12 2014 From: cciehelps at gmail.com (ku po) Date: Tue, 4 Mar 2014 11:16:12 +0800 Subject: AS path not optimal Message-ID: One of my client has peering with nlayer and a provider from Asia. It seems from one major ISP in US, the best path is through this Asia provider, instead of through nlayer which we want it to be. It seems this major ISP does not have a direct peering with nlayer AS 4436 is the cause of this problem. What is the best way to address this problem? From rcarpen at network1.net Tue Mar 4 03:20:42 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 3 Mar 2014 22:20:42 -0500 (EST) Subject: ISP inbound failover without BGP In-Reply-To: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> Is there some technical reason that BGP is not an option? You could allow them to announce their AT&T space via you as a secondary. -Randy ----- Original Message ----- > This may sound like dumb question, but... I'm used to asking those. > > Here's the scenario > > Another ISP, say AT&T, is the primary ISP for a customer. > > Customer has publicly accessible servers in their office, using the AT&T > address space. > > I am the customer's secondary ISP. > > Now, if AT&T link fails, I can provide the customer outbound Internet access > fairly easily.? So they can surf and get to the Internet. > > What about the publicly accessible servers that have AT&T addresses, though? > > One thought I had was having them use Dynamic DNS service. > > Are there any other solutions, short of using BGP multihoming and having them > try to get their own ASN and IPv4 /24 block? > > > It looks like a few router manufacturers have devices that might work, but it > looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the > primary ISP fails, the secondary ISP address is advertised. > > From elouie at yahoo.com Tue Mar 4 04:02:41 2014 From: elouie at yahoo.com (Eric A Louie) Date: Mon, 3 Mar 2014 20:02:41 -0800 (PST) Subject: ISP inbound failover without BGP In-Reply-To: References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com>, <5CE853F6-C5FB-46A9-94D9-11E4617CA849@corp.crocker.com> Message-ID: <1393905761.57674.YahooMailNeo@web181602.mail.ne1.yahoo.com> That's a good point Ray - thank you. >________________________________ > From: Ray >To: Matthew Crocker ; Eric A Louie >Cc: NANOG >Sent: Monday, March 3, 2014 6:31 PM >Subject: RE: ISP inbound failover without BGP > > > > >Depending on their business, using dynamic DNS providers could be a really bad idea. If they deal only with home users who won't even know, it'll probably work. If their customers are security-aware businesses, they probably block all sites hosted with dynamic DNS systems. > >Ray > > >> Subject: Re: ISP inbound failover without BGP >> From: matthew at corp.crocker.com >> Date: Mon, 3 Mar 2014 20:50:26 -0500 >> To: elouie at yahoo.com >> CC: nanog at nanog.org >> >> >> >> Depends on the application, >> >> SIP, VPN, SMTP, etc just setup both IPs and let the end-user application figure it out (SIP-UA register to both IPs for example) >> >> HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend the requests. Then it can load balance traffic over both IPs. >> >> DNS TTL ?tricks? are just that, they work ?kinda? >> >> Fatpipe? Crazy expensive IMHO but I hear they work ok. >> >> -Matt >> >> -- >> Matthew S. Crocker >> President >> Crocker Communications, Inc. >> PO BOX 710 >> Greenfield, MA 01302-0710 >> >> E: matthew at crocker.com >> P: (413) 746-2760 >> F: (413) 746-3704 >> W: http://www.crocker.com >> >> >> >> On Mar 3, 2014, at 8:11 PM, Eric A Louie wrote: >> >> > This may sound like dumb question, but... I'm used to asking those. >> > >> > Here's the scenario >> > >> > Another ISP, say AT&T, is the primary ISP for a customer. >> > >> > Customer has publicly accessible servers in their office, using the AT&T address space. >> > >> > I am the customer's secondary ISP. >> > >> > Now, if AT&T link fails, I can provide the customer outbound Internet access fairly easily. So they can surf and get to the Internet. >> > >> > What about the publicly accessible servers that have AT&T addresses, though? >> > >> > One thought I had was having them use Dynamic DNS service. >> > >> > Are there any other solutions, short of using BGP multihoming and having them try to get their own ASN and IPv4 /24 block? >> > >> > >> > It looks like a few router manufacturers have devices that might work, but it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary ISP fails, the secondary ISP address is advertised. >> > >> >> > > > From bill at herrin.us Tue Mar 4 04:19:36 2014 From: bill at herrin.us (William Herrin) Date: Mon, 3 Mar 2014 23:19:36 -0500 Subject: ISP inbound failover without BGP In-Reply-To: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Mon, Mar 3, 2014 at 8:11 PM, Eric A Louie wrote: > One thought I had was having them use Dynamic DNS service. > > Are there any other solutions, short of using BGP multihoming > and having them try to get their own ASN and IPv4 /24 block? Hi Eric, I went through this a couple years ago with continuity of operations planning. The bottom line is: with the notable exception of low-activity electronic mail, switching the address record in the DNS entry will generally not work as expected. For folks serious about reliable access to their servers, BGP isn't just the best way, it's the only way. Reasons why dynamic DNS fails to perform as expected include: * Web browser DNS pinning can result in a customer's web browser holding the old IP address indefinitely. * Host-level caching of looked up names which discards the TTL. Remember: your desktop or laptop performs lookups against multiple name services, e.g. DNS, /etc/hosts, lmhosts, NIS+. DNS TTL is no longer in scope once the name to address map enters the generic host lookup mechanism. Most OSes have a fixed timeout of one sort or another, some old ones as long as 24 hours. * Custom applications with either IP addresses hardcoded into the configuration or with getaddrinfo() called only once and the resulting IP address held for the lifetime of the application. * Anti-spam systems block IP addresses when receiving large quantities of email from formerly-quiescent IP addresses. This is a problem if your mail server sends a lot of email and suddenly switches to a new sending IP address. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From arturo.servin at gmail.com Tue Mar 4 04:30:53 2014 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 3 Mar 2014 20:30:53 -0800 Subject: ISP inbound failover without BGP In-Reply-To: <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> Message-ID: On Mon, Mar 3, 2014 at 7:20 PM, Randy Carpenter wrote: > Is there some technical reason that BGP is not an option? You could allow > them to announce their AT&T space via you as a secondary. unless it is a /26, /25 or something shorter. Even with a /24 things may get messy. IPv4 is coming to an end, but it is not possible for the customer to get their own space and use BGP? Regards, as From jgreco at ns.sol.net Tue Mar 4 00:48:33 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 3 Mar 2014 18:48:33 -0600 (CST) Subject: ISP inbound failover without BGP In-Reply-To: Message-ID: <201403040048.s240mY2C075171@aurora.sol.net> > Depending on their business=2C using dynamic DNS providers could be a reall= > y bad idea. If they deal only with home users who won't even know=2C it'll = > probably work. If their customers are security-aware businesses=2C they pro= > bably block all sites hosted with dynamic DNS systems. Where do dynamic DNS /providers/ enter the picture? You update *your own* DNS records. Those could conceivably be hosted with a dynamic DNS provider, but why not just use the API for whatever system you currently use for DNS? ... 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 elouie at yahoo.com Tue Mar 4 04:49:21 2014 From: elouie at yahoo.com (Eric A Louie) Date: Mon, 3 Mar 2014 20:49:21 -0800 (PST) Subject: ISP inbound failover without BGP In-Reply-To: <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> Message-ID: <1393908561.37682.YahooMailNeo@web181604.mail.ne1.yahoo.com> Honestly?? Because the end-customers are not technically competent enough to run dual-homed BGP, and we don't want to be their managed service providers on the IT side.? And announcing the AT&T space is fine until something goes wrong, and I have to troubleshoot the problem (Customer - "How come AT&T is down, and we're not getting inbound traffic to our servers?", and I discover L3 or CenturyLink isn't accepting my advertisement for some weird reason, but they won't fess up to it for a few frustrating hours) >________________________________ > From: Randy Carpenter >To: Eric A Louie >Cc: NANOG >Sent: Monday, March 3, 2014 7:20 PM >Subject: Re: ISP inbound failover without BGP > > > >Is there some technical reason that BGP is not an option? You could allow them to announce their AT&T space via you as a secondary. > >-Randy > >----- Original Message ----- >> This may sound like dumb question, but... I'm used to asking those. >> >> Here's the scenario >> >> Another ISP, say AT&T, is the primary ISP for a customer. >> >> Customer has publicly accessible servers in their office, using the AT&T >> address space. >> >> I am the customer's secondary ISP. >> >> Now, if AT&T link fails, I can provide the customer outbound Internet access >> fairly easily.? So they can surf and get to the Internet. >> >> What about the publicly accessible servers that have AT&T addresses, though? >> >> One thought I had was having them use Dynamic DNS service. >> >> Are there any other solutions, short of using BGP multihoming and having them >> try to get their own ASN and IPv4 /24 block? >> >> >> It looks like a few router manufacturers have devices that might work, but it >> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the >> primary ISP fails, the secondary ISP address is advertised. >> >> > > > From streiner at cluebyfour.org Tue Mar 4 01:56:35 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 3 Mar 2014 20:56:35 -0500 (EST) Subject: ISP inbound failover without BGP In-Reply-To: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Mon, 3 Mar 2014, Eric A Louie wrote: > Are there any other solutions, short of using BGP multihoming and > having them try to get their own ASN and IPv4 /24 block? For what it sounds like the customer wants to do, this really is the right solution. Most everything else has some level of 'ugly hack' attached to it, that can cause reliability/reachability problems at inopportune times (as opposed to problems that happen at opportune times). If the customer is just looking for failover capabilities, they can take default via BGP from both providers, prefer one over the other, and use some other bits to prefer one provider over for inbound connectivity. They would not need very beefy routers for this. That will get you basic service redundancy. Add a second router, and they can have some protection in the event of a router failure. It all really boils down to what the customer wants and is willing to pay for. If they have services that need to be reliably reachable, then using a time-tested design is a prudent decision. jms From faisal at snappytelecom.net Tue Mar 4 05:09:04 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 4 Mar 2014 05:09:04 +0000 (GMT) Subject: ISP inbound failover without BGP In-Reply-To: <1393908561.37682.YahooMailNeo@web181604.mail.ne1.yahoo.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> <1393908561.37682.YahooMailNeo@web181604.mail.ne1.yahoo.com> Message-ID: <1545519894.131446.1393909744049.JavaMail.root@snappytelecom.net> There are other elaborate solutions to accomplish this, however all of them would require a competent IT/Network Person to manage the network. If we were the ISP, we would look at such a case an an opportunity, and become the managed service provider, for a fee (typically a premium), and provide the service. As service providers, we all complain about the end-customer being a pain, but we often forget that it the the PITA end-customers that give us the ability to earn our daily bread!.... I think too many of us are overworked and providing highly under-paid services for peanuts, where we often overlook at opportunities to get premium value as a PITA, and not worth it... :) Just my personal two cents,..... Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Eric A Louie" > To: "Randy Carpenter" > Cc: "NANOG" > Sent: Monday, March 3, 2014 11:49:21 PM > Subject: Re: ISP inbound failover without BGP > > Honestly?? Because the end-customers are not technically competent enough to > run dual-homed BGP, and we don't want to be their managed service providers > on the IT side.? And announcing the AT&T space is fine until something goes > wrong, and I have to troubleshoot the problem (Customer - "How come AT&T is > down, and we're not getting inbound traffic to our servers?", and I discover > L3 or CenturyLink isn't accepting my advertisement for some weird reason, > but they won't fess up to it for a few frustrating hours) > > > > > > >________________________________ > > From: Randy Carpenter > >To: Eric A Louie > >Cc: NANOG > >Sent: Monday, March 3, 2014 7:20 PM > >Subject: Re: ISP inbound failover without BGP > > > > > > > >Is there some technical reason that BGP is not an option? You could allow > >them to announce their AT&T space via you as a secondary. > > > >-Randy > > > >----- Original Message ----- > >> This may sound like dumb question, but... I'm used to asking those. > >> > >> Here's the scenario > >> > >> Another ISP, say AT&T, is the primary ISP for a customer. > >> > >> Customer has publicly accessible servers in their office, using the AT&T > >> address space. > >> > >> I am the customer's secondary ISP. > >> > >> Now, if AT&T link fails, I can provide the customer outbound Internet > >> access > >> fairly easily.? So they can surf and get to the Internet. > >> > >> What about the publicly accessible servers that have AT&T addresses, > >> though? > >> > >> One thought I had was having them use Dynamic DNS service. > >> > >> Are there any other solutions, short of using BGP multihoming and having > >> them > >> try to get their own ASN and IPv4 /24 block? > >> > >> > >> It looks like a few router manufacturers have devices that might work, but > >> it > >> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the > >> primary ISP fails, the secondary ISP address is advertised. > >> > >> > > > > > > > From streiner at cluebyfour.org Tue Mar 4 02:02:17 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 3 Mar 2014 21:02:17 -0500 (EST) Subject: ISP inbound failover without BGP In-Reply-To: <1393908561.37682.YahooMailNeo@web181604.mail.ne1.yahoo.com> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> <1393908561.37682.YahooMailNeo@web181604.mail.ne1.yahoo.com> Message-ID: On Mon, 3 Mar 2014, Eric A Louie wrote: > Honestly?? Because the end-customers are not technically competent > enough to run dual-homed BGP, and we don't want to be their managed > service providers on the IT side.? And announcing the AT&T space is fine > until something goes wrong, and I have to troubleshoot the problem > (Customer - "How come AT&T is down, and we're not getting inbound > traffic to our servers?", and I discover L3 or CenturyLink isn't > accepting my advertisement for some weird reason, but they won't fess up > to it for a few frustrating hours) If they're not technically competent enough to handle BGP, they won't be technically competent enough to deal with solutions that play the short DNS TTL game. As someone else mentioned in this thread - would colocating the servers be a workable solution for them? Put the servers some place where the redundancy exists already. jms From sethm at rollernet.us Tue Mar 4 05:14:29 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 03 Mar 2014 21:14:29 -0800 Subject: ISP inbound failover without BGP In-Reply-To: <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> Message-ID: <53156135.3030902@rollernet.us> On 3/3/14, 7:20 PM, Randy Carpenter wrote: > Is there some technical reason that BGP is not an option? You could allow them to announce their AT&T space via you as a secondary. With the risk of starting holy war on how BGP works on dialup and that providers should permit such, the OP has not specified what transport methods is in play with AT&T which could limit such an option. ~Seth From dmiller at tiggee.com Tue Mar 4 05:37:37 2014 From: dmiller at tiggee.com (David Miller) Date: Tue, 04 Mar 2014 00:37:37 -0500 Subject: AS path not optimal In-Reply-To: References: Message-ID: <531566A1.50608@tiggee.com> On 03/03/2014 10:16 PM, ku po wrote: > One of my client has peering with nlayer and a provider from Asia. It seems > from one major ISP in US, the best path is through this Asia provider, > instead of through nlayer which we want it to be. > > It seems this major ISP does not have a direct peering with nlayer AS 4436 > is the cause of this problem. > > What is the best way to address this problem? > Add BGP communities to your client's announcements directing the Asia provider to prepend their AS X times (whatever value of X works best for you) on passing your client's prefixes to that major ISP in the US. The Asia provider should be able to provide you a list of their BGP control communities. -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From jlewis at lewis.org Tue Mar 4 05:38:10 2014 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 4 Mar 2014 00:38:10 -0500 (EST) Subject: ISP inbound failover without BGP In-Reply-To: References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> <1393908561.37682.YahooMailNeo@web181604.mail.ne1.yahoo.com> Message-ID: On Mon, 3 Mar 2014, Justin M. Streiner wrote: > If they're not technically competent enough to handle BGP, they won't be > technically competent enough to deal with solutions that play the short DNS > TTL game. > > As someone else mentioned in this thread - would colocating the servers be a > workable solution for them? Put the servers some place where the redundancy > exists already. My vote goes to the traditional BGP multihomed solution. It's the right way to solve the problem and the easiest to manage. If getting AT&T to do BGP and buying a BGP capable router (they don't even need full routes...so so anything that'll speak BGP, take a pair of default routes, and handle whatever their traffic level is will do) is too costly[1], another possible option I've not seen mentioned is VPN. They could put one machine/router somewhere with decent redundancy and setup a VPN gateway at their office that connects to the colo'd device. You might even offer this as a service. Spammers have been doing this for years. It makes moving their operations easier as their public facing servers get cancelled. All they do is move the VPN server(s) and their systems that do all the "work" remain online and hidden. [1] If only I had a dollar for every time a client said redundancy was too expensive to have, but when their non-redundant stuff went offline, they claimed to be losing millions of $ per small unit of time. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hank at efes.iucc.ac.il Tue Mar 4 07:20:43 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 04 Mar 2014 09:20:43 +0200 Subject: ISP inbound failover without BGP Message-ID: <20140304072049.1EC6E56015@doar.tau.ac.il> Have them look at radware linkproof which is designed for small shops that don't want to do bgp and getting their own ASN and pi address space.? Been around since 1999. http://www.radware.com/Products/LinkProof/ Hank On Mar 4, 2014 3:11 AM, Eric A Louie wrote: > > This may sound like dumb question, but... I'm used to asking those. > > Here's the scenario > > Another ISP, say AT&T, is the primary ISP for a customer. > > Customer has publicly accessible servers in their office, using the AT&T address space. > > I am the customer's secondary ISP. > > Now, if AT&T link fails, I can provide the customer outbound Internet access fairly easily.? So they can surf and get to the Internet. > > What about the publicly accessible servers that have AT&T addresses, though? > > One thought I had was having them use Dynamic DNS service.? > > Are there any other solutions, short of using BGP multihoming and having them try to get their own ASN and IPv4 /24 block? > > It looks like a few router manufacturers have devices that might work, but it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary ISP fails, the secondary ISP address is advertised. From joelja at bogus.com Tue Mar 4 07:28:38 2014 From: joelja at bogus.com (joel jaeggli) Date: Tue, 04 Mar 2014 07:28:38 +0000 Subject: AS path not optimal In-Reply-To: References: Message-ID: <531580A6.4030800@bogus.com> On 3/4/14, 3:16 AM, ku po wrote: > One of my client has peering with nlayer and a provider from Asia. It seems > from one major ISP in US, the best path is through this Asia provider, > instead of through nlayer which we want it to be. > > It seems this major ISP does not have a direct peering with nlayer AS 4436 > is the cause of this problem. > > What is the best way to address this problem? For exit selection, tag the routes you want to influence with a community and then apply a higher localpref to routes from that community. if inbound is also coming from asia you should explore prepending towards that provider via provider communities or in your advertisement directly (the later obviously is gross) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From jra at baylink.com Tue Mar 4 08:00:18 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 04 Mar 2014 03:00:18 -0500 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica Message-ID: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-routers-make-malicious-changes/ Is there any valid reason not to black hole those /32s on the back bone? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From vovan at fakmoymozg.ru Tue Mar 4 11:46:20 2014 From: vovan at fakmoymozg.ru (fmm) Date: Tue, 04 Mar 2014 12:46:20 +0100 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> Message-ID: On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote: > http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-routers-make-malicious-changes/ > > Is there any valid reason not to black hole those /32s on the back bone? >> The telltale sign a router has been compromised is DNS settings that >> have been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers >> contacted the provider that hosts those two IP addresses but have yet >> to receive a response. you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't you? Cheers From lathama at gmail.com Tue Mar 4 11:54:40 2014 From: lathama at gmail.com (Andrew Latham) Date: Tue, 4 Mar 2014 05:54:40 -0600 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> Message-ID: On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote: > On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote: > >> >> http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-routers-make-malicious-changes/ >> >> Is there any valid reason not to black hole those /32s on the back bone? > > > >>> The telltale sign a router has been compromised is DNS settings that have >>> been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted >>> the provider that hosts those two IP addresses but have yet to receive a >>> response. > > > you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't > you? > > > Cheers > Jay is right, it is just the /32s at the moment... Dropping the /22s could cause other sites to be blocked. inetnum: 5.45.72.0 - 5.45.75.255 netname: INFERNO-NL-DE descr: ******************************************************** descr: * We provide virtual and dedicated servers on this Subnet. descr: * descr: * Those services are self managed by our customers descr: * therefore, we are not using this IP space ourselves descr: * and it could be assigned to various end customers. descr: * descr: * In case of issues related with SPAM, Fraud, descr: * Phishing, DDoS, portscans or others, descr: * feel free to contact us with relevant info descr: * and we will shut down this server: abuse at 3nt.com descr: ******************************************************** country: NL admin-c: TNTS-RIPE tech-c: TNTS-RIPE status: ASSIGNED PA mnt-by: MNT-3NT mnt-routes: serverius-mnt source: RIPE # Filtered -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From diotonante at gmail.com Tue Mar 4 13:27:10 2014 From: diotonante at gmail.com (Davide Davini) Date: Tue, 04 Mar 2014 14:27:10 +0100 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> Message-ID: <5315D4AE.5030505@gmail.com> Andrew Latham wrote: > On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote: >> On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote: >> >>> >>> http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-routers-make-malicious-changes/ >>> >>> Is there any valid reason not to black hole those /32s on the back bone? >> >> >> >>>> The telltale sign a router has been compromised is DNS settings that have >>>> been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted >>>> the provider that hosts those two IP addresses but have yet to receive a >>>> response. >> >> >> you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't >> you? >> > > Jay is right, it is just the /32s at the moment... Dropping the /22s > could cause other sites to be blocked. > > inetnum: 5.45.72.0 - 5.45.75.255 > netname: INFERNO-NL-DE I'm guessing that was said under the assumption the provider wouldn't intervene, because if it does intervene there is no point in blackholig anything. From deleskie at gmail.com Tue Mar 4 13:28:01 2014 From: deleskie at gmail.com (jim deleskie) Date: Tue, 4 Mar 2014 09:28:01 -0400 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> Message-ID: Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's. Set up a DNS server locally to reply to those IP's Your customers stay up and running and blissfully unaware. Log the IP's hitting your DNS servers on those IP and have your support reach out to them in a controlled way, or reply to any request via DNS with an internal host that has a web page explaining what is broken and how they can fix it avoiding at least some of the calls to your helpdesk. -jim On Tue, Mar 4, 2014 at 7:54 AM, Andrew Latham wrote: > On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote: > > On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth > wrote: > > > >> > >> > http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-routers-make-malicious-changes/ > >> > >> Is there any valid reason not to black hole those /32s on the back bone? > > > > > > > >>> The telltale sign a router has been compromised is DNS settings that > have > >>> been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers > contacted > >>> the provider that hosts those two IP addresses but have yet to receive > a > >>> response. > > > > > > you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", > aren't > > you? > > > > > > Cheers > > > > Jay is right, it is just the /32s at the moment... Dropping the /22s > could cause other sites to be blocked. > > inetnum: 5.45.72.0 - 5.45.75.255 > netname: INFERNO-NL-DE > descr: ******************************************************** > descr: * We provide virtual and dedicated servers on this Subnet. > descr: * > descr: * Those services are self managed by our customers > descr: * therefore, we are not using this IP space ourselves > descr: * and it could be assigned to various end customers. > descr: * > descr: * In case of issues related with SPAM, Fraud, > descr: * Phishing, DDoS, portscans or others, > descr: * feel free to contact us with relevant info > descr: * and we will shut down this server: abuse at 3nt.com > descr: ******************************************************** > country: NL > admin-c: TNTS-RIPE > tech-c: TNTS-RIPE > status: ASSIGNED PA > mnt-by: MNT-3NT > mnt-routes: serverius-mnt > source: RIPE # Filtered > > > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > From lathama at gmail.com Tue Mar 4 13:30:06 2014 From: lathama at gmail.com (Andrew Latham) Date: Tue, 4 Mar 2014 07:30:06 -0600 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: <5315D4AE.5030505@gmail.com> References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> <5315D4AE.5030505@gmail.com> Message-ID: On Tue, Mar 4, 2014 at 7:27 AM, Davide Davini wrote: > Andrew Latham wrote: >> On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote: >>> On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote: >>> >>>> >>>> http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-routers-make-malicious-changes/ >>>> >>>> Is there any valid reason not to black hole those /32s on the back bone? >>> >>> >>> >>>>> The telltale sign a router has been compromised is DNS settings that have >>>>> been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted >>>>> the provider that hosts those two IP addresses but have yet to receive a >>>>> response. >>> >>> >>> you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't >>> you? >>> >> >> Jay is right, it is just the /32s at the moment... Dropping the /22s >> could cause other sites to be blocked. >> >> inetnum: 5.45.72.0 - 5.45.75.255 >> netname: INFERNO-NL-DE > > I'm guessing that was said under the assumption the provider wouldn't > intervene, because if it does intervene there is no point in blackholig > anything. > Davide, you are correct, some people are assuming that the provider is doing nothing. That has yet to be determined. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From s+Mailinglisten.nanog at sloc.de Tue Mar 4 14:16:19 2014 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Tue, 04 Mar 2014 15:16:19 +0100 Subject: ISP inbound failover without BGP In-Reply-To: References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <5315E033.2030503@sloc.de> Am 04.03.2014 05:19, schrieb William Herrin: > Reasons why dynamic DNS fails to perform as expected include: > > * Web browser DNS pinning can result in a customer's web browser > holding the old IP address indefinitely. > > * Host-level caching of looked up names which discards the TTL. > Remember: your desktop or laptop performs lookups against multiple > name services, e.g. DNS, /etc/hosts, lmhosts, NIS+. DNS TTL is no > longer in scope once the name to address map enters the generic host > lookup mechanism. Most OSes have a fixed timeout of one sort or > another, some old ones as long as 24 hours. * Eyeball ISPs' DNS resolvers might tamper with TTL values. -- SEBASTIAN SPIES lnked.in/sspies vastly.de From vristevs at ramapo.edu Tue Mar 4 14:27:58 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 04 Mar 2014 09:27:58 -0500 Subject: ISP inbound failover without BGP In-Reply-To: <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> References: <1393895467.63537.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1473335835.293638.1393903242317.JavaMail.zimbra@network1.net> Message-ID: <5315E2EE.7090907@ramapo.edu> I've been doing the suggestion below for many years using the IP addresses that Cogent gives us. All I needed to do is get LOA from them and submit it to my backup ISP. I've never had an issue with my Cogent IP's *not* being advertised by my other ISP and I really don't think there is very much management overhead for the customer once this is setup. I have an SNMP based alerting system (Cacti) set up so I can be alerted if too much traffic ever "shifts" to the backup link. The client getting their own ASN is the better way to go but you should be able to do the above until that comes through. On 3/3/2014 10:20 PM, Randy Carpenter wrote: > Is there some technical reason that BGP is not an option? You could allow them to announce their AT&T space via you as a secondary. > > -Randy > > ----- Original Message ----- >> This may sound like dumb question, but... I'm used to asking those. >> >> Here's the scenario >> >> Another ISP, say AT&T, is the primary ISP for a customer. >> >> Customer has publicly accessible servers in their office, using the AT&T >> address space. >> >> I am the customer's secondary ISP. >> >> Now, if AT&T link fails, I can provide the customer outbound Internet access >> fairly easily. So they can surf and get to the Internet. >> >> What about the publicly accessible servers that have AT&T addresses, though? >> >> One thought I had was having them use Dynamic DNS service. >> >> Are there any other solutions, short of using BGP multihoming and having them >> try to get their own ASN and IPv4 /24 block? >> >> >> It looks like a few router manufacturers have devices that might work, but it >> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the >> primary ISP fails, the secondary ISP address is advertised. >> >> -- Vlad From Valdis.Kletnieks at vt.edu Tue Mar 4 14:54:12 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Mar 2014 09:54:12 -0500 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: Your message of "Tue, 04 Mar 2014 09:28:01 -0400." References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> Message-ID: <45536.1393944852@turing-police.cc.vt.edu> On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said: > Why want to swing such a big hammer. Even blocking those 2 IP's will > isolate your users, and fill your support queue's. > > Set up a DNS server locally to reply to those IP's Your customers stay up > and running and blissfully unaware. > > Log the IP's hitting your DNS servers on those IP and have your support > reach out to them in a controlled way, or reply to any request via DNS > with an internal host that has a web page explaining what is broken and how > they can fix it avoiding at least some of the calls to your helpdesk. Two words: "DNS Changer". What did we learn from that? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jra at baylink.com Tue Mar 4 17:38:24 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Mar 2014 12:38:24 -0500 (EST) Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: <31526540.10828.1393954686517.JavaMail.root@benjamin.baylink.com> Message-ID: <7736908.10830.1393954704222.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Andrew Latham" > > you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", > Jay is right, it is just the /32s at the moment... Dropping the /22s > could cause other sites to be blocked. > > inetnum: 5.45.72.0 - 5.45.75.255 > netname: INFERNO-NL-DE > descr: ******************************************************** > descr: * We provide virtual and dedicated servers on this Subnet. > descr: * > descr: * Those services are self managed by our customers > descr: * therefore, we are not using this IP space ourselves > descr: * and it could be assigned to various end customers. > descr: * > descr: * In case of issues related with SPAM, Fraud, > descr: * Phishing, DDoS, portscans or others, > descr: * feel free to contact us with relevant info > descr: * and we will shut down this server: abuse at 3nt.com > descr: ******************************************************** > country: NL > admin-c: TNTS-RIPE > tech-c: TNTS-RIPE > status: ASSIGNED PA > mnt-by: MNT-3NT > mnt-routes: serverius-mnt > source: RIPE # Filtered Though, for the record, I see I have ssh bruteforce in my logs this week from 5.39.223.8; what it is with 5/8 this month? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Tue Mar 4 17:41:19 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Mar 2014 12:41:19 -0500 (EST) Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: Message-ID: <1802596.10832.1393954879768.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "jim deleskie" > Why swing such a big hammer. Even blocking those 2 IP's will > isolate your users, and fill your support queue's. > > Set up a DNS server locally to reply to those IP's Your customers stay up > and running and blissfully unaware. > > Log the IP's hitting your DNS servers on those IP and have your support > reach out to them in a controlled way, or reply to any request via DNS > with an internal host that has a web page explaining what is broken > and how they can fix it avoiding at least some of the calls to your helpdesk. Jim's right, of course. In my defense, it *was* 9 am, and I hadn't had any caffeine yet. ;-} Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From alvarezp at alvarezp.ods.org Tue Mar 4 18:06:13 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 04 Mar 2014 10:06:13 -0800 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> Message-ID: <53161615.6040604@alvarezp.ods.org> On 03/04/2014 05:28 AM, jim deleskie wrote: > Why want to swing such a big hammer. Even blocking those 2 IP's will > isolate your users, and fill your support queue's. When the malicious DNS services get shutdown you will still have your support queue's filled, anyway. Doing it now will let you identify those affected. Blockage doesn't have to be all-or-nothing. It can be incremental, selective or all-or-nothing on some time windows. Better now than later. From iam at st-andrews.ac.uk Tue Mar 4 18:33:46 2014 From: iam at st-andrews.ac.uk (Ian McDonald) Date: Tue, 4 Mar 2014 18:33:46 +0000 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: <53161615.6040604@alvarezp.ods.org> References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> , <53161615.6040604@alvarezp.ods.org> Message-ID: Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole. So long as there's an 'I have a clue' opt out, it appears to be the way forward to resolve this issue. Shutting down one set of 'bad resolvers' will simply cause a new set to be spawned, and a reinfection run round the still-unpatched cpe's of the world. Thanks -- ian Sent from my phone, please excuse brevity and misspelling. ________________________________ From: Octavio Alvarez Sent: ?04/?03/?2014 18:09 To: jim deleskie; Andrew Latham Cc: nanog at nanog.org Subject: Re: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica On 03/04/2014 05:28 AM, jim deleskie wrote: > Why want to swing such a big hammer. Even blocking those 2 IP's will > isolate your users, and fill your support queue's. When the malicious DNS services get shutdown you will still have your support queue's filled, anyway. Doing it now will let you identify those affected. Blockage doesn't have to be all-or-nothing. It can be incremental, selective or all-or-nothing on some time windows. Better now than later. From brandon.galbraith at gmail.com Tue Mar 4 18:48:09 2014 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 4 Mar 2014 12:48:09 -0600 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> <53161615.6040604@alvarezp.ods.org> Message-ID: On Tue, Mar 4, 2014 at 12:33 PM, Ian McDonald wrote: > Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole. So long as there's an 'I have a clue' opt out, it appears to be the way forward to resolve this issue. Shutting down one set of 'bad resolvers' will simply cause a new set to be spawned, and a reinfection run round the still-unpatched cpe's of the world. +1. Local network resolvers/trusted providers (Google 8.8., OpenDNS), "Clue Opt Out" switch available if needed. From mysidia at gmail.com Tue Mar 4 19:10:19 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 4 Mar 2014 13:10:19 -0600 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> <53161615.6040604@alvarezp.ods.org> Message-ID: On Tue, Mar 4, 2014 at 12:33 PM, Ian McDonald wrote: > Until the average user's cpe is only permitted to use the resolvers one > has provided as the provider (or otherwise decided are OK), this is going > to be a game of whackamole. No. That is still just treating symptoms, and not the disease. This also creates an unacceptable annoyance for the most slightly technical user who needs to troubleshoot any DNS problems with their domains. When the ISP's nameservers are blocked, the script kiddies will set up a tunnel, or configure the DNS client to use a different UDP port number for DNS resolution, or adjust the router firmware to run tcpdump and upload session data to/from interesting web destinations, to a hostname on port 80. -- -JH From kaeo at merike.com Tue Mar 4 19:52:02 2014 From: kaeo at merike.com (Merike Kaeo) Date: Tue, 4 Mar 2014 11:52:02 -0800 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: <45536.1393944852@turing-police.cc.vt.edu> References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> <45536.1393944852@turing-police.cc.vt.edu> Message-ID: <853C4F11-74FC-4027-8771-8964631C02FE@merike.com> On Mar 4, 2014, at 6:54 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said: >> Why want to swing such a big hammer. Even blocking those 2 IP's will >> isolate your users, and fill your support queue's. >> >> Set up a DNS server locally to reply to those IP's Your customers stay up >> and running and blissfully unaware. >> >> Log the IP's hitting your DNS servers on those IP and have your support >> reach out to them in a controlled way, or reply to any request via DNS >> with an internal host that has a web page explaining what is broken and how >> they can fix it avoiding at least some of the calls to your helpdesk. > > Two words: "DNS Changer". What did we learn from that? My thoughts exactly. Some walled gardens set up in those instances. And don't blindly follow someone's advice without looking at impacts to your networks. CPE devices are just a huge cesspool. Any device that already doesn't let you change username 'admin' is off to a bad start. We have to get these supposedly 'plug it in and never touch it' devices to be better at firmware upgrades. - merike From wbailey at satelliteintelligencegroup.com Tue Mar 4 19:59:57 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 4 Mar 2014 19:59:57 +0000 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: <853C4F11-74FC-4027-8771-8964631C02FE@merike.com> References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> <45536.1393944852@turing-police.cc.vt.edu> <853C4F11-74FC-4027-8771-8964631C02FE@merike.com> Message-ID: I don?t know that they have a lot of motivation to support ?legacy? access points. The home brew guys tend to magically ?find? ways to install software on these POS CPE AP/Router combos, which I don?t think is a coincidence. The linksys types of the world want to sell more routers, not make routers that suddenly have an amazing 8 year shelf life. Most people get tired of that POS box that gives them internet not working, and buy a new LESS POS with whatever 802.xxx of the week/month/year/shopping season. The margins probably really suck if you support a piece of plastic longer than __ months, so I doubt you?ll see anyone supporting their cheap box any time soon. I bet if you offered them a way to do it for free, they?d look at it ;) On 3/4/14, 11:52 AM, "Merike Kaeo" wrote: > >On Mar 4, 2014, at 6:54 AM, Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said: >>> Why want to swing such a big hammer. Even blocking those 2 IP's will >>> isolate your users, and fill your support queue's. >>> >>> Set up a DNS server locally to reply to those IP's Your customers >>>stay up >>> and running and blissfully unaware. >>> >>> Log the IP's hitting your DNS servers on those IP and have your support >>> reach out to them in a controlled way, or reply to any request via DNS >>> with an internal host that has a web page explaining what is broken >>>and how >>> they can fix it avoiding at least some of the calls to your helpdesk. >> >> Two words: "DNS Changer". What did we learn from that? > >My thoughts exactly. Some walled gardens set up in those instances. > >And don't blindly follow someone's advice without looking at impacts to >your >networks. > >CPE devices are just a huge cesspool. Any device that already doesn't >let you >change username 'admin' is off to a bad start. We have to get these >supposedly >'plug it in and never touch it' devices to be better at firmware upgrades. > >- merike From niels=nanog at bakker.net Tue Mar 4 20:51:01 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 4 Mar 2014 21:51:01 +0100 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> <45536.1393944852@turing-police.cc.vt.edu> <853C4F11-74FC-4027-8771-8964631C02FE@merike.com> Message-ID: <20140304205101.GD48842@burnout.tpb.net> >On 3/4/14, 11:52 AM, "Merike Kaeo" wrote: >>CPE devices are just a huge cesspool. Any device that already >>doesn't let you change username 'admin' is off to a bad start. We >>have to get these supposedly 'plug it in and never touch it' >>devices to be better at firmware upgrades. * wbailey at satelliteintelligencegroup.com (Warren Bailey) [Tue 04 Mar 2014, 21:00 CET]: >I don't know that they have a lot of motivation to support "legacy" >access points. The home brew guys tend to magically "find" ways to >install software on these POS CPE AP/Router combos, which I don't >think is a coincidence. The linksys types of the world want to sell >more routers, not make routers that suddenly have an amazing 8 year >shelf life. Most people get tired of that POS box that gives them >internet not working, and buy a new LESS POS with whatever 802.xxx >of the week/month/year/shopping season. The margins probably really >suck if you support a piece of plastic longer than __ months, so I >doubt you?ll see anyone supporting their cheap box any time soon. I >bet if you offered them a way to do it for free, they'd look at it >;) Cisco tried doing this while they still owned Linksys and got huge blowback from the community, who felt that they'd lost control over their own devices and the data passing through them. https://www.techdirt.com/articles/20120629/15451719541/you-dont-own-what-you-buy-part-15332-cisco-forces-questionable-new-firmware-routers.shtml http://arstechnica.com/civis/viewtopic.php?f=2&t=1177772 (whole thread) http://blogs.cisco.com/home/update-answering-our-customers-questions-about-cisco-connect-cloud-2/ (I fixed your quotes, by the way. You may want to engage with your postmaster to unfuck your mail client's character set.) -- Niels. From alvarezp at alvarezp.ods.org Tue Mar 4 21:24:32 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 04 Mar 2014 13:24:32 -0800 Subject: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica In-Reply-To: References: <84697a3f-5415-4ee9-ab11-ec3ab8e7f608@email.android.com> , <53161615.6040604@alvarezp.ods.org> Message-ID: <53164490.5060602@alvarezp.ods.org> On 04/03/14 10:33, Ian McDonald wrote: > Until the average user's cpe is only permitted to use the resolvers one > has provided as the provider (or otherwise decided are OK), this is > going to be a game of whackamole. So long as there's an 'I have a clue' > opt out, it appears to be the way forward to resolve this issue. > Shutting down one set of 'bad resolvers' will simply cause a new set to > be spawned, and a reinfection run round the still-unpatched cpe's of the > world. Hi. That's a method for just temporarily managing the situation, not fixing it. If a techie opts-out, it doesn't mean other non tech-savvy users behind the same CPE won't go to a bad website and infect the vulnerable CPE. Once in this situation, it is *very* difficult The clueful user to find out. Most operators don't have an opt-out for SOHO services or it's a pain in the $BODYPART because of the dynamic nature of the SOHO services and the proper static identification of each user among the mass of not tech-savvy users. I've been through that as a user. The root of the problem is an unpatched CPE, that's right. The ISP is responsible for fixing that in pretty much all its own SOHO networks. It all boils down to finding the affected users and patching the CPEs. That has the additional benefit of involving the upstream CPE vendor. Best regards. From bruns at 2mbit.com Tue Mar 4 21:38:32 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 04 Mar 2014 14:38:32 -0700 Subject: Any CenturyLink IPv6 engineers/tech people around? Message-ID: <531647D8.4040701@2mbit.com> Hello all, Don't suppose there's any CenturyLink engineers/tech people on this list that can look into a problem with their IPv6 6rd service? Got multiple customers on CenturyLink (including myself), with IPv6 through their 6rd service since native isn't available yet. IPv6 assignments from one customer can't talk to IPv6 assignments on another CL customer. Seems to be in the 6rd server end doing it, as I can set up a direct tunnel between customers and it passes IPv6 traffic normally. I can provide more details and some tests if needed from my end. Thanks! -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jra at baylink.com Wed Mar 5 03:07:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Mar 2014 22:07:56 -0500 (EST) Subject: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <20140304201743.GB29640@vortex.com> Message-ID: <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> Oh hell. Is this the *same* bug that just broke in Apple code last week? Cheers, -- jra ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" > To: privacy-list at vortex.com > Sent: Tuesday, March 4, 2014 3:17:43 PM > Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping > Critical crypto bug leaves Linux, hundreds of apps open to > eavesdropping > > http://j.mp/1jPcVOr (Ars Technica) > > "Hundreds of open source packages, including the Red Hat, Ubuntu, and > Debian distributions of Linux, are susceptible to attacks that > circumvent the most widely used technology to prevent eavesdropping on > the Internet, thanks to an extremely critical vulnerability in a > widely used cryptographic code library. The bug in the GnuTLS library > makes it trivial for attackers to bypass secure sockets layer (SSL) > and Transport Layer Security (TLS) protections available on websites > that depend on the open source package. Initial estimates included in > Internet discussions such as this one indicate that more than 200 > different operating systems or applications rely on GnuTLS to > implement crucial SSL and TLS operations, but it wouldn't be > surprising if the actual number is much higher. Web applications, > e-mail programs, and other code that use the library are vulnerable to > exploits that allow attackers monitoring connections to silently > decode encrypted traffic passing between end users and servers. The > bug is the result of commands in a section of the GnuTLS code that > verify the authenticity of TLS certificates, which are often known > simply as X509 certificates." > > - - - > > --Lauren-- > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Member: ACM Committee on Computers and Public Policy > Lauren's Blog: http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > _______________________________________________ > privacy mailing list > http://lists.vortex.com/mailman/listinfo/privacy -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mark at viviotech.net Wed Mar 5 04:40:37 2014 From: mark at viviotech.net (Mark Keymer) Date: Tue, 04 Mar 2014 20:40:37 -0800 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. Message-ID: <5316AAC5.6090109@viviotech.net> Hi Everyone, So I have a client who moved a domain specifically periodforgood.com to a new VPS with our company. DNS has been updated and the TTL time is 4 hours so things should all be updated but something might still be wrong. Looking for help / confirmation that things look good. And better yet if someone from Cox and take a look. Our client uses Cox for there home internet and sometimes the domain resolves and sometimes it does not. We found they have the following IP's in Cox's network that are being used to resolve domains. 68.105.28.11 68.105.28.12 68.105.29.12 After doing many nslookups via a remote session to there computer we found that the top 2 IP's never resolve the periodforgood.com domain and we found that the third one will about 20%-40% of the time resolve it. We have gone to several DNS testing tools and all seems to be in order. If you dig or nslookup directly to the DNS servers that are used for the domain it seems to always respond. I admit I might just be overlooking something myself and will feel dumb once someone points it out to me. But if you can point it out to me that would be great! Also note that it looks like those DNS resolvers are blocked from outside lookups which is good. So maybe someone with some eyeballs inside or otherwise can help out? Sincerely, -- Mark Keymer CFO/COO Vivio Technologies From trelane at trelane.net Wed Mar 5 05:00:25 2014 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 05 Mar 2014 00:00:25 -0500 Subject: AT&T uverse ipv6 engineer Message-ID: <5316AF69.2080803@trelane.net> Would an AT&T engineer who deals with uverse IPv6 please contact me off list? I'm getting horrible throughput on your 6RD. Thanks! Andrew From contact at winterei.se Wed Mar 5 06:00:18 2014 From: contact at winterei.se (Paul S.) Date: Wed, 05 Mar 2014 15:00:18 +0900 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <5316AAC5.6090109@viviotech.net> References: <5316AAC5.6090109@viviotech.net> Message-ID: <5316BD72.3000703@winterei.se> For all it's worth, it might be Cox ignoring TTLs and enforcing their own update times instead. Wait 24-48 hours, and it should probably fix it all up. I'm not seeing anything majorly broken with your system except the SOA EXPIRE being ridiculously large. On 3/5/2014 ?? 01:40, Mark Keymer wrote: > Hi Everyone, > > So I have a client who moved a domain specifically periodforgood.com > to a new VPS with our company. > > DNS has been updated and the TTL time is 4 hours so things should all > be updated but something might still be wrong. Looking for help / > confirmation that things look good. And better yet if someone from Cox > and take a look. > > Our client uses Cox for there home internet and sometimes the domain > resolves and sometimes it does not. We found they have the following > IP's in Cox's network that are being used to resolve domains. > > 68.105.28.11 > 68.105.28.12 > 68.105.29.12 > > After doing many nslookups via a remote session to there computer we > found that the top 2 IP's never resolve the periodforgood.com domain > and we found that the third one will about 20%-40% of the time resolve > it. > > We have gone to several DNS testing tools and all seems to be in > order. If you dig or nslookup directly to the DNS servers that are > used for the domain it seems to always respond. > > I admit I might just be overlooking something myself and will feel > dumb once someone points it out to me. But if you can point it out to > me that would be great! > > Also note that it looks like those DNS resolvers are blocked from > outside lookups which is good. So maybe someone with some eyeballs > inside or otherwise can help out? > > Sincerely, > From mpalmer at hezmatt.org Wed Mar 5 06:17:42 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 5 Mar 2014 17:17:42 +1100 Subject: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> References: <20140304201743.GB29640@vortex.com> <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> Message-ID: <20140305061737.GW7718@hezmatt.org> On Tue, Mar 04, 2014 at 10:07:56PM -0500, Jay Ashworth wrote: > Oh hell. > > Is this the *same* bug that just broke in Apple code last week? I'd be surprised if Apple used GnuTLS, on licencing grounds... > > widely used cryptographic code library. The bug in the GnuTLS library On the other hand, the DSA does sound *awfully* familiar: http://www.debian.org/security/2014/dsa-2869 Looking at the patch included in the sid version referenced in that DSA (also available at https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b), the general class of logic error involved is somewhat similar to the Apple case. Thankfully, we can see the full revision history of GnuTLS, and it looks like Nikos both fixed the bug *and* introduced it (at least, the 'goto cleanup' tests were introduced in 0fba2d90, way back in October 2003 -- it may have been safe then and someone else mucked up the cleanup code to break it; I haven't looked that deeply). Fun times indeed. "Once is happenstance, twice is coincidence..." - Matt From rs at seastrom.com Wed Mar 5 12:52:10 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 05 Mar 2014 07:52:10 -0500 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <5316BD72.3000703@winterei.se> (Paul S.'s message of "Wed, 05 Mar 2014 15:00:18 +0900") References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> Message-ID: <8661nsg64l.fsf@valhalla.seastrom.com> "Paul S." writes: > For all it's worth, it might be Cox ignoring TTLs and enforcing their > own update times instead. > > Wait 24-48 hours, and it should probably fix it all up. Possibly. > I'm not seeing anything majorly broken with your system except the SOA > EXPIRE being ridiculously large. Nowhere even close to ridiculously large. 3600000 (10000 hours, 41 days) is the historical example value in RFC 1035. It's a bit larger than current recommended practices (2-4 weeks) but I wouldn't fault anyone for using that value nor would I expect any nameserver software to malfunction when confronted it. Besides, that value only matters to secondary nameservers. Speaking of that... ;; ADDITIONAL SECTION: ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122 ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122 I think OP ought to approach his hoster with a cluebat. Not just on the same subnet but the same address? Really. -r From herro91 at gmail.com Wed Mar 5 17:19:05 2014 From: herro91 at gmail.com (Herro91) Date: Wed, 5 Mar 2014 12:19:05 -0500 Subject: OAM/CFM question on IOS-XR Message-ID: Hi, I've been working on a basic configuration for E-OAM starting with one domain. I have CFM working between the PEs (IOS-XR) devices tied to an EoMPLS instance, but have a few questions below: 1) I "think" I should be seeing MIPs in my traceroute when there is a P router in between the two PEs, correct? 2) If the P router in between these PEs is just a transit node, what configuration is required to create the MIPs? I have seen the MIP autocreate all, but it seems to be tied to a service configuration under CFM which would not apply in the case of a transit/P router. Thanks! From bicknell at ufp.org Wed Mar 5 20:21:56 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 5 Mar 2014 14:21:56 -0600 Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> References: <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> Message-ID: <0141083C-7F9C-4C8D-8B07-C4F53F1B8C4E@ufp.org> On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote: > Is this the *same* bug that just broke in Apple code last week? No, the Apple bug was the existence of an /extra/ "goto fail;". The GnuTLS bug was that it was /missing/ a "goto fail;". I'm figuring the same developer worked on both, and just put the line in the wrong repository. :) And yes, while this is a joke, Apple fixed their bug by removing a "goto fail;", and GnuTLS fixed theirs by adding a "goto fail;". I can't make up something that funny. https://www.imperialviolet.org/2014/02/22/applebug.html http://blog.existentialize.com/the-story-of-the-gnutls-bug.html -- 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: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Wed Mar 5 20:23:55 2014 From: bill at herrin.us (William Herrin) Date: Wed, 5 Mar 2014 15:23:55 -0500 Subject: valley free routing? Message-ID: Hi folks, Can anyone tell me about a situation in which a route which was not valley free was not a result of a misconfiguration or a bad actor? For those who don't recall the terminology, a network path is valley free if it crosses exactly zero or one free peering links when traveling between the two endpoints. Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bruns at 2mbit.com Wed Mar 5 20:38:26 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 05 Mar 2014 13:38:26 -0700 Subject: [Solved] Any CenturyLink IPv6 engineers/tech people around? In-Reply-To: <531647D8.4040701@2mbit.com> References: <531647D8.4040701@2mbit.com> Message-ID: <53178B42.1050204@2mbit.com> On 3/4/14, 2:38 PM, Brielle Bruns wrote: > Hello all, > > Don't suppose there's any CenturyLink engineers/tech people on this list > that can look into a problem with their IPv6 6rd service? > Thanks for the off-list replies. Think I've got the issues figured out. 6rd behaves a lot like 6to4 in how it handles traffic destined for hosts in the same ISP IPv6 subnet - and aggressive filtering of protocol 41 on external facing interfaces can break that. RFC5569 has more details on implementation, in case anyone else runs into this problem at a later point. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From Valdis.Kletnieks at vt.edu Wed Mar 5 21:00:44 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 05 Mar 2014 16:00:44 -0500 Subject: valley free routing? In-Reply-To: Your message of "Wed, 05 Mar 2014 15:23:55 -0500." References: Message-ID: <18513.1394053244@turing-police.cc.vt.edu> On Wed, 05 Mar 2014 15:23:55 -0500, William Herrin said: > Hi folks, > > Can anyone tell me about a situation in which a route which was not > valley free was not a result of a misconfiguration or a bad actor? For > those who don't recall the terminology, a network path is valley free > if it crosses exactly zero or one free peering links when traveling > between the two endpoints. Assume 3 providers A B and C, where you have a single-homed customer on A and a single-homed customer on C, and A and C don't peer. Traffic may end up going thorugh an A-B peering and a B-C peering. And whether A-B and B-C are a free peering or a paid transit is a business deal, outside the scope of BGP, unless you want to abuse communities... Are A and/or C "bad actors" for not peering? Jury is still out on that one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jra at baylink.com Wed Mar 5 21:03:38 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Mar 2014 16:03:38 -0500 (EST) Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <0141083C-7F9C-4C8D-8B07-C4F53F1B8C4E@ufp.org> Message-ID: <4578745.10980.1394053418017.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote: > > > Is this the *same* bug that just broke in Apple code last week? > > No, the Apple bug was the existence of an /extra/ "goto fail;". > > The GnuTLS bug was that it was /missing/ a "goto fail;". > > I'm figuring the same developer worked on both, and just put the line > in the wrong repository. :) Those who speculate that these bugs happened at the behest of the NSA would probably agree with you. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bill at herrin.us Wed Mar 5 21:08:21 2014 From: bill at herrin.us (William Herrin) Date: Wed, 5 Mar 2014 16:08:21 -0500 Subject: valley free routing? In-Reply-To: <18513.1394053244@turing-police.cc.vt.edu> References: <18513.1394053244@turing-police.cc.vt.edu> Message-ID: On Wed, Mar 5, 2014 at 4:00 PM, wrote: > On Wed, 05 Mar 2014 15:23:55 -0500, William Herrin said: >> Can anyone tell me about a situation in which a route which was not >> valley free was not a result of a misconfiguration or a bad actor? For >> those who don't recall the terminology, a network path is valley free >> if it crosses exactly zero or one free peering links when traveling >> between the two endpoints. > > Assume 3 providers A B and C, where you have a single-homed customer on A and a > single-homed customer on C, and A and C don't peer. Traffic may end up going > thorugh an A-B peering and a B-C peering. And whether A-B and B-C are a free > peering or a paid transit is a business deal, outside the scope of BGP, unless > you want to abuse communities... > > Are A and/or C "bad actors" for not peering? Jury is still out on that one. Hi Valdis, It's that business deal I want to hear about. When A-B and B-C are free peering but the traffic goes A-B-C for some reason other than a misconfiguration or deliberate abuse. On or off list, I'd like to know about real-life use cases where folks do this on purpose. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mark at viviotech.net Wed Mar 5 21:23:12 2014 From: mark at viviotech.net (Mark Keymer) Date: Wed, 05 Mar 2014 13:23:12 -0800 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <8661nsg64l.fsf@valhalla.seastrom.com> References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> Message-ID: <531795C0.4040908@viviotech.net> Thank you to the on and off lists replies. The DNS servers are not my choice to have them that way. But I will mention that to my client. It looks like Cox is now resolving things as it should be for this domain. Sincerely, Mark Keymer CFO/COO Vivio Technologies On 3/5/2014 4:52 AM, Rob Seastrom wrote: > "Paul S." writes: > >> For all it's worth, it might be Cox ignoring TTLs and enforcing their >> own update times instead. >> >> Wait 24-48 hours, and it should probably fix it all up. > Possibly. > >> I'm not seeing anything majorly broken with your system except the SOA >> EXPIRE being ridiculously large. > Nowhere even close to ridiculously large. 3600000 (10000 hours, 41 > days) is the historical example value in RFC 1035. It's a bit larger > than current recommended practices (2-4 weeks) but I wouldn't fault > anyone for using that value nor would I expect any nameserver software > to malfunction when confronted it. Besides, that value only matters > to secondary nameservers. Speaking of that... > > ;; ADDITIONAL SECTION: > ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122 > ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122 > > I think OP ought to approach his hoster with a cluebat. Not just on > the same subnet but the same address? Really. > > -r > > From David.Siegel at Level3.com Wed Mar 5 21:48:26 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Wed, 5 Mar 2014 21:48:26 +0000 Subject: valley free routing? In-Reply-To: References: <18513.1394053244@turing-police.cc.vt.edu> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05C13F8C4@USIDCWVEMBX05.corp.global.level3.com> I can't think of any circumstances where the business "B" would be content transit traffic between A and C without some form of compensation. That compensation may not involve payment for bits, however. In theory, the compensation might be derived from something occurring at the application layer, but even in those cases that business relationship is probably not apparent from looking at prefix advertisements. Business B is probably using b2b user agents, gre encap or some other method that makes both legs look like independent IP flows to network A and B. Interesting question, though. Dave -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Wednesday, March 05, 2014 2:08 PM To: Valdis Kletnieks Cc: nanog at nanog.org Subject: Re: valley free routing? On Wed, Mar 5, 2014 at 4:00 PM, wrote: > On Wed, 05 Mar 2014 15:23:55 -0500, William Herrin said: >> Can anyone tell me about a situation in which a route which was not >> valley free was not a result of a misconfiguration or a bad actor? >> For those who don't recall the terminology, a network path is valley >> free if it crosses exactly zero or one free peering links when >> traveling between the two endpoints. > > Assume 3 providers A B and C, where you have a single-homed customer > on A and a single-homed customer on C, and A and C don't peer. > Traffic may end up going thorugh an A-B peering and a B-C peering. And > whether A-B and B-C are a free peering or a paid transit is a business > deal, outside the scope of BGP, unless you want to abuse communities... > > Are A and/or C "bad actors" for not peering? Jury is still out on that one. Hi Valdis, It's that business deal I want to hear about. When A-B and B-C are free peering but the traffic goes A-B-C for some reason other than a misconfiguration or deliberate abuse. On or off list, I'd like to know about real-life use cases where folks do this on purpose. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From deleskie at gmail.com Wed Mar 5 21:58:12 2014 From: deleskie at gmail.com (jim deleskie) Date: Wed, 5 Mar 2014 17:58:12 -0400 Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <4578745.10980.1394053418017.JavaMail.root@benjamin.baylink.com> References: <0141083C-7F9C-4C8D-8B07-C4F53F1B8C4E@ufp.org> <4578745.10980.1394053418017.JavaMail.root@benjamin.baylink.com> Message-ID: Doing some serious adjusting of my tinfoil today over his :) -jim On Wed, Mar 5, 2014 at 5:03 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Leo Bicknell" > > > On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote: > > > > > Is this the *same* bug that just broke in Apple code last week? > > > > No, the Apple bug was the existence of an /extra/ "goto fail;". > > > > The GnuTLS bug was that it was /missing/ a "goto fail;". > > > > I'm figuring the same developer worked on both, and just put the line > > in the wrong repository. :) > > Those who speculate that these bugs happened at the behest of the NSA > would probably agree with you. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > > From ikiris at gmail.com Wed Mar 5 22:37:47 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 5 Mar 2014 16:37:47 -0600 Subject: valley free routing? In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC05C13F8C4@USIDCWVEMBX05.corp.global.level3.com> References: <18513.1394053244@turing-police.cc.vt.edu> <970945E55BFD8C4EA4CAD74B647A9DC05C13F8C4@USIDCWVEMBX05.corp.global.level3.com> Message-ID: The AS I worked at back in the day did to a degree for willing parties. Mostly small ISPs who all knew each other. We had at the time 3 regional hub locations with interlinks, and peered settlement free with 2 - 3 ASs in 1 of the locations, and 1-2 ASs each in the other 2 locations, all of which could opt to allow their prefixes to be heard by the others via communities. -Blake On Wed, Mar 5, 2014 at 3:48 PM, Siegel, David wrote: > I can't think of any circumstances where the business "B" would be content > transit traffic between A and C without some form of compensation. That > compensation may not involve payment for bits, however. In theory, the > compensation might be derived from something occurring at the application > layer, but even in those cases that business relationship is probably not > apparent from looking at prefix advertisements. Business B is probably > using b2b user agents, gre encap or some other method that makes both legs > look like independent IP flows to network A and B. > > Interesting question, though. > > > > Dave > > > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Wednesday, March 05, 2014 2:08 PM > To: Valdis Kletnieks > Cc: nanog at nanog.org > Subject: Re: valley free routing? > > On Wed, Mar 5, 2014 at 4:00 PM, wrote: > > On Wed, 05 Mar 2014 15:23:55 -0500, William Herrin said: > >> Can anyone tell me about a situation in which a route which was not > >> valley free was not a result of a misconfiguration or a bad actor? > >> For those who don't recall the terminology, a network path is valley > >> free if it crosses exactly zero or one free peering links when > >> traveling between the two endpoints. > > > > Assume 3 providers A B and C, where you have a single-homed customer > > on A and a single-homed customer on C, and A and C don't peer. > > Traffic may end up going thorugh an A-B peering and a B-C peering. And > > whether A-B and B-C are a free peering or a paid transit is a business > > deal, outside the scope of BGP, unless you want to abuse communities... > > > > Are A and/or C "bad actors" for not peering? Jury is still out on that > one. > > Hi Valdis, > > It's that business deal I want to hear about. When A-B and B-C are free > peering but the traffic goes A-B-C for some reason other than a > misconfiguration or deliberate abuse. On or off list, I'd like to know > about real-life use cases where folks do this on purpose. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: Falls > Church, VA 22042-3004 > > > From blueneon at gmail.com Wed Mar 5 23:11:53 2014 From: blueneon at gmail.com (Tom Morris) Date: Wed, 5 Mar 2014 18:11:53 -0500 Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: References: <0141083C-7F9C-4C8D-8B07-C4F53F1B8C4E@ufp.org> <4578745.10980.1394053418017.JavaMail.root@benjamin.baylink.com> Message-ID: Been spending most of the day scrubbing away that vuln in my facility here.... now here's the fun part: imagine just how many embedded devices (most of which get orphaned from a software maintenance perspective the moment they hit the store shelves) are gonna have this flaw. There's been the discussion of crappy home broadband CPE... Only a matter of time before someone fakes the certificate and breaks a "trusted" software update method, or heck... a dns explot + fake certificate = several million compromised payment card terminals. On Wed, Mar 5, 2014 at 4:58 PM, jim deleskie wrote: > Doing some serious adjusting of my tinfoil today over his :) > > -jim > > > On Wed, Mar 5, 2014 at 5:03 PM, Jay Ashworth wrote: > > > ----- Original Message ----- > > > From: "Leo Bicknell" > > > > > On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote: > > > > > > > Is this the *same* bug that just broke in Apple code last week? > > > > > > No, the Apple bug was the existence of an /extra/ "goto fail;". > > > > > > The GnuTLS bug was that it was /missing/ a "goto fail;". > > > > > > I'm figuring the same developer worked on both, and just put the line > > > in the wrong repository. :) > > > > Those who speculate that these bugs happened at the behest of the NSA > > would probably agree with you. > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think RFC > > 2100 > > Ashworth & Associates http://www.bcp38.info 2000 Land > > Rover DII > > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > > 1274 > > > > > -- -- Tom Morris, KG4CYX Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz! 786-228-7087 151.820 Megacycles From Valdis.Kletnieks at vt.edu Thu Mar 6 00:54:09 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 05 Mar 2014 19:54:09 -0500 Subject: valley free routing? In-Reply-To: Your message of "Wed, 05 Mar 2014 21:48:26 +0000." <970945E55BFD8C4EA4CAD74B647A9DC05C13F8C4@USIDCWVEMBX05.corp.global.level3.com> References: <18513.1394053244@turing-police.cc.vt.edu> <970945E55BFD8C4EA4CAD74B647A9DC05C13F8C4@USIDCWVEMBX05.corp.global.level3.com> Message-ID: <31823.1394067249@turing-police.cc.vt.edu> On Wed, 05 Mar 2014 21:48:26 +0000, "Siegel, David" said: > I can't think of any circumstances where the business "B" would be content > transit traffic between A and C without some form of compensation. That > compensation may not involve payment for bits, however. If ASN B is a cooperative venture (such as a regional network) funded by A, C, and several others for mutual gain, it's not at all out of the question. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jmaslak at antelope.net Thu Mar 6 01:18:39 2014 From: jmaslak at antelope.net (Joel Maslak) Date: Wed, 5 Mar 2014 18:18:39 -0700 Subject: valley free routing? In-Reply-To: References: Message-ID: I have worked for the middle network when I was responsible for a government network - typically we were the middle network. Logic was it was good for citizens for us to essentially act like a peering exchange for certain types of entity (who also typically were government affiliated). One I can think of was to allow a full mesh of video education between various institutions - it was the right thing to do for all entities involved and I facilitated it through the network I was affiliated with. You might also think about the circumstance of two government subcontractors working on a common project or interfacing with each other's systems on behalf of a common customer. The middle network is paying each end to connect to the middle but is providing reverse transit between them (I.E. the end entities are paid to transit the middle!), although the contracts aren't exactly phrased to say that! A lot of time, this may be done with static routes, but it could easily be done with BGP and the end effect is the same. I have never heard the term valley free. Where does it come from? On Mar 5, 2014 1:25 PM, "William Herrin" wrote: > Hi folks, > > Can anyone tell me about a situation in which a route which was not > valley free was not a result of a misconfiguration or a bad actor? For > those who don't recall the terminology, a network path is valley free > if it crosses exactly zero or one free peering links when traveling > between the two endpoints. > > Thanks, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From jra at baylink.com Thu Mar 6 03:48:18 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Mar 2014 22:48:18 -0500 (EST) Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <20140305061737.GW7718@hezmatt.org> Message-ID: <8823266.11010.1394077698367.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matt Palmer" > Fun times indeed. "Once is happenstance, twice is coincidence..." And for the few who don't recall the last stanza -- and this is looking less and less by the month like it requires an aluminium foil fedora to buy as a justification: "Three times is enemy action." Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mgarciacase at gmail.com Wed Mar 5 11:37:29 2014 From: mgarciacase at gmail.com (=?ISO-8859-1?B?TWFy7WEgR2FyY+1h?=) Date: Wed, 5 Mar 2014 12:37:29 +0100 Subject: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <20140305061737.GW7718@hezmatt.org> References: <20140304201743.GB29640@vortex.com> <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> <20140305061737.GW7718@hezmatt.org> Message-ID: 2014-03-05 7:17 GMT+01:00 Matt Palmer : > the 'goto > cleanup' tests were introduced in 0fba2d90, way back in October 2003 > Where can you see that "the 'goto cleanup' tests were introduced in 0fba2d90, way back in October 2003" ? *Mar?a Garc?a* From jmceachin at gmail.com Wed Mar 5 19:02:41 2014 From: jmceachin at gmail.com (Jmac) Date: Wed, 05 Mar 2014 14:02:41 -0500 Subject: Novartis and Qwest AS209 Message-ID: All, I haven?t posted something to Nanog in probably 10 years so forgive my ignorance on protocol. I am sure this has been posted about but while I figure out how to search the archives?. I see Ripe DB, Maxmind and many others have AS209 associated with the company Novartis. Did I miss something because ARIN whois shows it different. If this is wrong, it seems the source of the error is db.ripe.net. aut-num: AS209 as-name: ASN-QWEST-US descr: NOVARTIS-DMZ-US admin-c: NOVN1-RIPE tech-c: NOVN2-RIPE mnt-by: NOVARTIS-MNT source: RIPE # Filtered Thanks Jason From morrowc.lists at gmail.com Thu Mar 6 10:05:30 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Mar 2014 05:05:30 -0500 Subject: Novartis and Qwest AS209 In-Reply-To: References: Message-ID: guessing that 209 registered some objects on behalf of novartis/customer? novartis isn't qwest who's now centurylink anyway. On Wed, Mar 5, 2014 at 2:02 PM, Jmac wrote: > All, I haven?t posted something to Nanog in probably 10 years so forgive my > ignorance on protocol. I am sure this has been posted about but while I > figure out how to search the archives?. > > I see Ripe DB, Maxmind and many others have AS209 associated with the > company Novartis. Did I miss something because ARIN whois shows it > different. If this is wrong, it seems the source of the error is > db.ripe.net. > > aut-num: AS209 > num> > as-name: ASN-QWEST-US > descr: NOVARTIS-DMZ-US > admin-c: NOVN1-RIPE > =PERSON> > tech-c: NOVN2-RIPE > =PERSON> > mnt-by: NOVARTIS-MNT > pe=MNTNER> > source: RIPE # Filtered > > Thanks > Jason > > From mpalmer at hezmatt.org Thu Mar 6 11:24:57 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 6 Mar 2014 22:24:57 +1100 Subject: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: References: <20140304201743.GB29640@vortex.com> <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> <20140305061737.GW7718@hezmatt.org> Message-ID: <20140306112457.GN7718@hezmatt.org> On Wed, Mar 05, 2014 at 12:37:29PM +0100, Mar?a Garc?a wrote: > 2014-03-05 7:17 GMT+01:00 Matt Palmer : > > the 'goto > > cleanup' tests were introduced in 0fba2d90, way back in October 2003 > > Where can you see that "the 'goto > cleanup' tests were introduced in 0fba2d90, way back in October 2003" ? In the git repo I linked to in my previous e-mail. - Matt -- I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. -- Bjarne Stroustrup From mgarciacase at gmail.com Thu Mar 6 11:55:50 2014 From: mgarciacase at gmail.com (=?ISO-8859-1?B?TWFy7WEgR2FyY+1h?=) Date: Thu, 6 Mar 2014 12:55:50 +0100 Subject: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping In-Reply-To: <20140306112457.GN7718@hezmatt.org> References: <20140304201743.GB29640@vortex.com> <10342793.10882.1393988876197.JavaMail.root@benjamin.baylink.com> <20140305061737.GW7718@hezmatt.org> <20140306112457.GN7718@hezmatt.org> Message-ID: I can't see the date... ? El mar 6, 2014 12:27 PM, "Matt Palmer" escribi?: > On Wed, Mar 05, 2014 at 12:37:29PM +0100, Mar?a Garc?a wrote: > > 2014-03-05 7:17 GMT+01:00 Matt Palmer : > > > the 'goto > > > cleanup' tests were introduced in 0fba2d90, way back in October 2003 > > > > Where can you see that "the 'goto > > cleanup' tests were introduced in 0fba2d90, way back in October 2003" ? > > In the git repo I linked to in my previous e-mail. > > - Matt > > -- > I have always wished that my computer would be as easy to use as my > telephone. My wish has come true. I no longer know how to use my telephone. > -- Bjarne Stroustrup > > > From bmanning at vacation.karoshi.com Thu Mar 6 12:14:14 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 6 Mar 2014 04:14:14 -0800 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <8661nsg64l.fsf@valhalla.seastrom.com> References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> Message-ID: <20140306121413.GA20355@vacation.karoshi.com> On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote: > > "Paul S." writes: > > > For all it's worth, it might be Cox ignoring TTLs and enforcing their > > own update times instead. > > > > Wait 24-48 hours, and it should probably fix it all up. > > Possibly. > > > I'm not seeing anything majorly broken with your system except the SOA > > EXPIRE being ridiculously large. > > Nowhere even close to ridiculously large. 3600000 (10000 hours, 41 > days) is the historical example value in RFC 1035. It's a bit larger > than current recommended practices (2-4 weeks) but I wouldn't fault > anyone for using that value nor would I expect any nameserver software > to malfunction when confronted it. Besides, that value only matters > to secondary nameservers. Speaking of that... > > ;; ADDITIONAL SECTION: > ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122 > ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122 > > I think OP ought to approach his hoster with a cluebat. Not just on > the same subnet but the same address? Really. > > -r > haven't you heard about "anycast"?? /bill From jako.andras at eik.bme.hu Thu Mar 6 12:17:12 2014 From: jako.andras at eik.bme.hu (=?utf-8?B?SsOBS8OTIEFuZHLDoXM=?=) Date: Thu, 6 Mar 2014 13:17:12 +0100 Subject: valley free routing? In-Reply-To: References: <18513.1394053244@turing-police.cc.vt.edu> Message-ID: <20140306121712.GA26170@eik.bme.hu> > It's that business deal I want to hear about. When A-B and B-C are > free peering but the traffic goes A-B-C for some reason other than a > misconfiguration or deliberate abuse. On or off list, I'd like to know > about real-life use cases where folks do this on purpose. As far as I understand some NRENs do that in Europe. Check out AS1853 and AS-ACONETTOVIX in the RIPE whois. "A" networks are the peers a VIX, "B" is ACONET, "C" networks are CESNET, SANET, and PIONIER. DTAG's looking glass shows this path to SANET: sh ip bgp regexp _2607_ BGP table version is 0, local router ID is 217.239.38.165 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i147.175.0.0 194.25.5.150 100 0 1853 2607 i *>i147.213.0.0 194.25.5.150 100 0 1853 2607 i *>i147.232.0.0 194.25.5.150 100 0 1853 2607 i *>i158.193.0.0 194.25.5.150 100 0 1853 2607 i *>i158.195.0.0 194.25.5.150 100 0 1853 2607 i *>i158.197.0.0 194.25.5.150 100 0 1853 2607 i *>i192.108.130.0 194.25.5.150 100 0 1853 2607 i *>i192.108.131.0 194.25.5.150 100 0 1853 2607 i *>i192.108.132.0/23 194.25.5.150 100 0 1853 2607 i *>i192.108.138.0 194.25.5.150 100 0 1853 2607 i *>i192.108.149.0 194.25.5.150 100 0 1853 2607 i *>i193.87.0.0/16 194.25.5.150 100 0 1853 2607 i *>i194.1.0.0/17 194.25.5.150 100 0 1853 2607 i *>i194.160.0.0/16 194.25.5.150 100 0 1853 2607 i Total number of prefixes 14 Regards, Andr?s From iljitsch at muada.com Thu Mar 6 12:39:28 2014 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 6 Mar 2014 13:39:28 +0100 Subject: valley free routing? In-Reply-To: References: Message-ID: <286F0865-9D89-4B50-B819-887C921553F8@muada.com> > On 6 mrt. 2014, at 02:18, Joel Maslak wrote: > > I have never heard the term valley free. Where does it come from? This paper, which is a must-read for anyone interested in BGP: Stable internet routing without global coordination By Lixin Gao and Jennifer Rexford http://dl.acm.org/citation.cfm?id=504612 From nick at foobar.org Thu Mar 6 12:41:15 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 06 Mar 2014 12:41:15 +0000 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <20140306121413.GA20355@vacation.karoshi.com> References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> Message-ID: <53186CEB.60209@foobar.org> On 06/03/2014 12:14, bmanning at vacation.karoshi.com wrote: > On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote: >> to secondary nameservers. Speaking of that... >> >> ;; ADDITIONAL SECTION: >> ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122 >> ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122 >> >> I think OP ought to approach his hoster with a cluebat. Not just on >> the same subnet but the same address? Really. >> >> -r >> > > haven't you heard about "anycast"?? rs probably has. The owner of 199.73.57.122, probably not. Nick From rs at seastrom.com Thu Mar 6 13:07:55 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 06 Mar 2014 08:07:55 -0500 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <53186CEB.60209@foobar.org> (Nick Hilliard's message of "Thu, 06 Mar 2014 12:41:15 +0000") References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> Message-ID: <86k3c7cw5w.fsf@valhalla.seastrom.com> Nick Hilliard writes: >> haven't you heard about "anycast"?? > > rs probably has. The owner of 199.73.57.122, probably not. indeed. there are many pieces of evidence that this is not an anycast prefix. proof is left as an exercise to those who can perform traceroutes from multiple continents, run nmap -sP, log into route-views, or do some combination of the above. -r From contact at winterei.se Thu Mar 6 13:17:37 2014 From: contact at winterei.se (Paul S.) Date: Thu, 06 Mar 2014 22:17:37 +0900 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <53186CEB.60209@foobar.org> References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> Message-ID: <53187571.80701@winterei.se> OP is actually the owner of it as per ARIN whois data. -- Paul On 3/6/2014 ?? 09:41, Nick Hilliard wrote: > On 06/03/2014 12:14, bmanning at vacation.karoshi.com wrote: >> On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote: >>> to secondary nameservers. Speaking of that... >>> >>> ;; ADDITIONAL SECTION: >>> ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122 >>> ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122 >>> >>> I think OP ought to approach his hoster with a cluebat. Not just on >>> the same subnet but the same address? Really. >>> >>> -r >>> >> haven't you heard about "anycast"?? > rs probably has. The owner of 199.73.57.122, probably not. > > Nick > > > From jiri.prochazka at superhosting.cz Thu Mar 6 13:00:29 2014 From: jiri.prochazka at superhosting.cz (Jiri Prochazka) Date: Thu, 06 Mar 2014 14:00:29 +0100 Subject: fiber optics patchcords - supplier nearby Atlanta,GA Message-ID: Hello list, we're deploying a new rack/technology in Atlanta,GA and we are out of reserves of optical patchcords. We need to get another few pieces (combinations of most used connectors like LC/SC/E2000 and lenghts). Could you please point me to some eshop in the US, where we can get them? Ideally with possibility to pay over PayPal and delivery time to Atlanta,GA in two working days. Normally, we would ship them from Europe, but we do not want to risk the delay which could be caused by customs. Thank you! Jiri Prochazka From josh at 2cold.net Thu Mar 6 13:28:14 2014 From: josh at 2cold.net (Joshua McDonald) Date: Thu, 6 Mar 2014 08:28:14 -0500 Subject: fiber optics patchcords - supplier nearby Atlanta,GA In-Reply-To: References: Message-ID: <106713563872075579@unknownmsgid> Not sure about the PayPal requirement, but Cables and Kits is local to Atlanta. http://www.cablesandkits.com Josh > On Mar 6, 2014, at 8:21, Jiri Prochazka wrote: > > Hello list, > > we're deploying a new rack/technology in Atlanta,GA and we are out of reserves of optical patchcords. > > We need to get another few pieces (combinations of most used connectors like LC/SC/E2000 and lenghts). > > > Could you please point me to some eshop in the US, where we can get them? > > Ideally with possibility to pay over PayPal and delivery time to Atlanta,GA in two working days. Normally, we would ship them from Europe, but we do not want to risk the delay which could be caused by customs. > > > Thank you! > > > > Jiri Prochazka > > From joelja at bogus.com Thu Mar 6 13:28:31 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 06 Mar 2014 13:28:31 +0000 Subject: fiber optics patchcords - supplier nearby Atlanta,GA In-Reply-To: References: Message-ID: <531877FF.50402@bogus.com> On 3/6/14, 1:00 PM, Jiri Prochazka wrote: > Hello list, > > we're deploying a new rack/technology in Atlanta,GA and we are out of > reserves of optical patchcords. > > We need to get another few pieces (combinations of most used connectors > like LC/SC/E2000 and lenghts). > > > Could you please point me to some eshop in the US, where we can get them? > > Ideally with possibility to pay over PayPal and delivery time to > Atlanta,GA in two working days. Normally, we would ship them from > Europe, but we do not want to risk the delay which could be caused by > customs. cables and kits is local to atlanta http://www.cablesandkits.com/ when I was standing up a large footprint in atl I worked with the local graybar among other suppliers. > > Thank you! > > > > Jiri Prochazka > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From dale.rumph at gmail.com Thu Mar 6 13:32:39 2014 From: dale.rumph at gmail.com (Dale Rumph) Date: Thu, 6 Mar 2014 08:32:39 -0500 Subject: fiber optics patchcords - supplier nearby Atlanta,GA In-Reply-To: References: Message-ID: On Mar 6, 2014 8:22 AM, "Jiri Prochazka" wrote: > > Hello list, > > we're deploying a new rack/technology in Atlanta,GA and we are out of reserves of optical patchcords. > > We need to get another few pieces (combinations of most used connectors like LC/SC/E2000 and lenghts). > > > Could you please point me to some eshop in the US, where we can get them? > > Ideally with possibility to pay over PayPal and delivery time to Atlanta,GA in two working days. Normally, we would ship them from Europe, but we do not want to risk the delay which could be caused by customs. > > > Thank you! > > > > Jiri Prochazka > > http://www.cablesandkits.com/ is located in buford GA, also monoprice.comis a good estore for patch cables. From randy at psg.com Thu Mar 6 14:41:52 2014 From: randy at psg.com (Randy Bush) Date: Thu, 06 Mar 2014 14:41:52 +0000 Subject: valley free routing? In-Reply-To: References: Message-ID: once upon a time, provider A and provider P were having a peering war, and provider V provided valley transit for P's prefixes to A. it was not meant to be seen publicly, but the traceroutes were posted to nanog, or maybe it was com-priv at the time. this is far from the only time this has happened. randy From jiri.prochazka at superhosting.cz Thu Mar 6 15:39:27 2014 From: jiri.prochazka at superhosting.cz (Jiri Prochazka) Date: Thu, 06 Mar 2014 16:39:27 +0100 Subject: fiber optics patchcords - supplier nearby Atlanta,GA In-Reply-To: References: Message-ID: Thanks to all who replied here & off list. We have already made an order on Cablesandkits.com. Jiri Dne 6.3.2014 14:00, Jiri Prochazka napsal(a): > Hello list, > > we're deploying a new rack/technology in Atlanta,GA and we are out of > reserves of optical patchcords. > > We need to get another few pieces (combinations of most used connectors > like LC/SC/E2000 and lenghts). > > > Could you please point me to some eshop in the US, where we can get them? > > Ideally with possibility to pay over PayPal and delivery time to > Atlanta,GA in two working days. Normally, we would ship them from > Europe, but we do not want to risk the delay which could be caused by > customs. > > > Thank you! > > > > Jiri Prochazka > > > From rejchrt at ics.muni.cz Thu Mar 6 12:53:38 2014 From: rejchrt at ics.muni.cz (Jan Rejchrt) Date: Thu, 06 Mar 2014 13:53:38 +0100 Subject: Network anomaly survey - evaluation and results Message-ID: <53186FD2.8040202@ics.muni.cz> Dear network experts, few months ago we conducted a survey regarding network anomalies. We'd like to provide you with our findings that you can find at RIPE Labs page: https://labs.ripe.net/Members/jan_rejchrt/network-anomaly-detection-2013-survey-evaluation I'd like to thank all the participants. Best regards, Jan Rejchrt On behalf of CSIRT-MU -- Mgr. Jan Rejchrt rejchrt at ics.muni.cz Security Department, CSIRT-MU group http://csirt.muni.cz Institute of Computer Science, Masaryk University, Brno, Czech Republic PGP Key ID: 0x9B5724C8 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From bja8180 at gmail.com Thu Mar 6 15:37:14 2014 From: bja8180 at gmail.com (Bryan Ashley) Date: Thu, 6 Mar 2014 10:37:14 -0500 Subject: BGP attributes through IGP Message-ID: Greetings all - first time caller long time listener. I came across a scenario the other day which got my wheels turning a bit and wanted to reach out and see how others are handling this besides what I would think to be the obvious. Scenario: R1->R2->R3->R4 R1->R2 eBGP R2->R3 OSPF R3->R4 eBGP Essentially what I want to do is be able to carry BGP attributes through OSPF so that remote end sees the full AS-PATH, ORIGIN, etc. The easy answer here is iBGP across OSPF however the wrinkle is this can't be done. Its a long story and one in which we are currently fighting however suffice it to say for the moment this option is out. My searches have come up a little short however I found a couple references to using automatic-tag and as-path tag to carry this through. I cant seem to find any Junos reference information on this so wanted to reach out to the ether and see if others have faced this situation before or have any other recommendations on solutions. Responses on or off list is much appreciated. From saku at ytti.fi Thu Mar 6 21:09:32 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 6 Mar 2014 23:09:32 +0200 Subject: BGP attributes through IGP In-Reply-To: References: Message-ID: <20140306210932.GA8413@pob.ytti.fi> On (2014-03-06 10:37 -0500), Bryan Ashley wrote: > My searches have come up a little short however I found a couple references > to using automatic-tag and as-path tag to carry this through. I cant seem > to find any Junos reference information on this so wanted to reach out to > the ether and see if others have faced this situation before or have any > other recommendations on solutions. I don't think JunOS supports this. It's bit of hack at any rate. It's not transporting AS_PATH, it's transporting single 16b ASN. It's essentially abusing (some what well-defined and interoperable abuse) 32b tag field for this purpose. Maybe you could try to do some of this manually, set some tags, which trigger 'set then origin x', as-path-expand/prepend might be more challenging. Recommendation for solution might be easier with rationale why you need to transport origin+aspath over IGP. -- ++ytti From bja8180 at gmail.com Thu Mar 6 21:58:51 2014 From: bja8180 at gmail.com (Bryan Ashley) Date: Thu, 6 Mar 2014 16:58:51 -0500 Subject: BGP attributes through IGP In-Reply-To: <20140306210932.GA8413@pob.ytti.fi> References: <20140306210932.GA8413@pob.ytti.fi> Message-ID: so this scenario was a much more scaled down version of the actual topology. Basically I have a "gap" of routers that I don't manage or have access to in between mine running eBGP. We are collecting some metrics and doing monitoring on the AS-PATH of the routes received, among other attributes, for both ends so losing some of this information is a problem. Again, I know the right answer here is to run iBGP across the IGP and I am fighting that fight but it got me looking for alternative solutions and figured I would see if anyone else ever had to come up with a creative solution before. On Thu, Mar 6, 2014 at 4:09 PM, Saku Ytti wrote: > On (2014-03-06 10:37 -0500), Bryan Ashley wrote: > > > My searches have come up a little short however I found a couple > references > > to using automatic-tag and as-path tag to carry this through. I cant > seem > > to find any Junos reference information on this so wanted to reach out to > > the ether and see if others have faced this situation before or have any > > other recommendations on solutions. > > I don't think JunOS supports this. > > It's bit of hack at any rate. It's not transporting AS_PATH, it's > transporting > single 16b ASN. > It's essentially abusing (some what well-defined and interoperable abuse) > 32b > tag field for this purpose. > > Maybe you could try to do some of this manually, set some tags, which > trigger > 'set then origin x', as-path-expand/prepend might be more challenging. > Recommendation for solution might be easier with rationale why you need to > transport origin+aspath over IGP. > > -- > ++ytti > > From efinley.lists at gmail.com Thu Mar 6 22:10:42 2014 From: efinley.lists at gmail.com (Elliot Finley) Date: Thu, 6 Mar 2014 15:10:42 -0700 Subject: BGP attributes through IGP In-Reply-To: References: <20140306210932.GA8413@pob.ytti.fi> Message-ID: iBGP over GRE? On Thu, Mar 6, 2014 at 2:58 PM, Bryan Ashley wrote: > so this scenario was a much more scaled down version of the actual > topology. Basically I have a "gap" of routers that I don't manage or have > access to in between mine running eBGP. We are collecting some metrics and > doing monitoring on the AS-PATH of the routes received, among other > attributes, for both ends so losing some of this information is a problem. > Again, I know the right answer here is to run iBGP across the IGP and I am > fighting that fight but it got me looking for alternative solutions and > figured I would see if anyone else ever had to come up with a creative > solution before. > > > On Thu, Mar 6, 2014 at 4:09 PM, Saku Ytti wrote: > > > On (2014-03-06 10:37 -0500), Bryan Ashley wrote: > > > > > My searches have come up a little short however I found a couple > > references > > > to using automatic-tag and as-path tag to carry this through. I cant > > seem > > > to find any Junos reference information on this so wanted to reach out > to > > > the ether and see if others have faced this situation before or have > any > > > other recommendations on solutions. > > > > I don't think JunOS supports this. > > > > It's bit of hack at any rate. It's not transporting AS_PATH, it's > > transporting > > single 16b ASN. > > It's essentially abusing (some what well-defined and interoperable abuse) > > 32b > > tag field for this purpose. > > > > Maybe you could try to do some of this manually, set some tags, which > > trigger > > 'set then origin x', as-path-expand/prepend might be more challenging. > > Recommendation for solution might be easier with rationale why you need > to > > transport origin+aspath over IGP. > > > > -- > > ++ytti > > > > > From gdt at gdt.id.au Fri Mar 7 00:19:04 2014 From: gdt at gdt.id.au (Glen Turner) Date: Fri, 7 Mar 2014 10:49:04 +1030 Subject: BGP attributes through IGP In-Reply-To: <20140306210932.GA8413@pob.ytti.fi> References: <20140306210932.GA8413@pob.ytti.fi> Message-ID: Saku Ytti wrote: > > It's essentially abusing (some what well-defined and interoperable abuse) 32b > tag field for this purpose. That's pretty much what the OSPF tag and the BGP's synchronisation with OSPF were originally intended for. However it's pretty much a design misfeature and you'd be happier with iBGP over a tunnel -glen From mpetach at netflight.com Fri Mar 7 02:23:42 2014 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 6 Mar 2014 18:23:42 -0800 Subject: valley free routing? In-Reply-To: References: Message-ID: On Wed, Mar 5, 2014 at 12:23 PM, William Herrin wrote: > Hi folks, > > Can anyone tell me about a situation in which a route which was not > valley free was not a result of a misconfiguration or a bad actor? For > those who don't recall the terminology, a network path is valley free > if it crosses exactly zero or one free peering links when traveling > between the two endpoints. > Isn't that the way most of the IPv6 internet ran for many years? ISP A -> 6939 <- ISP B, settlement-free connections all around? It's what established 6939 as the core of the IPv6 internet. Matt > > Thanks, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From bill at herrin.us Fri Mar 7 02:56:38 2014 From: bill at herrin.us (William Herrin) Date: Thu, 6 Mar 2014 21:56:38 -0500 Subject: valley free routing? In-Reply-To: References: Message-ID: On Thu, Mar 6, 2014 at 9:23 PM, Matthew Petach wrote: > On Wed, Mar 5, 2014 at 12:23 PM, William Herrin wrote: >> Can anyone tell me about a situation in which a route which was not >> valley free was not a result of a misconfiguration or a bad actor? For >> those who don't recall the terminology, a network path is valley free >> if it crosses exactly zero or one free peering links when traveling >> between the two endpoints. > > > Isn't that the way most of the IPv6 internet ran > for many years? ISP A -> 6939 <- ISP B, > settlement-free connections all around? It's > what established 6939 as the core of the > IPv6 internet. Hi Matthew, By peering I mean a link on which the two participants offer and accept substantially fewer routes than "the rest of the Internet." Usually only the routes for each participant's respective customers. The clever folks at HE provided full IPv6 transit as a loss leader which enhanced their market position (put them on the map quite frankly). That's not a "valley" in this context. I'm really intrigued by the multiple reports of RENs creating a sort of shadow network where other RENs are permitted to cross their internal backbone at no cost but not access their general Internet transit. That does seem to be a valley. Is anybody outside the Research and Education industry doing this sort of thing? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ikiris at gmail.com Fri Mar 7 03:53:13 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 6 Mar 2014 21:53:13 -0600 Subject: BGP attributes through IGP In-Reply-To: References: <20140306210932.GA8413@pob.ytti.fi> Message-ID: Mpls, GRE, line gun... At some point, you want to stop beginning technical designs with "Doctor! Doctor! It hurts when I do this. What can I do?" The answer doesn't generally change, no matter how many times it's asked. -Blake On Thu, Mar 6, 2014 at 6:19 PM, Glen Turner wrote: > > Saku Ytti wrote: > > > > It's essentially abusing (some what well-defined and interoperable > abuse) 32b > > tag field for this purpose. > > That's pretty much what the OSPF tag and the BGP's synchronisation with > OSPF were originally intended for. > > However it's pretty much a design misfeature and you'd be happier with > iBGP over a tunnel > > -glen From saku at ytti.fi Fri Mar 7 07:11:50 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 7 Mar 2014 09:11:50 +0200 Subject: BGP attributes through IGP In-Reply-To: References: <20140306210932.GA8413@pob.ytti.fi> Message-ID: <20140307071150.GA21162@pob.ytti.fi> On (2014-03-07 10:49 +1030), Glen Turner wrote: > That's pretty much what the OSPF tag and the BGP's synchronisation with OSPF were originally intended for. 1403 (1364) is historic and never referenced by OSPF standard. Original intention for external tag is unspecified information carried between AS borders. > However it's pretty much a design misfeature and you'd be happier with iBGP over a tunnel Agreed. If this is common requirement, nothing stopping figuring out new LSA/LSP to properly carry BGP information. Of course won't be solution for near-term, unless OP controls the edge and uses open source implementation, in which case he might send this information in opaque LSA. -- ++ytti From bmanning at vacation.karoshi.com Fri Mar 7 10:04:09 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 7 Mar 2014 02:04:09 -0800 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <86k3c7cw5w.fsf@valhalla.seastrom.com> References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> <86k3c7cw5w.fsf@valhalla.seastrom.com> Message-ID: <20140307100409.GA26837@vacation.karoshi.com> On Thu, Mar 06, 2014 at 08:07:55AM -0500, Rob Seastrom wrote: > > Nick Hilliard writes: > > >> haven't you heard about "anycast"?? > > > > rs probably has. The owner of 199.73.57.122, probably not. > > indeed. there are many pieces of evidence that this is not an anycast > prefix. proof is left as an exercise to those who can perform > traceroutes from multiple continents, run nmap -sP, log into > route-views, or do some combination of the above. > > -r > sorry for the poor attempt at humour... it was ancient practice to hang many names (not cnames) off a single IP address. all perfectly legal from a DNS POV. rs.example.org. in a 10.10.10.53 nick.example.com. in a 10.10.10.53 bbss.isc.org. in a 10.10.10.53 the punchline here was "anycasting" the address across multiple names. nary a routing trick in sight or in play. Lame I know. as a tool to defeat the autobots who insist on "two nameservers" for a delegation - its kind of a clever poke in the eye w/ a sharp stick. Back to my oubliette /bill From rs at seastrom.com Fri Mar 7 11:03:15 2014 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 07 Mar 2014 06:03:15 -0500 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <20140307100409.GA26837@vacation.karoshi.com> (bmanning@vacation.karoshi.com's message of "Fri, 7 Mar 2014 02:04:09 -0800") References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> <86k3c7cw5w.fsf@valhalla.seastrom.com> <20140307100409.GA26837@vacation.karoshi.com> Message-ID: <8638iu8e4s.fsf@valhalla.seastrom.com> bmanning at vacation.karoshi.com writes: > sorry for the poor attempt at humour... > it was ancient practice to hang many names (not cnames) > off a single IP address. all perfectly legal from a DNS POV. > > rs.example.org. in a 10.10.10.53 > nick.example.com. in a 10.10.10.53 > bbss.isc.org. in a 10.10.10.53 it's also a poor practice operationally and one that's been deprecated for decades. i have a vague recollection of an rfc that said secondary nameservers ought not be connected to the same psn (remember those?) but my google fu fails me this early in the morning. nevertheless, i direct our august audience to rfc 1537 section 6 (october 1993). it's entirely reasonable to bring up this configuration misstep in the context of things acting hinky. > the punchline here was "anycasting" the address across multiple names. > nary a routing trick in sight or in play. "When *I* use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it mean to neither more nor less."' > Lame I know. > > as a tool to defeat the autobots who insist on "two nameservers" > for a delegation - its kind of a clever poke in the eye w/ a > sharp stick. I hear the owners' manual for Fords tells you how to turn off the seat belt alarm too. Clever in rather the same way. -r From ahebert at pubnix.net Fri Mar 7 13:36:13 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 07 Mar 2014 08:36:13 -0500 Subject: BCP38, DNS Reflection and IPv6 Message-ID: <5319CB4D.5010404@pubnix.net> A few observations for this Friday. ------ We where finally able to register our NS IPv6 with NetSol and I just noticed IPv6 DNS Reflection Attempts (*) starting a few days after. * By attempts, they could also be probes from projects, but they need to be pretty aggressive to end up listed here. Examples with logs: Toward HE Tunnels 2001:470:6d:5b8::12 1138 queries: . IN ANY +ED () Toward RackSpace 2001:4801:7821:77:7c1b:4e53:ff10:4961 2191 queries: . IN ANY +ED () There is also 2 more to HE Tunnels and 1 to OVH, but we only archive a few GB of query logs. Having none of the volume, I wonder how bad would it be to ACL a source IPv6 (/56 to /32) on most CPE, local & regional distribution routers. ----- On another note, the same honeypot was receiving a constant stream of 1Mbps in reflection DNS queries, from the 22th at 13h EST until the 28th at 5h30m EST. My guess is that the CC renew transaction didn't pass or the CC finally returned as stolen. ----- This morning doc.gov is very popular on the pot, about 10k bytes worth of DNSSEC KEY and SIG. And they're just doing from 25 to 50 queries then stopping for 10s to a minute. I have a good idea why. -- ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From me at staticsafe.ca Fri Mar 7 14:35:05 2014 From: me at staticsafe.ca (staticsafe) Date: Fri, 07 Mar 2014 09:35:05 -0500 Subject: Fwd: [menog] APRICOT2014 Archives Message-ID: <5319D919.6060008@staticsafe.ca> ---------- Forwarded message ---------- From: Miwa Fujii Date: Fri, Mar 7, 2014 at 2:36 AM Subject: [menog] APRICOT2014 Archives To: "menog at menog.org" Hi MENOG members, APRICOT2014 is over now and archived materials are available in: https://2014.apricot.net/program As usual, there were lots of interesting sessions. Here is some sessions to look into as examples of great archives - these are sessions on CGN, managing IPv4 address exhaustion, IPv6 in mobile networs: APNIC Plenary: Anatomy of CGN ============================= Geoff (APNIC), Shin Miyakawa (NTT), Sunny Yeung (Telstra) and Alastair Johnson (Alcatel-Lucent) discussed on CGN. http://www.youtube.com/watch?v=IF7AnAFYrzc https://2014.apricot.net/program#session/66283 IPv6 in Mobile Networks Tutorial bu Sunny Young (Telstra) ========================================================= https://2014.apricot.net/program#session/66936 464XLAT: Breaking Free of IPv4 Tutorial by Cameron Byrne (T-Mobile USA) ======================================================================= https://2014.apricot.net/program#session/66932 Short video clips ================= Shin Miyakawa (NTT COM): CGNs and IPv6 http://www.youtube.com/watch?v=J3YD8KG8HaQ Cameron Byrne (T-Mobile USA): T-Mobile's positive experience in deploying IPv6 for its network http://www.youtube.com/watch?v=8yW3cSIm8Bg Sunny Yeung (Australia Telstra): The importance of IPv6 to Telstra's future http://www.youtube.com/watch?v=oStlNQm8je0 Alastair Johnson (Alcatel-Lucent): His thoughts on the trends of network operators around the transition from IPv4 to IPv6 in Asia-Pacific http://www.youtube.com/watch?v=mzp8fWp_srQ&list=PLSnVjSuzLJcyFNlG3JSBTnC76S 25HOLj8 Geoff Huston (APNIC): A brief history of CGNs and the implications for the future of IPv4 and IPv6 http://www.youtube.com/watch?v=H2awlfgM02w&list=PLSnVjSuzLJcyFNlG3JSBTnC76S 25HOLj8 Hope you find something useful for your day to day operations. Cheers, Miwa ----------------------------------------- Miwa Fujii Senior Advisor, Internet Development, APNIC www.apnic.net www.apnic.net/ipv6 TEL: +61 7 3858 3100 ----------------------------------------- -- staticsafe From jason at lixfeld.ca Fri Mar 7 16:07:11 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 7 Mar 2014 11:07:11 -0500 Subject: Who uses ARIN's IRR? Message-ID: I don't need to use it much, but when I do, it's an ever-increasing royal pain in the ass. My current plight revolves around not being able to get full dumps of objects. Certain mandatory fields in objects are 'filtered' and/or replaced with dummy data. This poses a problem because one can no longer simply cut and paste the output, change the necessary bits and fire it off to rr at arin.net for processing. WhoisRWS doesn't seem to have hooks into the IRR database like RIPE seems to have gotten right. So how do people tend to get around this? Is there something that I'm missing or do people just throw their hands up and move their IRR data to RADB or something? From David.Siegel at Level3.com Fri Mar 7 16:18:28 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Fri, 7 Mar 2014 16:18:28 +0000 Subject: valley free routing? In-Reply-To: References: Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05C1427A8@USIDCWVEMBX05.corp.global.level3.com> Having been employed by a provider V in one such example of the below, I viewed it as a temporary, partial transit relationship. Does such a situation meet Bill's original definition? -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Thursday, March 06, 2014 7:42 AM To: William Herrin Cc: North American Network Operators' Group Subject: Re: valley free routing? once upon a time, provider A and provider P were having a peering war, and provider V provided valley transit for P's prefixes to A. it was not meant to be seen publicly, but the traceroutes were posted to nanog, or maybe it was com-priv at the time. this is far from the only time this has happened. randy From bill at herrin.us Fri Mar 7 16:40:14 2014 From: bill at herrin.us (William Herrin) Date: Fri, 7 Mar 2014 11:40:14 -0500 Subject: valley free routing? In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC05C1427A8@USIDCWVEMBX05.corp.global.level3.com> References: <970945E55BFD8C4EA4CAD74B647A9DC05C1427A8@USIDCWVEMBX05.corp.global.level3.com> Message-ID: On Fri, Mar 7, 2014 at 11:18 AM, Siegel, David wrote: > Having been employed by a provider V in one such example of the below, > I viewed it as a temporary, partial transit relationship. Does such a > situation meet Bill's original definition? Hi David, I think you have the right of it. That the recipient elects only to use the link for a limited set of destinations is an ordinary part of transit service. In Randy's example, a peering link was converted to a transit link on a short term basis. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From andrew.koch at tdstelecom.com Fri Mar 7 17:01:12 2014 From: andrew.koch at tdstelecom.com (Koch, Andrew) Date: Fri, 7 Mar 2014 17:01:12 +0000 Subject: Who uses ARIN's IRR? In-Reply-To: References: Message-ID: <9FD362844B11AF4BBFE6DBFE0B5619511EBDDB9C@cmailbox7> > -----Original Message----- > From: Jason Lixfeld [mailto:jason at lixfeld.ca] > Sent: Friday, March 07, 2014 10:07 > To: NANOG > Subject: Who uses ARIN's IRR? > > I don't need to use it much, but when I do, it's an ever-increasing royal > pain in the ass. > > My current plight revolves around not being able to get full dumps of > objects. Certain mandatory fields in objects are 'filtered' and/or > replaced with dummy data. This poses a problem because one can no longer > simply cut and paste the output, change the necessary bits and fire it off > to rr at arin.net for processing. WhoisRWS doesn't seem to have hooks into > the IRR database like RIPE seems to have gotten right. > > So how do people tend to get around this? Is there something that I'm > missing or do people just throw their hands up and move their IRR data to > RADB or something? You will notice right at the top of the output there is a hint on getting an unfiltered object. Try using the -B flag on your query to get around this. [elm:usrako]: whois -h rr.arin.net " 64.50.224.0 " % This is the ARIN Routing Registry. % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '64.50.224.0/19AS4181' route: 64.50.224.0/19 descr: TDS Telecom origin: AS4181 mnt-by: MNT-TDST source: ARIN # Filtered [elm:usrako]: whois -h rr.arin.net " -B 64.50.224.0 " % This is the ARIN Routing Registry. % Information related to '64.50.224.0/19AS4181' route: 64.50.224.0/19 descr: TDS Telecom origin: AS4181 mnt-by: MNT-TDST changed: andrew.koch at tdstelecom.com 20100526 source: ARIN HTH, Andy Koch TDS Telecom - IP Network Operations andrew.koch at tdstelecom.com From jason at lixfeld.ca Fri Mar 7 17:05:15 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 7 Mar 2014 12:05:15 -0500 Subject: Who uses ARIN's IRR? In-Reply-To: <9FD362844B11AF4BBFE6DBFE0B5619511EBDDB9C@cmailbox7> References: <9FD362844B11AF4BBFE6DBFE0B5619511EBDDB9C@cmailbox7> Message-ID: On Mar 7, 2014, at 12:01 PM, Koch, Andrew wrote: > You will notice right at the top of the output there is a hint on getting an unfiltered object. Try using the -B flag on your query to get around this. Indeed, however that doesn't help with the dummy objects that also make it impossible to use the output as a new template like everyone has been doing for a hundred years. From contact at winterei.se Fri Mar 7 17:14:46 2014 From: contact at winterei.se (Paul S.) Date: Sat, 08 Mar 2014 02:14:46 +0900 Subject: Who uses ARIN's IRR? In-Reply-To: References: Message-ID: <5319FE86.4000309@winterei.se> On 3/8/2014 ?? 01:07, Jason Lixfeld wrote: > I don't need to use it much, but when I do, it's an ever-increasing royal pain in the ass. > > My current plight revolves around not being able to get full dumps of objects. Certain mandatory fields in objects are 'filtered' and/or replaced with dummy data. This poses a problem because one can no longer simply cut and paste the output, change the necessary bits and fire it off to rr at arin.net for processing. WhoisRWS doesn't seem to have hooks into the IRR database like RIPE seems to have gotten right. > > So how do people tend to get around this? Is there something that I'm missing or do people just throw their hands up and move their IRR data to RADB or something? You'll likely have a lot more peace of mind by moving to RADB anyway, ARIN's IRR is way too unflexible for use -- at least in my opinion. From randy at psg.com Fri Mar 7 17:52:13 2014 From: randy at psg.com (Randy Bush) Date: Fri, 07 Mar 2014 17:52:13 +0000 Subject: valley free routing? In-Reply-To: References: <970945E55BFD8C4EA4CAD74B647A9DC05C1427A8@USIDCWVEMBX05.corp.global.level3.com> Message-ID: > I think you have the right of it. That the recipient elects only to > use the link for a limited set of destinations is an ordinary part of > transit service. In Randy's example, a peering link was converted to a > transit link on a short term basis. you know the term? From cscora at apnic.net Fri Mar 7 18:11:55 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Mar 2014 04:11:55 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201403071811.s27IBtkb030195@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Mar, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 485175 Prefixes after maximum aggregation: 191734 Deaggregation factor: 2.53 Unique aggregates announced to Internet: 240090 Total ASes present in the Internet Routing Table: 46277 Prefixes per ASN: 10.48 Origin-only ASes present in the Internet Routing Table: 35607 Origin ASes announcing only one prefix: 16396 Transit ASes present in the Internet Routing Table: 6052 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1875 Unregistered ASNs in the Routing Table: 485 Number of 32-bit ASNs allocated by the RIRs: 6056 Number of 32-bit ASNs visible in the Routing Table: 4618 Prefixes from 32-bit ASNs in the Routing Table: 14855 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 443 Number of addresses announced to Internet: 2657868548 Equivalent to 158 /8s, 107 /16s and 219 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.8 Total number of prefixes smaller than registry allocations: 168995 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 115350 Total APNIC prefixes after maximum aggregation: 34578 APNIC Deaggregation factor: 3.34 Prefixes being announced from the APNIC address blocks: 117967 Unique aggregates announced from the APNIC address blocks: 49596 APNIC Region origin ASes present in the Internet Routing Table: 4890 APNIC Prefixes per ASN: 24.12 APNIC Region origin ASes announcing only one prefix: 1225 APNIC Region transit ASes present in the Internet Routing Table: 861 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 855 Number of APNIC addresses announced to Internet: 730759040 Equivalent to 43 /8s, 142 /16s and 127 /24s Percentage of available APNIC address space announced: 85.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 166347 Total ARIN prefixes after maximum aggregation: 82770 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 167732 Unique aggregates announced from the ARIN address blocks: 78116 ARIN Region origin ASes present in the Internet Routing Table: 16170 ARIN Prefixes per ASN: 10.37 ARIN Region origin ASes announcing only one prefix: 6120 ARIN Region transit ASes present in the Internet Routing Table: 1667 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 71 Number of ARIN addresses announced to Internet: 1066741632 Equivalent to 63 /8s, 149 /16s and 47 /24s Percentage of available ARIN address space announced: 56.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, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 121984 Total RIPE prefixes after maximum aggregation: 61753 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 125946 Unique aggregates announced from the RIPE address blocks: 79923 RIPE Region origin ASes present in the Internet Routing Table: 17630 RIPE Prefixes per ASN: 7.14 RIPE Region origin ASes announcing only one prefix: 8298 RIPE Region transit ASes present in the Internet Routing Table: 2866 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2648 Number of RIPE addresses announced to Internet: 656662148 Equivalent to 39 /8s, 35 /16s and 222 /24s Percentage of available RIPE address space announced: 95.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 54609 Total LACNIC prefixes after maximum aggregation: 9944 LACNIC Deaggregation factor: 5.49 Prefixes being announced from the LACNIC address blocks: 60505 Unique aggregates announced from the LACNIC address blocks: 27859 LACNIC Region origin ASes present in the Internet Routing Table: 2071 LACNIC Prefixes per ASN: 29.22 LACNIC Region origin ASes announcing only one prefix: 549 LACNIC Region transit ASes present in the Internet Routing Table: 425 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1033 Number of LACNIC addresses announced to Internet: 151999104 Equivalent to 9 /8s, 15 /16s and 82 /24s Percentage of available LACNIC address space announced: 90.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11913 Total AfriNIC prefixes after maximum aggregation: 2652 AfriNIC Deaggregation factor: 4.49 Prefixes being announced from the AfriNIC address blocks: 12582 Unique aggregates announced from the AfriNIC address blocks: 4226 AfriNIC Region origin ASes present in the Internet Routing Table: 705 AfriNIC Prefixes per ASN: 17.85 AfriNIC Region origin ASes announcing only one prefix: 204 AfriNIC Region transit ASes present in the Internet Routing Table: 152 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 11 Number of AfriNIC addresses announced to Internet: 51382784 Equivalent to 3 /8s, 16 /16s and 10 /24s Percentage of available AfriNIC address space announced: 51.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2983 11580 895 Korea Telecom 17974 2757 903 78 PT Telekomunikasi Indonesia 7545 2196 320 117 TPG Telecom Limited 4755 1834 396 196 TATA Communications formerly 9829 1594 1283 39 National Internet Backbone 9583 1307 102 534 Sify Limited 7552 1250 1082 13 Viettel Corporation 9498 1241 311 77 BHARTI Airtel Ltd. 4808 1181 2123 359 CNCGROUP IP network China169 24560 1111 384 176 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3020 3688 53 BellSouth.net Inc. 22773 2320 2938 140 Cox Communications Inc. 1785 2180 693 127 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1688 1673 576 Charter Communications 4323 1622 1089 412 tw telecom holdings, inc. 701 1491 11174 763 MCI Communications Services, 30036 1385 298 556 Mediacom Communications Corp 6983 1322 815 307 ITC^Deltacom 22561 1300 401 228 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1690 544 16 OJSC "Vimpelcom" 34984 1472 264 248 TELLCOM ILETISIM HIZMETLERI A 20940 1286 497 967 Akamai International B.V. 13188 1048 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 891 370 41 Bezeq International-Ltd 6849 830 361 34 JSC "Ukrtelecom" 6830 775 2331 426 Liberty Global Operations B.V 12479 712 798 51 France Telecom Espana SA 35228 555 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3539 1938 93 NET Servi?os de Comunica??o S 10620 2776 443 182 Telmex Colombia S.A. 18881 1916 972 21 Global Village Telecom 7303 1696 1169 219 Telecom Argentina S.A. 8151 1374 2883 415 Uninet S.A. de C.V. 6503 943 434 61 Axtel, S.A.B. de C.V. 11830 875 364 15 Instituto Costarricense de El 27947 853 113 48 Telconet S.A 7738 846 1626 39 Telemar Norte Leste S.A. 3816 783 316 126 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1638 240 6 Sudanese Mobile Telephone (ZA 24863 922 376 28 Link Egypt (Link.NET) 6713 602 685 28 Office National des Postes et 8452 529 958 13 TE-AS 24835 299 144 9 Vodafone Data 36992 264 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29571 207 22 17 Cote d'Ivoire Telecom 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3539 1938 93 NET Servi?os de Comunica??o S 6389 3020 3688 53 BellSouth.net Inc. 4766 2983 11580 895 Korea Telecom 10620 2776 443 182 Telmex Colombia S.A. 17974 2757 903 78 PT Telekomunikasi Indonesia 22773 2320 2938 140 Cox Communications Inc. 7545 2196 320 117 TPG Telecom Limited 1785 2180 693 127 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1916 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3020 2967 BellSouth.net Inc. 17974 2757 2679 PT Telekomunikasi Indonesia 10620 2776 2594 Telmex Colombia S.A. 22773 2320 2180 Cox Communications Inc. 4766 2983 2088 Korea Telecom 7545 2196 2079 TPG Telecom Limited 1785 2180 2053 PaeTec Communications, Inc. 18881 1916 1895 Global Village Telecom 18566 2048 1870 MegaPath Corporation 8402 1690 1674 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:16 /9:12 /10:30 /11:90 /12:255 /13:474 /14:953 /15:1652 /16:12863 /17:6749 /18:11504 /19:23775 /20:33619 /21:36378 /22:51935 /23:45220 /24:257403 /25:795 /26:942 /27:434 /28:12 /29:18 /30:7 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 6389 1696 3020 BellSouth.net Inc. 36998 1599 1638 Sudanese Mobile Telephone (ZA 22773 1560 2320 Cox Communications Inc. 8402 1371 1690 OJSC "Vimpelcom" 30036 1223 1385 Mediacom Communications Corp 11492 1174 1221 CABLE ONE, INC. 1785 1166 2180 PaeTec Communications, Inc. 6983 1040 1322 ITC^Deltacom 34984 999 1472 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:988 2:760 3:3 4:16 5:910 6:19 8:658 12:1858 13:4 14:961 15:9 16:3 17:27 18:21 20:35 23:762 24:1722 27:1766 31:1526 32:44 33:2 34:5 36:118 37:1803 38:927 39:4 40:193 41:3091 42:247 44:18 46:2146 47:15 49:673 50:919 52:12 54:45 55:8 57:26 58:1168 59:596 60:380 61:1524 62:1258 63:1981 64:4353 65:2249 66:4204 67:2066 68:1030 69:3303 70:839 71:471 72:1956 74:2668 75:312 76:394 77:1199 78:989 79:681 80:1298 81:1124 82:665 83:743 84:746 85:1287 86:417 87:1071 88:522 89:1727 90:151 91:5751 92:659 93:1689 94:2030 95:1498 96:535 97:352 98:1069 99:41 100:50 101:791 103:4386 105:534 106:166 107:546 108:547 109:2007 110:997 111:1254 112:634 113:825 114:873 115:1118 116:1039 117:873 118:1322 119:1293 120:365 121:791 122:1920 123:1263 124:1457 125:1452 128:639 129:242 130:360 131:661 132:357 133:157 134:319 135:74 136:248 137:301 138:349 139:159 140:212 141:362 142:559 143:429 144:497 145:97 146:596 147:459 148:792 149:342 150:161 151:580 152:420 153:204 154:93 155:461 156:334 157:368 158:224 159:863 160:353 161:478 162:1218 163:221 164:689 165:612 166:281 167:600 168:1026 169:123 170:1224 171:195 172:20 173:1627 174:680 175:603 176:1469 177:2810 178:1967 179:562 180:1640 181:976 182:1461 183:491 184:698 185:1367 186:2743 187:1455 188:1872 189:1300 190:7438 191:107 192:7146 193:5447 194:4014 195:3348 196:1347 197:1112 198:4959 199:5594 200:6048 201:2687 202:8968 203:8888 204:4659 205:2666 206:2946 207:2902 208:3972 209:3726 210:3072 211:1698 212:2216 213:2019 214:895 215:84 216:5510 217:1688 218:565 219:321 220:1296 221:595 222:342 223:605 End of report From marco at paesani.it Fri Mar 7 11:31:03 2014 From: marco at paesani.it (Marco Paesani) Date: Fri, 7 Mar 2014 12:31:03 +0100 Subject: As path for Junos Message-ID: Hi Everyone, I need a help to transform this Cisco IOS command: ip as-path access-list 50 permit _([0-9]+)_\1_\1_ in Juniper JUNOS policy-options. Best regards, Marco M. +39 348 6019349 From mloftis at wgops.com Fri Mar 7 19:26:14 2014 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 7 Mar 2014 11:26:14 -0800 Subject: As path for Junos In-Reply-To: References: Message-ID: http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html There's no backref support in the regex subset that juniper has chosen to implement, see http://juniper.cluepon.net/index.php/ER_Detect_AS-PATH_prepends - and I don't think Juniper has gone anywhere with that engineering request. On Fri, Mar 7, 2014 at 3:31 AM, Marco Paesani wrote: > Hi Everyone, > I need a help to transform this Cisco IOS command: > > ip as-path access-list 50 permit _([0-9]+)_\1_\1_ > > in Juniper JUNOS policy-options. > Best regards, > Marco > M. +39 348 6019349 -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From pmsac.nanog at gmail.com Fri Mar 7 19:44:10 2014 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Fri, 7 Mar 2014 19:44:10 +0000 Subject: As path for Junos In-Reply-To: References: Message-ID: On 7 March 2014 19:26, Michael Loftis wrote: > > http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html > > There's no backref support in the regex subset that juniper has chosen > to implement, see > http://juniper.cluepon.net/index.php/ER_Detect_AS-PATH_prepends > > - and I don't think Juniper has gone anywhere with that engineering > request. > Why wouldn't ".{3}" work, for this case? > > On Fri, Mar 7, 2014 at 3:31 AM, Marco Paesani wrote: > > Hi Everyone, > > I need a help to transform this Cisco IOS command: > > > > ip as-path access-list 50 permit _([0-9]+)_\1_\1_ > > > > in Juniper JUNOS policy-options. > > Best regards, > > Marco > > M. +39 348 6019349 > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > > From pmsac.nanog at gmail.com Fri Mar 7 19:47:06 2014 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Fri, 7 Mar 2014 19:47:06 +0000 Subject: As path for Junos In-Reply-To: References: Message-ID: On 7 March 2014 19:44, Pedro Cavaca wrote: > > > > On 7 March 2014 19:26, Michael Loftis wrote: > >> >> http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html >> >> There's no backref support in the regex subset that juniper has chosen >> to implement, see >> http://juniper.cluepon.net/index.php/ER_Detect_AS-PATH_prepends >> >> - and I don't think Juniper has gone anywhere with that engineering >> request. >> > > Why wouldn't ".{3}" work, for this case? > > Or, to better align with the given Cisco example: ".* .{3} .*" > >> On Fri, Mar 7, 2014 at 3:31 AM, Marco Paesani wrote: >> > Hi Everyone, >> > I need a help to transform this Cisco IOS command: >> > >> > ip as-path access-list 50 permit _([0-9]+)_\1_\1_ >> > >> > in Juniper JUNOS policy-options. >> > Best regards, >> > Marco >> > M. +39 348 6019349 >> >> >> >> -- >> >> "Genius might be described as a supreme capacity for getting its >> possessors >> into trouble of all kinds." >> -- Samuel Butler >> >> > From bill at herrin.us Fri Mar 7 19:52:34 2014 From: bill at herrin.us (William Herrin) Date: Fri, 7 Mar 2014 14:52:34 -0500 Subject: valley free routing? In-Reply-To: References: <970945E55BFD8C4EA4CAD74B647A9DC05C1427A8@USIDCWVEMBX05.corp.global.level3.com> Message-ID: On Fri, Mar 7, 2014 at 12:52 PM, Randy Bush wrote: >> I think you have the right of it. That the recipient elects only to >> use the link for a limited set of destinations is an ordinary part of >> transit service. In Randy's example, a peering link was converted to a >> transit link on a short term basis. > > you know the term? Hi Randy, For my interests I don't care about the duration. Five minutes or five years it's all the same to me. I care about the characteristics of the relationship while it's ongoing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cidr-report at potaroo.net Fri Mar 7 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Mar 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201403072200.s27M00KQ077247@wattle.apnic.net> This report has been generated at Fri Mar 7 21:13:49 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-02-14 491597 276347 01-03-14 491460 275962 02-03-14 491205 275926 03-03-14 490989 276308 04-03-14 491898 277222 05-03-14 492098 277901 06-03-14 492533 277663 07-03-14 492316 277499 AS Summary 46446 Number of ASes in routing system 19038 Number of ASes announcing only one prefix 3529 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A. 119657472 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'). --- 07Mar14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 492224 277483 214741 43.6% All ASes AS28573 3529 105 3424 97.0% NET Servi?os de Comunica??o S.A. AS6389 3020 56 2964 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2740 173 2567 93.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2983 904 2079 69.7% KIXS-AS-KR Korea Telecom AS18881 1916 25 1891 98.7% Global Village Telecom AS1785 2180 424 1756 80.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS36998 1638 99 1539 94.0% SDN-MOBITEL AS18566 2048 565 1483 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2880 1478 1402 48.7% TWTC - tw telecom holdings, inc. AS10620 2776 1423 1353 48.7% Telmex Colombia S.A. AS7303 1752 450 1302 74.3% Telecom Argentina S.A. AS4755 1834 620 1214 66.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 2198 1069 1129 51.4% TPG-INTERNET-AP TPG Telecom Limited AS22561 1300 237 1063 81.8% AS22561 - CenturyTel Internet Holdings, Inc. AS7552 1251 206 1045 83.5% VIETEL-AS-AP Viettel Corporation AS6983 1325 316 1009 76.2% ITCDELTA - ITC^Deltacom AS9829 1594 646 948 59.5% BSNL-NIB National Internet Backbone AS22773 2324 1403 921 39.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4808 1181 398 783 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4788 991 228 763 77.0% TMNET-AS-AP TM Net, Internet Service Provider AS35908 875 112 763 87.2% VPLSNET - Krypt Technologies AS18101 919 163 756 82.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1111 377 734 66.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS701 1490 762 728 48.9% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1384 674 710 51.3% Uninet S.A. de C.V. AS855 761 57 704 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7738 846 147 699 82.6% Telemar Norte Leste S.A. AS4780 1030 363 667 64.8% SEEDNET Digital United Inc. AS6147 768 113 655 85.3% Telefonica del Peru S.A.A. AS9808 941 286 655 69.6% CMNET-GD Guangdong Mobile Communication Co.Ltd. Total 51585 13879 37706 73.1% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc. 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 103.244.236.0/22 AS58794 103.245.16.0/22 AS18097 DCN D.C.N. Corporation 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 162.244.44.0/24 AS30466 CAXD - Cable Axion Digitel Inc. 162.244.45.0/24 AS30466 CAXD - Cable Axion Digitel Inc. 162.244.46.0/24 AS30466 CAXD - Cable Axion Digitel Inc. 162.244.47.0/24 AS30466 CAXD - Cable Axion Digitel Inc. 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc. 172.85.0.0/24 AS29571 CITelecom-AS 172.85.1.0/24 AS29571 CITelecom-AS 172.85.2.0/24 AS29571 CITelecom-AS 172.85.3.0/24 AS29571 CITelecom-AS 172.86.0.0/24 AS29571 CITelecom-AS 172.86.1.0/24 AS29571 CITelecom-AS 172.86.2.0/24 AS29571 CITelecom-AS 172.87.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 187.109.160.0/24 AS26270 187.109.161.0/24 AS26270 187.109.162.0/24 AS26270 187.109.163.0/24 AS26270 187.109.164.0/24 AS26270 187.109.165.0/24 AS26270 187.109.166.0/24 AS26270 187.109.168.0/24 AS26270 187.109.169.0/24 AS26270 187.109.170.0/24 AS26270 187.109.171.0/24 AS26270 187.109.172.0/24 AS26270 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 191.7.168.0/21 AS26286 G30 TELECOM SERVI?OS EM TELECOMUNICA??ES LTDA 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company 192.75.23.0/24 AS2579 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc. 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.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc. 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V. 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 192.241.20.0/24 AS7381 SASUSA SunGard Availability Services USA 192.241.21.0/24 AS7381 SASUSA SunGard Availability Services USA 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.25.216.0/22 AS8220 COLT COLT Technology Services Group Limited 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd 193.28.14.0/24 AS34309 LINK11 Link11 GmbH 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.33.106.0/23 AS42444 193.33.252.0/23 AS3356 LEVEL3 Level 3 Communications 193.36.229.0/24 AS15404 COLT Technology Services Group Limited 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd 193.84.187.0/24 AS16276 OVH OVH SAS 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS 193.111.229.0/24 AS3356 LEVEL3 Level 3 Communications 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A. 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.26.0/24 AS16095 JAYNET jay.net a/s 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd. 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd. 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB 194.9.8.0/23 AS2863 SPRITELINK Centor AB 194.9.8.0/24 AS2863 SPRITELINK Centor AB 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd. 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.55.104.0/23 AS7244 ALAMEDANET - Alameda Networks 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB 194.156.179.0/24 AS3209 VODANET Vodafone GmbH 194.176.123.0/24 AS28717 ZENSYSTEMS-AS Zen Systems A/S 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL 195.39.252.0/23 AS29004 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.85.201.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.178.120.0/23 AS39385 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 196.2.224.0/22 AS24863 LINKdotNET-AS 196.3.182.0/24 AS37004 196.3.183.0/24 AS37004 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.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS SES WORLD SKIES ARIN AS, for routing RIPE space. 196.45.0.0/21 AS26625 196.45.10.0/24 AS26625 196.49.2.0/24 AS33763 Paratus-Telecom 196.216.129.0/24 AS36886 196.216.130.0/24 AS36886 196.216.131.0/24 AS36886 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.72.78.0/23 AS3967 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc. 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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.30.138.0/24 AS23319 199.30.139.0/24 AS23319 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC 199.68.72.0/24 AS174 COGENT Cogent/PSI 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc. 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC 199.91.240.0/21 AS174 COGENT Cogent/PSI 199.116.200.0/21 AS22830 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.188.28.0/22 AS46802 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.196.64.0/24 AS26977 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.164.0/22 AS46099 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.203.80.0/20 AS27021 216.203.80.0/21 AS27021 216.203.87.0/24 AS27021 216.203.88.0/21 AS27021 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 7 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Mar 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201403072200.s27M01TG077264@wattle.apnic.net> BGP Update Report Interval: 27-Feb-14 -to- 06-Mar-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 52218 1.9% 35.4 -- 2 - AS7552 49007 1.8% 38.3 -- 3 - AS29571 44662 1.6% 210.7 -- 4 - AS8402 36489 1.3% 18.8 -- 5 - AS28573 23574 0.8% 6.5 -- 6 - AS13118 22141 0.8% 503.2 -- 7 - AS41691 19274 0.7% 876.1 -- 8 - AS4775 18833 0.7% 241.4 -- 9 - AS10620 18757 0.7% 6.8 -- 10 - AS45899 16778 0.6% 43.6 -- 11 - AS17974 15783 0.6% 5.8 -- 12 - AS25184 15720 0.6% 127.8 -- 13 - AS11976 14327 0.5% 135.2 -- 14 - AS45169 13545 0.5% 903.0 -- 15 - AS8151 12840 0.5% 9.1 -- 16 - AS7497 12680 0.5% 33.8 -- 17 - AS18881 12373 0.4% 6.5 -- 18 - AS31148 11679 0.4% 11.5 -- 19 - AS50710 11357 0.4% 50.5 -- 20 - AS6629 11039 0.4% 157.7 -- TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS39382 6322 0.2% 3161.0 -- 2 - AS54465 8174 0.3% 2724.7 -- 3 - AS56488 1958 0.1% 1958.0 -- 4 - AS45169 13545 0.5% 903.0 -- 5 - AS2 4426 0.2% 638.0 -- 6 - AS41691 19274 0.7% 876.1 -- 7 - AS42740 3812 0.1% 762.4 -- 8 - AS62431 698 0.0% 698.0 -- 9 - AS60345 1149 0.0% 574.5 -- 10 - AS57201 570 0.0% 570.0 -- 11 - AS16561 3267 0.1% 544.5 -- 12 - AS2 523 0.0% 2004.0 -- 13 - AS13118 22141 0.8% 503.2 -- 14 - AS47151 997 0.0% 498.5 -- 15 - AS4 477 0.0% 117.0 -- 16 - AS39575 472 0.0% 472.0 -- 17 - AS33995 470 0.0% 470.0 -- 18 - AS45703 931 0.0% 465.5 -- 19 - AS40524 908 0.0% 454.0 -- 20 - AS11054 10132 0.4% 440.5 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21947 0.8% AS13118 -- 2 - 89.221.206.0/24 19217 0.7% AS41691 -- 3 - 192.58.232.0/24 10745 0.4% AS6629 -- 4 - 78.109.192.0/20 9531 0.3% AS25184 -- 5 - 222.127.0.0/24 9366 0.3% AS4775 -- 7 - 206.152.15.0/24 8170 0.3% AS54465 -- 8 - 67.210.190.0/23 7952 0.3% AS11976 -- 9 - 205.247.12.0/24 7687 0.3% AS6459 -- 10 - 103.11.61.0/24 7000 0.2% AS9387 -- 11 - 216.109.107.0/24 6516 0.2% AS11486 -- AS16561 -- 12 - 200.23.126.0/24 6499 0.2% AS8151 -- 13 - 67.210.188.0/23 6016 0.2% AS11976 -- 14 - 199.187.118.0/24 4684 0.2% AS11054 -- 15 - 42.83.48.0/20 3493 0.1% AS18135 -- 16 - 2.93.235.0/24 3419 0.1% AS8402 -- 17 - 195.178.104.0/24 3162 0.1% AS39382 -- 18 - 195.178.105.0/24 3160 0.1% AS39382 -- 19 - 216.57.5.0/24 2877 0.1% AS12006 -- 20 - 72.52.128.0/17 2784 0.1% AS32244 -- Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From bmeshier at amherst.com Fri Mar 7 22:12:57 2014 From: bmeshier at amherst.com (Meshier, Brent) Date: Fri, 7 Mar 2014 22:12:57 +0000 Subject: Need ARIN routing registry help Message-ID: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> Level3 won't let us advertise our netblock because RADB shows it owned by Telkom South Africa, but it's clearly assigned to us by ARIN. I've raised a question with ARIN, could really use someone there that could expedite. On that note, when ARIN re-assigns networks, shouldn't they clear out related entries in the routing registry? --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. From nick at foobar.org Fri Mar 7 22:20:53 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 07 Mar 2014 22:20:53 +0000 Subject: Need ARIN routing registry help In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> Message-ID: <531A4645.4010206@foobar.org> On 07/03/2014 22:12, Meshier, Brent wrote: > Level3 won't let us advertise our netblock because RADB shows it owned > by Telkom South Africa, but it's clearly assigned to us by ARIN. I've > raised a question with ARIN, could really use someone there that could > expedite. On that note, when ARIN re-assigns networks, shouldn't they > clear out related entries in the routing registry? Because they don't control entries in the Merit RADB and hassling them won't get anything removed from there. Why not send an email to radb-support at merit.edu instead, and ask them to delete the entry in whois.radb.net? Nick From bmeshier at amherst.com Fri Mar 7 22:23:20 2014 From: bmeshier at amherst.com (Meshier, Brent) Date: Fri, 7 Mar 2014 22:23:20 +0000 Subject: Need ARIN routing registry help In-Reply-To: <531A4645.4010206@foobar.org> References: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> <531A4645.4010206@foobar.org> Message-ID: <68C2CBC977F3E04799DF9C76E938E7090842D8A5@DFEXCH1.asglp.com> Already spoke to Merit, their response "That's what ARIN is telling us. They correct their Routing Registry, ours will change to match" --Brent -----Original Message----- On 07/03/2014 22:12, Meshier, Brent wrote: > Level3 won't let us advertise our netblock because RADB shows it owned > by Telkom South Africa, but it's clearly assigned to us by ARIN. I've > raised a question with ARIN, could really use someone there that could > expedite. On that note, when ARIN re-assigns networks, shouldn't they > clear out related entries in the routing registry? Because they don't control entries in the Merit RADB and hassling them won't get anything removed from there. Why not send an email to radb-support at merit.edu instead, and ask them to delete the entry in whois.radb.net? Nick --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. From jgreco at ns.sol.net Fri Mar 7 18:34:50 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 7 Mar 2014 12:34:50 -0600 (CST) Subject: Need ARIN routing registry help In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> Message-ID: <201403071834.s27IYoxm046773@aurora.sol.net> > Level3 won't let us advertise our netblock because RADB shows it owned by T= > elkom South Africa, but it's clearly assigned to us by ARIN. I've raised a= > question with ARIN, could really use someone there that could expedite. O= > n that note, when ARIN re-assigns networks, shouldn't they clear out relate= > d entries in the routing registry? Why would ARIN do that, or do other work for you like making sure that the space wasn't listed in DNSBL's, or my local filters? You got the space. It's in your lap to go contact RADB to fix the entries. ... 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 khuon at NEEBU.Net Fri Mar 7 22:29:25 2014 From: khuon at NEEBU.Net (Jake Khuon) Date: Fri, 07 Mar 2014 14:29:25 -0800 Subject: Need ARIN routing registry help In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090842D8A5@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> <531A4645.4010206@foobar.org> <68C2CBC977F3E04799DF9C76E938E7090842D8A5@DFEXCH1.asglp.com> Message-ID: <531A4845.6070400@NEEBU.Net> On 07/03/14 14:23, Meshier, Brent wrote: > Already spoke to Merit, their response "That's what ARIN is telling us. They correct their Routing Registry, ours will change to match" What does the source attribute on the object say? If it's RADB then Merit should be able to help you get the objects cleaned up. But if the source points to ARIN then the original object data is stored in the ARIN IRR you'll have to bug ARIN to get the object cleaned. The NRTM at whois.radb.net should pick up the changes. > -----Original Message----- > > On 07/03/2014 22:12, Meshier, Brent wrote: >> Level3 won't let us advertise our netblock because RADB shows it owned >> by Telkom South Africa, but it's clearly assigned to us by ARIN. I've >> raised a question with ARIN, could really use someone there that could >> expedite. On that note, when ARIN re-assigns networks, shouldn't they >> clear out related entries in the routing registry? > > Because they don't control entries in the Merit RADB and hassling them won't get anything removed from there. > > Why not send an email to radb-support at merit.edu instead, and ask them to delete the entry in whois.radb.net? > > Nick > > > --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. > -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From faisal at snappytelecom.net Fri Mar 7 22:37:48 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 7 Mar 2014 22:37:48 +0000 (GMT) Subject: Need ARIN routing registry help In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090842D8A5@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> <531A4645.4010206@foobar.org> <68C2CBC977F3E04799DF9C76E938E7090842D8A5@DFEXCH1.asglp.com> Message-ID: <724208708.161697.1394231868641.JavaMail.root@snappytelecom.net> "...That's what ARIN is telling us. They correct their Routing Registry, ours will change to match" You are getting caught into a loop here.... May I suggest that you take a closer look at the RADB record and determine which registry it was created by. Your earlier statement implied that the Record was created in (Merit) RADB, however your above statement implies that Merit is telling you that the RADB entry is originating from ARIN RR.. I know ARIN RR is maintained by ARIN, and I am very sure they will help you remove the record. Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Brent Meshier" > To: "Nick Hilliard" , nanog at nanog.org > Sent: Friday, March 7, 2014 5:23:20 PM > Subject: RE: Need ARIN routing registry help > > Already spoke to Merit, their response "That's what ARIN is telling us. They > correct their Routing Registry, ours will change to match" > > --Brent > > -----Original Message----- > > On 07/03/2014 22:12, Meshier, Brent wrote: > > Level3 won't let us advertise our netblock because RADB shows it owned > > by Telkom South Africa, but it's clearly assigned to us by ARIN. I've > > raised a question with ARIN, could really use someone there that could > > expedite. On that note, when ARIN re-assigns networks, shouldn't they > > clear out related entries in the routing registry? > > Because they don't control entries in the Merit RADB and hassling them won't > get anything removed from there. > > Why not send an email to radb-support at merit.edu instead, and ask them to > delete the entry in whois.radb.net? > > Nick > > > --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for > important disclosures regarding this electronic communication. > > From LarrySheldon at cox.net Fri Mar 7 22:50:56 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 07 Mar 2014 16:50:56 -0600 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> <86k3c7cw5w.fsf@valhalla.seastrom.com> <20140307100409.GA26837@vacation.karoshi.com> Message-ID: <531A4D50.1070601@cox.net> On 3/7/2014 5:03 AM, Rob Seastrom wrote: > for decades. i have a vague recollection of an rfc that said > secondary nameservers ought not be connected to the same psn (remember > those?) but my google fu fails me this early in the morning. Packet Switch Node? Not sure what would be in this context. Not on the same router? How about two routers away with both THEM on the same router (a third one)? Not on a host that does anything else? Both of those actually make some sense to me, the first from a single point of failure consideration, the second regarding unrelated failures (I have to re-boot my windows PC at least once a day, most days because Firefox, the way I use it, gets itself tangled about that often and a reboot is the quickest way to clear it). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From ndavis at arin.net Sat Mar 8 01:38:59 2014 From: ndavis at arin.net (Nate Davis) Date: Sat, 8 Mar 2014 01:38:59 +0000 Subject: Need ARIN routing registry help In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090842D833@DFEXCH1.asglp.com> Message-ID: On 3/7/14 5:12 PM, "Meshier, Brent" wrote: >Level3 won't let us advertise our netblock because RADB shows it owned by >Telkom South Africa, but it's clearly assigned to us by ARIN. I've >raised a question with ARIN, could really use someone there that could >expedite. On that note, when ARIN re-assigns networks, shouldn't they >clear out related entries in the routing registry? >--- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for >important disclosures regarding this electronic communication. Brent, Please contact me off-list with the details of your open request with ARIN, I would be happy to assist. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers From marco at paesani.it Sat Mar 8 06:06:50 2014 From: marco at paesani.it (Marco Paesani) Date: Sat, 8 Mar 2014 07:06:50 +0100 Subject: As path for Junos In-Reply-To: References: Message-ID: Hi, thanks for all info but with my 11.4R7.5 I cannot implement the check. Regards, Marco 2014-03-07 20:47 GMT+01:00 Pedro Cavaca : > > > > On 7 March 2014 19:44, Pedro Cavaca wrote: > >> >> >> >> On 7 March 2014 19:26, Michael Loftis wrote: >> >>> >>> http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html >>> >>> There's no backref support in the regex subset that juniper has chosen >>> to implement, see >>> http://juniper.cluepon.net/index.php/ER_Detect_AS-PATH_prepends >>> >>> - and I don't think Juniper has gone anywhere with that engineering >>> request. >>> >> >> Why wouldn't ".{3}" work, for this case? >> >> > > Or, to better align with the given Cisco example: ".* .{3} .*" > > >> >>> On Fri, Mar 7, 2014 at 3:31 AM, Marco Paesani wrote: >>> > Hi Everyone, >>> > I need a help to transform this Cisco IOS command: >>> > >>> > ip as-path access-list 50 permit _([0-9]+)_\1_\1_ >>> > >>> > in Juniper JUNOS policy-options. >>> > Best regards, >>> > Marco >>> > M. +39 348 6019349 >>> >>> >>> >>> -- >>> >>> "Genius might be described as a supreme capacity for getting its >>> possessors >>> into trouble of all kinds." >>> -- Samuel Butler >>> >>> >> > From saku at ytti.fi Sat Mar 8 08:47:52 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 8 Mar 2014 10:47:52 +0200 Subject: As path for Junos In-Reply-To: References: Message-ID: <20140308084752.GA28924@pob.ytti.fi> On (2014-03-07 19:44 +0000), Pedro Cavaca wrote: > Why wouldn't ".{3}" work, for this case? Because the OP wants a same atom N times, not any atom N times. -- ++ytti From pmsac.nanog at gmail.com Sat Mar 8 09:21:54 2014 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Sat, 8 Mar 2014 09:21:54 +0000 Subject: As path for Junos In-Reply-To: <20140308084752.GA28924@pob.ytti.fi> References: <20140308084752.GA28924@pob.ytti.fi> Message-ID: On 8 March 2014 08:47, Saku Ytti wrote: > On (2014-03-07 19:44 +0000), Pedro Cavaca wrote: > > > Why wouldn't ".{3}" work, for this case? > > Because the OP wants a same atom N times, not any atom N times. > Of course, what was I thinking? I'll crawl back to my hole now... Thanks for being gentle on the clue-bat. > > -- > ++ytti > > From randy at psg.com Sat Mar 8 16:10:58 2014 From: randy at psg.com (Randy Bush) Date: Sat, 08 Mar 2014 16:10:58 +0000 Subject: Who uses ARIN's IRR? In-Reply-To: References: Message-ID: > So how do people tend to get around this? use a sane registry. arin works hard to make their services unusable. it comes from their confusion of being a regulator as opposed to a nic. randy From mpetach at netflight.com Sun Mar 9 19:43:46 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 9 Mar 2014 12:43:46 -0700 Subject: anyone ever get an HWIC-CABLE-D-2 card to work? Message-ID: I'm grasping at straws here, and reaching out to a wider community to find out if there's anyone out there that's been able to get an HWIC-CABLE-D-2 card to work. I figured it was worth giving one more shot before I call and cancel my Comcast account, as it seems silly to pay for a service I can't use. The card synchronizes with the CMTS system, does all the happy dancing back and forth with ranging, etc. and then just hangs waiting for the TFTP transfer to complete. Tried different cables, removing all splitters, plugging in right at the entry point to the facility...no change. :( Here's the config on the interface: netflight-1841#show run int cable-Modem 0/1/0 Building configuration... Current configuration : 344 bytes ! interface Cable-Modem0/1/0 ip address dhcp no ip redirects no ip unreachables no ip proxy-arp ip nbar protocol-discovery ip flow ingress ip nat outside ip virtual-reassembly in load-interval 30 service-module ip rip relay ipv6 address dhcp ipv6 dhcp client pd hint ::/60 ipv6 traffic-filter v6-external-in in no cdp enable end netflight-1841# netflight-1841#show int cable-Modem 0/1/0 Cable-Modem0/1/0 is up, line protocol is down HFC state is IP_COMPLETE, HFC MAC address is 0018.19b6.76f6 Hardware is Cable modem, address is 001b.2a7d.adfc (bia 001b.2a7d.adfc) Internet address will be negotiated using DHCP MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not supported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:01, output 00:00:01, output hang never Last clearing of "show interface" counters never Input queue: 0/75/17/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 14000 bits/sec, 19 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec HFC input: 0 errors, 0 discards, 0 unknown protocols 0 flow control discards HFC output: 0 errors, 0 discards 49900914 packets input, 3803706540 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 5 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 34567 packets output, 1519738 bytes, 0 underruns 0 output errors, 0 collisions, 5 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out netflight-1841# netflight-1841#show controllers cable-Modem 0/1/0 mac state Connectivity State: IP complete Boot State: Waiting for TFTP BPI Security: Disabled DOCSIS Operating Mode: DOCSIS 1.0 mode DOCSIS COS Mode: Unregistered Snmp Operating Mode: NmAccess mode MIB Values: Mac Resets: 0 Sync lost: 0 Invalid Maps: 0 Invalid UCDs: 0 Invalid Rng Rsp: 0 Invalid Reg Rsp: 0 T1 Timeouts: 0 T2 Timeouts: 0 T3 Timeouts: 1 T4 Timeouts: 0 Range Aborts: 0 DS Lock : Locked DS Frequency: 651000000 Hz DS QAM Mode: QAM256 DS Power Level: 4.3 dBmV DS Symbol Rate: 5360.537 Ksym/sec DS Interleave: 32 Taps, 4 Increment DS SNR: 38.3 dB US ID: 45 US Frequency: 18900000 Hz US QAM Mode: QPSK US Power Level: 35.7 dBmV US Symbol Rate: 2560 Ksym/sec Ranging Offset: 12226 Mini-Slot Size: 4 Change Count: 1 Preamble Superstring: 03 f0 28 33 eb f0 28 33 eb f0 28 33 eb f0 28 33 eb e1 ee 16 6d e8 73 09 15 d7 92 e7 03 ba 7a 94 0a af ad 06 ed ac 17 7c 79 a6 b8 d1 7f 4b 14 c6 03 32 b2 7e d2 4d f9 6a 14 4e cb d8 6a 9c 86 21 00 88 c8 ea d8 e2 54 6c f9 e2 dc a4 13 3a 3e f0 7f 0d f3 de c0 ed f3 de c0 0d f3 de c0 ed f3 de c0 ed f3 de c0 ed f3 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Burst Descriptors: +--------------+------+------+------+------+------+------+------+------+------+ | | 1 | 2 | 3 | 4 | 5 | 6 | 9 | 10 | 11 | | IUC | Req | Req/ | Init | Per | Short| Long | Adv | Adv | Adv | | | | Data | Maint| Maint| Data | Data | Short| Long | UGS | +--------------+------+------+------+------+------+------+------+------+------+ Modulation: QPSK XXXX QPSK QPSK XXXX XXXX 64QAM 64QAM 64QAM DiffEncoding: Off XXXX Off Off XXXX XXXX Off Off Off PreambleLen: 56 XXXX 640 384 XXXX XXXX 104 104 104 PreambleOffset: 652 XXXX 0 0 XXXX XXXX 716 716 716 FEC T Bytes: 0 XXXX 5 5 XXXX XXXX 12 16 12 FEC K Bytes: 16 XXXX 34 34 XXXX XXXX 81 223 81 Scrambler Seed: 338 XXXX 338 338 XXXX XXXX 338 338 338 Max Burst: 0 XXXX 0 0 XXXX XXXX 11 255 255 Guard Time: 8 XXXX 48 48 XXXX XXXX 8 8 8 Last Codeword: Fixed XXXX Fixed Fixed XXXX XXXX Short Short Short Scrambler: On XXXX On On XXXX XXXX On On On Preamble Type: QPSK1 XXXX QPSK1 QPSK1 XXXX XXXX QPSK1 QPSK1 QPSK1 RsIntrlvrDepth: 1 XXXX 0 0 XXXX XXXX 0 0 0 RsIntrlvrBlkSz: 2048 XXXX 2048 2048 XXXX XXXX 2048 2048 2048 Config File: Network Access: Allowed Maximum Number of CPEs: -1 Concatenation: Enabled Fragmentation: Enabled PHS: Enabled Maximum DS Data Rate: 0 Maximum US Data Rate: 0 Maximum US Burst: 0 Ranging Backoff Start: 2 Ranging Backoff End: 7 TX Backoff Start: 2 TX Backoff End: 8 My offered IP address: 73.72.46.36 CM Configuration file: d11_m_hwiccabled2_economyplus_c01.cm Log Server IP address: 0.0.0.0 TFTP Server IP address: 96.120.88.93 Time Server IP address: 69.252.97.8 Domain Name Server: 68.87.76.178; 68.87.78.130 Lease time: 365673 netflight-1841# If people have ideas on more appropriate forums that might be able to help, I'd love pointers to those as well; search engine searches have been largely fruitless on this so far. Thanks so much for any pointers people can give! Matt From tknchris at gmail.com Sun Mar 9 20:21:51 2014 From: tknchris at gmail.com (chris) Date: Sun, 9 Mar 2014 16:21:51 -0400 Subject: anyone ever get an HWIC-CABLE-D-2 card to work? In-Reply-To: References: Message-ID: Did you have comcast register this card on your account? When you try to browse web do you get redirected like a modem in walled garden state? On Mar 9, 2014 3:46 PM, "Matthew Petach" wrote: > I'm grasping at straws here, and reaching out to a > wider community to find out if there's anyone out > there that's been able to get an HWIC-CABLE-D-2 > card to work. I figured it was worth giving one > more shot before I call and cancel my Comcast > account, as it seems silly to pay for a service I > can't use. > > The card synchronizes with the CMTS system, > does all the happy dancing back and forth with > ranging, etc. and then just hangs waiting for the > TFTP transfer to complete. Tried different cables, > removing all splitters, plugging in right at the entry > point to the facility...no change. :( > > Here's the config on the interface: > > netflight-1841#show run int cable-Modem 0/1/0 > Building configuration... > > Current configuration : 344 bytes > ! > interface Cable-Modem0/1/0 > ip address dhcp > no ip redirects > no ip unreachables > no ip proxy-arp > ip nbar protocol-discovery > ip flow ingress > ip nat outside > ip virtual-reassembly in > load-interval 30 > service-module ip rip relay > ipv6 address dhcp > ipv6 dhcp client pd hint ::/60 > ipv6 traffic-filter v6-external-in in > no cdp enable > end > > netflight-1841# > > > netflight-1841#show int cable-Modem 0/1/0 > Cable-Modem0/1/0 is up, line protocol is down > HFC state is IP_COMPLETE, HFC MAC address is 0018.19b6.76f6 > Hardware is Cable modem, address is 001b.2a7d.adfc (bia 001b.2a7d.adfc) > Internet address will be negotiated using DHCP > MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA, loopback not set > Keepalive not supported > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:01, output 00:00:01, output hang never > Last clearing of "show interface" counters never > Input queue: 0/75/17/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 30 second input rate 14000 bits/sec, 19 packets/sec > 30 second output rate 0 bits/sec, 0 packets/sec > HFC input: 0 errors, 0 discards, 0 unknown protocols 0 flow control > discards > HFC output: 0 errors, 0 discards > 49900914 packets input, 3803706540 bytes, 0 no buffer > Received 0 broadcasts (0 IP multicasts) > 0 runts, 0 giants, 5 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 input packets with dribble condition detected > 34567 packets output, 1519738 bytes, 0 underruns > 0 output errors, 0 collisions, 5 interface resets > 0 unknown protocol drops > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier > 0 output buffer failures, 0 output buffers swapped out > netflight-1841# > > > netflight-1841#show controllers cable-Modem 0/1/0 mac state > > Connectivity State: IP complete > Boot State: Waiting for TFTP > BPI Security: Disabled > DOCSIS Operating Mode: DOCSIS 1.0 mode > DOCSIS COS Mode: Unregistered > Snmp Operating Mode: NmAccess mode > > MIB Values: > Mac Resets: 0 > Sync lost: 0 > Invalid Maps: 0 > Invalid UCDs: 0 > Invalid Rng Rsp: 0 > Invalid Reg Rsp: 0 > T1 Timeouts: 0 > T2 Timeouts: 0 > T3 Timeouts: 1 > T4 Timeouts: 0 > Range Aborts: 0 > > DS Lock : Locked > DS Frequency: 651000000 Hz > DS QAM Mode: QAM256 > DS Power Level: 4.3 dBmV > DS Symbol Rate: 5360.537 Ksym/sec > DS Interleave: 32 Taps, 4 Increment > DS SNR: 38.3 dB > > US ID: 45 > US Frequency: 18900000 Hz > US QAM Mode: QPSK > US Power Level: 35.7 dBmV > US Symbol Rate: 2560 Ksym/sec > Ranging Offset: 12226 > Mini-Slot Size: 4 > Change Count: 1 > > > Preamble Superstring: > 03 f0 28 33 eb f0 28 33 eb f0 28 33 eb f0 28 33 > eb e1 ee 16 6d e8 73 09 15 d7 92 e7 03 ba 7a 94 > 0a af ad 06 ed ac 17 7c 79 a6 b8 d1 7f 4b 14 c6 > 03 32 b2 7e d2 4d f9 6a 14 4e cb d8 6a 9c 86 21 > 00 88 c8 ea d8 e2 54 6c f9 e2 dc a4 13 3a 3e f0 > 7f 0d f3 de c0 ed f3 de c0 0d f3 de c0 ed f3 de > c0 ed f3 de c0 ed f3 ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > Burst Descriptors: > > +--------------+------+------+------+------+------+------+------+------+------+ > | | 1 | 2 | 3 | 4 | 5 | 6 | 9 | > 10 | 11 | > | IUC | Req | Req/ | Init | Per | Short| Long | Adv | Adv | Adv | > | | | Data | Maint| Maint| Data | Data | Short| Long | > UGS | > > +--------------+------+------+------+------+------+------+------+------+------+ > Modulation: QPSK XXXX QPSK QPSK XXXX XXXX 64QAM 64QAM 64QAM > DiffEncoding: Off XXXX Off Off XXXX XXXX Off Off Off > PreambleLen: 56 XXXX 640 384 XXXX XXXX 104 104 104 > PreambleOffset: 652 XXXX 0 0 XXXX XXXX 716 716 716 > FEC T Bytes: 0 XXXX 5 5 XXXX XXXX 12 16 12 > FEC K Bytes: 16 XXXX 34 34 XXXX XXXX 81 223 81 > Scrambler Seed: 338 XXXX 338 338 XXXX XXXX 338 338 338 > Max Burst: 0 XXXX 0 0 XXXX XXXX 11 255 255 > Guard Time: 8 XXXX 48 48 XXXX XXXX 8 8 8 > Last Codeword: Fixed XXXX Fixed Fixed XXXX XXXX Short Short Short > Scrambler: On XXXX On On XXXX XXXX On On On > Preamble Type: QPSK1 XXXX QPSK1 QPSK1 XXXX XXXX QPSK1 QPSK1 QPSK1 > RsIntrlvrDepth: 1 XXXX 0 0 XXXX XXXX 0 0 0 > RsIntrlvrBlkSz: 2048 XXXX 2048 2048 XXXX XXXX 2048 2048 2048 > > Config File: > Network Access: Allowed > Maximum Number of CPEs: -1 > Concatenation: Enabled > Fragmentation: Enabled > PHS: Enabled > Maximum DS Data Rate: 0 > Maximum US Data Rate: 0 > Maximum US Burst: 0 > > Ranging Backoff Start: 2 > Ranging Backoff End: 7 > TX Backoff Start: 2 > TX Backoff End: 8 > > My offered IP address: 73.72.46.36 > CM Configuration file: d11_m_hwiccabled2_economyplus_c01.cm > Log Server IP address: 0.0.0.0 > TFTP Server IP address: 96.120.88.93 > Time Server IP address: 69.252.97.8 > Domain Name Server: 68.87.76.178; 68.87.78.130 > Lease time: 365673 > > netflight-1841# > > > If people have ideas on more appropriate > forums that might be able to help, I'd love > pointers to those as well; search engine > searches have been largely fruitless on this > so far. > > Thanks so much for any pointers people > can give! > > Matt > From mpetach at netflight.com Sun Mar 9 20:45:27 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 9 Mar 2014 13:45:27 -0700 Subject: anyone ever get an HWIC-CABLE-D-2 card to work? In-Reply-To: References: Message-ID: On Sun, Mar 9, 2014 at 1:21 PM, chris wrote: > Did you have comcast register this card on your account? When you try to > browse web do you get redirected like a modem in walled garden state? > Yes, I read the HFC MAC address off to the comcast account activation people, and they repeated it back to me to make sure it was correct. I can't browse the web because the line protocol state on the interface is still "down"--until the line protocol comes up, there's no ability to send or receive packets. :( If there were a way to force line protocol to come up, and get an IP address on the interface, I might then be able to get to the captive portal; but without a usable IP address on the interface, there's no packet flow happening at layer 3. :( Thanks! Matt From wbailey at satelliteintelligencegroup.com Sun Mar 9 21:48:41 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 9 Mar 2014 21:48:41 +0000 Subject: anyone ever get an HWIC-CABLE-D-2 card to work? In-Reply-To: References: Message-ID: Some cable providers do weird provisioning stuff with different flavors of DOCSIS. Do you know if your HWIC supports the version of DOCSIS your provider runs? It looks like those cards are good for DOCSIS 2.0, and many new providers are 3.0 by now so that may be something to look into..? On 3/9/14, 2:45 PM, "Matthew Petach" wrote: >On Sun, Mar 9, 2014 at 1:21 PM, chris wrote: > >> Did you have comcast register this card on your account? When you try to >> browse web do you get redirected like a modem in walled garden state? >> > >Yes, I read the HFC MAC address off to the comcast >account activation people, and they repeated it back to >me to make sure it was correct. > >I can't browse the web because the line protocol >state on the interface is still "down"--until the >line protocol comes up, there's no ability to >send or receive packets. :( > >If there were a way to force line protocol to come >up, and get an IP address on the interface, I might >then be able to get to the captive portal; but without >a usable IP address on the interface, there's no packet >flow happening at layer 3. :( > >Thanks! > >Matt From mpetach at netflight.com Mon Mar 10 02:56:47 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 9 Mar 2014 19:56:47 -0700 Subject: anyone ever get an HWIC-CABLE-D-2 card to work? In-Reply-To: References: Message-ID: On Sun, Mar 9, 2014 at 2:48 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Some cable providers do weird provisioning stuff with different flavors of > DOCSIS. Do you know if your HWIC supports the version of DOCSIS your > provider runs? It looks like those cards are good for DOCSIS 2.0, and many > new providers are 3.0 by now so that may be something to look into..? > Comcast does still seem to support DOCSIS 2.0 devices, I know other people that are still using DOCSIS 2.0 devices without issue, so I'm sure it's not just a protocol version number issue. Thanks! Matt From rs at seastrom.com Mon Mar 10 18:57:06 2014 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 10 Mar 2014 14:57:06 -0400 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <531A4D50.1070601@cox.net> (Larry Sheldon's message of "Fri, 07 Mar 2014 16:50:56 -0600") References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> <86k3c7cw5w.fsf@valhalla.seastrom.com> <20140307100409.GA26837@vacation.karoshi.com> <531A4D50.1070601@cox.net> Message-ID: <86y50hevb1.fsf@valhalla.seastrom.com> Larry Sheldon writes: > On 3/7/2014 5:03 AM, Rob Seastrom wrote: > >> for decades. i have a vague recollection of an rfc that said >> secondary nameservers ought not be connected to the same psn (remember >> those?) but my google fu fails me this early in the morning. > > Packet Switch Node? > > Not sure what would be in this context. > > Not on the same router? How about two routers away with both THEM on > the same router (a third one)? A PSN or IMP was an ARPANET/MILNET "core" router. Some sites had more than one. A reasonable carry-forward of the concept would be that nameservers ought to be geographically and topologically diverse so as to avoid fate-sharing. Different upstreams, different coasts (maybe different continents?), different covering prefixes, and certainly not on the same IPv4 /32... would be the intelligent thing to do particularly if one wants to query nanog@ about operational hinkiness and not be on the receiving end of derisive chuckles. > Not on a host that does anything else? > > Both of those actually make some sense to me, the first from a single > point of failure consideration, the second regarding unrelated > failures (I have to re-boot my windows PC at least once a day, most > days because Firefox, the way I use it, gets itself tangled about that > often and a reboot is the quickest way to clear it). Can't hurt to have authoritative nameservers on dedicated VMs (enterprise guys running AD have my sympathies), but that's not what we're talking about here. -r From bmanning at vacation.karoshi.com Mon Mar 10 20:49:26 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 10 Mar 2014 13:49:26 -0700 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <86y50hevb1.fsf@valhalla.seastrom.com> References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> <86k3c7cw5w.fsf@valhalla.seastrom.com> <20140307100409.GA26837@vacation.karoshi.com> <531A4D50.1070601@cox.net> <86y50hevb1.fsf@valhalla.seastrom.com> Message-ID: <20140310204926.GA13077@vacation.karoshi.com> RFC 2182.... On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote: > > Larry Sheldon writes: > > > On 3/7/2014 5:03 AM, Rob Seastrom wrote: > > > >> for decades. i have a vague recollection of an rfc that said > >> secondary nameservers ought not be connected to the same psn (remember > >> those?) but my google fu fails me this early in the morning. > > > > Packet Switch Node? > > > > Not sure what would be in this context. > > > > Not on the same router? How about two routers away with both THEM on > > the same router (a third one)? > > A PSN or IMP was an ARPANET/MILNET "core" router. Some sites had more > than one. A reasonable carry-forward of the concept would be that > nameservers ought to be geographically and topologically diverse so as > to avoid fate-sharing. Different upstreams, different coasts (maybe > different continents?), different covering prefixes, and certainly not > on the same IPv4 /32... would be the intelligent thing to do > particularly if one wants to query nanog@ about operational hinkiness > and not be on the receiving end of derisive chuckles. > > > Not on a host that does anything else? > > > > Both of those actually make some sense to me, the first from a single > > point of failure consideration, the second regarding unrelated > > failures (I have to re-boot my windows PC at least once a day, most > > days because Firefox, the way I use it, gets itself tangled about that > > often and a reboot is the quickest way to clear it). > > Can't hurt to have authoritative nameservers on dedicated VMs > (enterprise guys running AD have my sympathies), but that's not what > we're talking about here. > > -r > From rs at seastrom.com Mon Mar 10 21:29:17 2014 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 10 Mar 2014 17:29:17 -0400 Subject: DNS Resolving issues. So for related just to Cox. But could be larger. In-Reply-To: <20140310204926.GA13077@vacation.karoshi.com> (bmanning@vacation.karoshi.com's message of "Mon, 10 Mar 2014 13:49:26 -0700") References: <5316AAC5.6090109@viviotech.net> <5316BD72.3000703@winterei.se> <8661nsg64l.fsf@valhalla.seastrom.com> <20140306121413.GA20355@vacation.karoshi.com> <53186CEB.60209@foobar.org> <86k3c7cw5w.fsf@valhalla.seastrom.com> <20140307100409.GA26837@vacation.karoshi.com> <531A4D50.1070601@cox.net> <86y50hevb1.fsf@valhalla.seastrom.com> <20140310204926.GA13077@vacation.karoshi.com> Message-ID: <86y50h215e.fsf@valhalla.seastrom.com> Thanks Bill. Clearly my Google-fu was failing because of plugging in anachronistic terms when searching for a document that is only barely old enough to drive. -r bmanning at vacation.karoshi.com writes: > RFC 2182.... > > > > On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote: >> >> Larry Sheldon writes: >> >> > On 3/7/2014 5:03 AM, Rob Seastrom wrote: >> > >> >> for decades. i have a vague recollection of an rfc that said >> >> secondary nameservers ought not be connected to the same psn (remember >> >> those?) but my google fu fails me this early in the morning. >> > >> > Packet Switch Node? >> > >> > Not sure what would be in this context. >> > >> > Not on the same router? How about two routers away with both THEM on >> > the same router (a third one)? >> >> A PSN or IMP was an ARPANET/MILNET "core" router. Some sites had more >> than one. A reasonable carry-forward of the concept would be that >> nameservers ought to be geographically and topologically diverse so as >> to avoid fate-sharing. Different upstreams, different coasts (maybe >> different continents?), different covering prefixes, and certainly not >> on the same IPv4 /32... would be the intelligent thing to do >> particularly if one wants to query nanog@ about operational hinkiness >> and not be on the receiving end of derisive chuckles. >> >> > Not on a host that does anything else? >> > >> > Both of those actually make some sense to me, the first from a single >> > point of failure consideration, the second regarding unrelated >> > failures (I have to re-boot my windows PC at least once a day, most >> > days because Firefox, the way I use it, gets itself tangled about that >> > often and a reboot is the quickest way to clear it). >> >> Can't hurt to have authoritative nameservers on dedicated VMs >> (enterprise guys running AD have my sympathies), but that's not what >> we're talking about here. >> >> -r >> From herro91 at gmail.com Mon Mar 10 21:34:41 2014 From: herro91 at gmail.com (Herro91) Date: Mon, 10 Mar 2014 17:34:41 -0400 Subject: OAM/CFM question on IOS-XR Message-ID: > Hi, > > I've been working on a basic configuration for E-OAM starting with one > domain. I have CFM working between the PEs (IOS-XR) devices tied to an > EoMPLS instance, but have a few questions below: > > 1) I "think" I should be seeing MIPs in my traceroute when there is a P > router in between the two PEs, correct? > > 2) If the P router in between these PEs is just a transit node, what > configuration is required to create the MIPs? I have seen the MIP > autocreate all, but it seems to be tied to a service configuration under > CFM which would not apply in the case of a transit/P router. > > > Thanks! > From herro91 at gmail.com Mon Mar 10 21:40:44 2014 From: herro91 at gmail.com (Herro91) Date: Mon, 10 Mar 2014 17:40:44 -0400 Subject: Seeking config for QinQ/802.1ad on Brocade MLX Message-ID: Hello All, I am trying to find an example config on how to configure QinQ/802.1ad/PB on the Brocade MLX8 platform. I have found some basic examples for PBB/Mac in Mac, but not a complete config for 802.1ad Can anyone on the list help? Thanks! From mikeal.clark at gmail.com Mon Mar 10 22:19:28 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Mon, 10 Mar 2014 17:19:28 -0500 Subject: XO/TWC problems? Message-ID: I'm seeing packet loss between XO and TWC. 206.111.2.89 seems to be the problem. Anyone else seeing similar? From greg at thesmythes.org Mon Mar 10 23:59:08 2014 From: greg at thesmythes.org (Greg Smythe) Date: Mon, 10 Mar 2014 23:59:08 +0000 Subject: XO/TWC problems? In-Reply-To: References: Message-ID: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> I'm seeing a problem between that IP and another XO router at 207.88.14.193 -=-=-=-=-=-=-=-=-=-=--=-=- Greg Smythe -----Original Message----- From: Mikeal Clark [mailto:mikeal.clark at gmail.com] Sent: Monday, March 10, 2014 6:19 PM To: NANOG [nanog at nanog.org] Subject: XO/TWC problems? I'm seeing packet loss between XO and TWC. 206.111.2.89 seems to be the problem. Anyone else seeing similar? From mikeal.clark at gmail.com Tue Mar 11 00:27:23 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Mon, 10 Mar 2014 19:27:23 -0500 Subject: XO/TWC problems? In-Reply-To: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> References: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> Message-ID: Glad someone else is seeing it. TWC wasn't much help. Not sure how to follow up on this but I have 3 sites that can't stay online because of it. On Mon, Mar 10, 2014 at 6:59 PM, Greg Smythe wrote: > I'm seeing a problem between that IP and another XO router at > 207.88.14.193 > > > > -=-=-=-=-=-=-=-=-=-=--=-=- > Greg Smythe > > > > -----Original Message----- > From: Mikeal Clark [mailto:mikeal.clark at gmail.com] > Sent: Monday, March 10, 2014 6:19 PM > To: NANOG [nanog at nanog.org] > Subject: XO/TWC problems? > > I'm seeing packet loss between XO and TWC. > > 206.111.2.89 seems to be the problem. Anyone else seeing similar? > From mikeal.clark at gmail.com Tue Mar 11 02:42:16 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Mon, 10 Mar 2014 21:42:16 -0500 Subject: XO/TWC problems? In-Reply-To: References: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> Message-ID: No one from XO monitors the list? We have a cpl people from AT&T networks reporting the same issues now. On Mon, Mar 10, 2014 at 7:27 PM, Mikeal Clark wrote: > Glad someone else is seeing it. TWC wasn't much help. Not sure how to > follow up on this but I have 3 sites that can't stay online because of it. > > > On Mon, Mar 10, 2014 at 6:59 PM, Greg Smythe wrote: > >> I'm seeing a problem between that IP and another XO router at >> 207.88.14.193 >> >> >> >> -=-=-=-=-=-=-=-=-=-=--=-=- >> Greg Smythe >> >> >> >> -----Original Message----- >> From: Mikeal Clark [mailto:mikeal.clark at gmail.com] >> Sent: Monday, March 10, 2014 6:19 PM >> To: NANOG [nanog at nanog.org] >> Subject: XO/TWC problems? >> >> I'm seeing packet loss between XO and TWC. >> >> 206.111.2.89 seems to be the problem. Anyone else seeing similar? >> > > From sh.vahabzadeh at gmail.com Tue Mar 11 06:26:26 2014 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Tue, 11 Mar 2014 09:56:26 +0330 Subject: MTU Problem on Cisco 7606 Message-ID: Hi everybody, I have change my core router from 7206 VXR to 7606 with RSP720 since last 1 month. I had GRE Tunnel in 7206 with one of my regions with this config: interface Tunnel1 > ip mtu 1500 > ip policy route-map clear-df I have copy this config to new 7606 with the same config but now I have Problem with page load. For example yahoo.com totally does not work. I change Tunnel interface config to: interface Tunnel1 > ip tcp adjust-mss 1360 > tunnel mode ipip But again does not make difference, for example yahoo.com solve but put another site in trouble. I must notice that my region side router is 7206 VXR and we have not change that router, It is the same as before was. The question is what is different between 7600 and 7200 in MTU? I change "*system jumbomtu*" to *1526* on 7606 but it does not make any difference. Would you please help me in this field? Thanks IOS on 7606: c7600rsp72043-adventerprisek9-mz.152-4.S4a.bin IOS on 7206: > c7200p-adventerprisek9-mz.124-24.T.bin -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From universe at truemetal.org Tue Mar 11 07:00:26 2014 From: universe at truemetal.org (Markus) Date: Tue, 11 Mar 2014 08:00:26 +0100 Subject: How to catch a cracker in the US? Message-ID: <531EB48A.3020609@truemetal.org> Hi, I'm an ISP in Germany and a cracker (not a hacker :) ) has targeted a customers of mine in the last days. The cracker was successful and caused financial damage / was successful with data theft. I set a trap and finally caught his real IP address - a Comcast user in the US (100% not a proxy or bot). What would be the next steps to pursuit him? If I contact local authorities here in Germany I'm afraid months will pass by and Comcast will have possible already deleted their logs by then (?). Any advice? Thank you! Markus From rdobbins at arbor.net Tue Mar 11 07:06:23 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 11 Mar 2014 07:06:23 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <531EB48A.3020609@truemetal.org> References: <531EB48A.3020609@truemetal.org> Message-ID: <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> On Mar 11, 2014, at 2:00 PM, Markus wrote: > Any advice? Start with CERT-BUND, maybe? Although it's questionable whether or not it's possible to remotely absolutely ascertain whether the attacking machine in question was being operated by miscreants unbeknownst to its actual owner. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From adam.vitkovsky at swan.sk Tue Mar 11 12:57:41 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Tue, 11 Mar 2014 12:57:41 +0000 Subject: [c-nsp] OAM/CFM question on IOS-XR In-Reply-To: References: Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011CF7A2@EX01.swan.local> Hi, > Herro91 > Sent: Wednesday, March 05, 2014 6:19 PM > 1) I "think" I should be seeing MIPs in my traceroute when there is a P router > in between the two PEs, correct? It is a L2 form of traceroute so it will record only L2 hops configured as MIPs or MEPs. So in a p2p PW there are going to be only PW endpoints as MEPs for a particular Level. > 2) If the P router in between these PEs is just a transit node, what > configuration is required to create the MIPs? See CFM is meant for L2 OAM where there are no interface ip addresses you can ping to or capture in a traceroute. So in case of an e.g. me3400 connected to your XR box than p2p PW to another XR box than another me3400 as CPE. These four boxes form the L2 domain over which you can utilize CFM to pin-point the failure. You could have the me3400 as MEPs and XR boxes as MIPs for the particular level. This gets handy as the L2 (aggregation) domain at each end of the MPLS cloud gets bigger and it's more difficult to see which L2 box dropped the ball. Regarding the MPLS core in between, well you already have tools to identify the failed P/core box. adam > -----Original Message----- > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of > Herro91 > Sent: Wednesday, March 05, 2014 6:19 PM > To: Cisco-nsp; nanog at nanog.org > Subject: [c-nsp] OAM/CFM question on IOS-XR > > Hi, > > I've been working on a basic configuration for E-OAM starting with one > domain. I have CFM working between the PEs (IOS-XR) devices tied to an > EoMPLS instance, but have a few questions below: > > 1) I "think" I should be seeing MIPs in my traceroute when there is a P router > in between the two PEs, correct? > > 2) If the P router in between these PEs is just a transit node, what > configuration is required to create the MIPs? I have seen the MIP autocreate > all, but it seems to be tied to a service configuration under CFM which would > not apply in the case of a transit/P router. > > > Thanks! > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From mikeal.clark at gmail.com Tue Mar 11 17:56:14 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Tue, 11 Mar 2014 12:56:14 -0500 Subject: XO/TWC problems? In-Reply-To: References: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> Message-ID: This problem seemed resolved for awhile and now its representing with about 7% packet loss. Looks like someone adjusted the routing a bit at XO. On Mon, Mar 10, 2014 at 9:42 PM, Mikeal Clark wrote: > No one from XO monitors the list? We have a cpl people from AT&T networks > reporting the same issues now. > > > On Mon, Mar 10, 2014 at 7:27 PM, Mikeal Clark wrote: > >> Glad someone else is seeing it. TWC wasn't much help. Not sure how to >> follow up on this but I have 3 sites that can't stay online because of it. >> >> >> On Mon, Mar 10, 2014 at 6:59 PM, Greg Smythe wrote: >> >>> I'm seeing a problem between that IP and another XO router at >>> 207.88.14.193 >>> >>> >>> >>> -=-=-=-=-=-=-=-=-=-=--=-=- >>> Greg Smythe >>> >>> >>> >>> -----Original Message----- >>> From: Mikeal Clark [mailto:mikeal.clark at gmail.com] >>> Sent: Monday, March 10, 2014 6:19 PM >>> To: NANOG [nanog at nanog.org] >>> Subject: XO/TWC problems? >>> >>> I'm seeing packet loss between XO and TWC. >>> >>> 206.111.2.89 seems to be the problem. Anyone else seeing similar? >>> >> >> > From jmceachin at gmail.com Tue Mar 11 18:04:24 2014 From: jmceachin at gmail.com (Jmac) Date: Tue, 11 Mar 2014 14:04:24 -0400 Subject: Novartis and Qwest AS209 In-Reply-To: References: Message-ID: Thanks Chris. That is what I assumed as well. Some automatic route object registration went awry. Was hoping someone from Qwest/CenturyLink would jump in and fix it as many of the GEOIP databases automated tools use descr field. No further comment required. It was just peeving me a bit so figured I would send something out on it. -jason On 3/6/14, 5:05 AM, "Christopher Morrow" wrote: >guessing that 209 registered some objects on behalf of novartis/customer? >novartis isn't qwest who's now centurylink anyway. > >On Wed, Mar 5, 2014 at 2:02 PM, Jmac wrote: >> All, I haven?t posted something to Nanog in probably 10 years so >>forgive my >> ignorance on protocol. I am sure this has been posted about but while I >> figure out how to search the archives?. >> >> I see Ripe DB, Maxmind and many others have AS209 associated with the >> company Novartis. Did I miss something because ARIN whois shows it >> different. If this is wrong, it seems the source of the error is >> db.ripe.net. >> >> aut-num: AS209 >> >>>ut- >> num> >> as-name: ASN-QWEST-US >> descr: NOVARTIS-DMZ-US >> admin-c: NOVN1-RIPE >> >>>ype >> =PERSON> >> tech-c: NOVN2-RIPE >> >>>ype >> =PERSON> >> mnt-by: NOVARTIS-MNT >> >>>&ty >> pe=MNTNER> >> source: RIPE # Filtered >> >> Thanks >> Jason >> >> From nick at flhsi.com Tue Mar 11 20:05:41 2014 From: nick at flhsi.com (Nick Olsen) Date: Tue, 11 Mar 2014 16:05:41 -0400 Subject: Google Apps/Mail Contact Message-ID: <401f2e59$7cf0ec1f$3bfee062$@flhsi.com> Anyone from Google Apps for education, Specifically the Mail side of the house listening? Having a hell of a time with normal support channels on an SMTP issue. Unicast Welcome. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From ops.lists at gmail.com Tue Mar 11 23:40:17 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 12 Mar 2014 05:10:17 +0530 Subject: Google Apps/Mail Contact In-Reply-To: <401f2e59$7cf0ec1f$3bfee062$@flhsi.com> References: <401f2e59$7cf0ec1f$3bfee062$@flhsi.com> Message-ID: Highly automated systems that won't let up blocking till whatever part of your mail stream to them is considered spam doesn't stop. Could be cracked accounts, spamming customers, malware, users with .forwards to their gmail so all their inbound spam is forwarded as well .. On Wednesday, March 12, 2014, Nick Olsen wrote: > Anyone from Google Apps for education, Specifically the Mail side of the > house listening? > > Having a hell of a time with normal support channels on an SMTP issue. > > Unicast Welcome. > > Thanks! > > Nick Olsen > Network Operations (855) FLSPEED x106 > > > > -- --srs (iPad) From edwardroels at gmail.com Wed Mar 12 00:38:41 2014 From: edwardroels at gmail.com (Edward Roels) Date: Tue, 11 Mar 2014 20:38:41 -0400 Subject: XO/TWC problems? In-Reply-To: References: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> Message-ID: As seen from Cogent to XO. http://i.imgur.com/aFyAw1p.png On Tue, Mar 11, 2014 at 1:56 PM, Mikeal Clark wrote: > This problem seemed resolved for awhile and now its representing with about > 7% packet loss. > > Looks like someone adjusted the routing a bit at XO. > > > On Mon, Mar 10, 2014 at 9:42 PM, Mikeal Clark >wrote: > > > No one from XO monitors the list? We have a cpl people from AT&T > networks > > reporting the same issues now. > > > > > > On Mon, Mar 10, 2014 at 7:27 PM, Mikeal Clark >wrote: > > > >> Glad someone else is seeing it. TWC wasn't much help. Not sure how to > >> follow up on this but I have 3 sites that can't stay online because of > it. > >> > >> > >> On Mon, Mar 10, 2014 at 6:59 PM, Greg Smythe > wrote: > >> > >>> I'm seeing a problem between that IP and another XO router at > >>> 207.88.14.193 > >>> > >>> > >>> > >>> -=-=-=-=-=-=-=-=-=-=--=-=- > >>> Greg Smythe > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Mikeal Clark [mailto:mikeal.clark at gmail.com] > >>> Sent: Monday, March 10, 2014 6:19 PM > >>> To: NANOG [nanog at nanog.org] > >>> Subject: XO/TWC problems? > >>> > >>> I'm seeing packet loss between XO and TWC. > >>> > >>> 206.111.2.89 seems to be the problem. Anyone else seeing similar? > >>> > >> > >> > > > From adam.vitkovsky at swan.sk Wed Mar 12 10:10:27 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Wed, 12 Mar 2014 10:10:27 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Tuesday, March 11, 2014 8:06 AM > Although it's questionable whether or not it's possible to remotely absolutely > ascertain whether the attacking machine in question was being operated by > miscreants unbeknownst to its actual owner. Though it's 100% correct would this withstand in the court? e.g. nope wasn't me downloading that movie, must have been a hacker misusing my PC, I didn't even know there's a "torrent client" as you guys call it installed on my PC I only use it to play solitaire. From rdobbins at arbor.net Wed Mar 12 10:41:32 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 12 Mar 2014 10:41:32 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> Message-ID: <91756162-41E4-47C7-9ABD-2932B86E1783@arbor.net> On Mar 12, 2014, at 5:10 PM, Vitkovsk? Adam wrote: > Though it's 100% correct would this withstand in the court? TIINAL - The Internet Is Not A Lawyer. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mikeal.clark at gmail.com Wed Mar 12 13:50:22 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Wed, 12 Mar 2014 08:50:22 -0500 Subject: XO/TWC problems? In-Reply-To: References: <6A855EC9802B4E4EADDBBC6D7CA6ABB439D765@tiger.house.local> Message-ID: Problem looks worse this morning. Seeing about 15% packet loss now. On Tue, Mar 11, 2014 at 7:38 PM, Edward Roels wrote: > As seen from Cogent to XO. > > http://i.imgur.com/aFyAw1p.png > > > On Tue, Mar 11, 2014 at 1:56 PM, Mikeal Clark >wrote: > > > This problem seemed resolved for awhile and now its representing with > about > > 7% packet loss. > > > > Looks like someone adjusted the routing a bit at XO. > > > > > > On Mon, Mar 10, 2014 at 9:42 PM, Mikeal Clark > >wrote: > > > > > No one from XO monitors the list? We have a cpl people from AT&T > > networks > > > reporting the same issues now. > > > > > > > > > On Mon, Mar 10, 2014 at 7:27 PM, Mikeal Clark > >wrote: > > > > > >> Glad someone else is seeing it. TWC wasn't much help. Not sure how > to > > >> follow up on this but I have 3 sites that can't stay online because of > > it. > > >> > > >> > > >> On Mon, Mar 10, 2014 at 6:59 PM, Greg Smythe > > wrote: > > >> > > >>> I'm seeing a problem between that IP and another XO router at > > >>> 207.88.14.193 > > >>> > > >>> > > >>> > > >>> -=-=-=-=-=-=-=-=-=-=--=-=- > > >>> Greg Smythe > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Mikeal Clark [mailto:mikeal.clark at gmail.com] > > >>> Sent: Monday, March 10, 2014 6:19 PM > > >>> To: NANOG [nanog at nanog.org] > > >>> Subject: XO/TWC problems? > > >>> > > >>> I'm seeing packet loss between XO and TWC. > > >>> > > >>> 206.111.2.89 seems to be the problem. Anyone else seeing similar? > > >>> > > >> > > >> > > > > > > From bill at herrin.us Wed Mar 12 13:56:49 2014 From: bill at herrin.us (William Herrin) Date: Wed, 12 Mar 2014 09:56:49 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <531EB48A.3020609@truemetal.org> References: <531EB48A.3020609@truemetal.org> Message-ID: On Tue, Mar 11, 2014 at 3:00 AM, Markus wrote: > I'm an ISP in Germany and a cracker (not a hacker :) ) has targeted a > customers of mine in the last days. The cracker was successful and caused > financial damage / was successful with data theft. I set a trap and finally > caught his real IP address - a Comcast user in the US (100% not a proxy or > bot). What would be the next steps to pursuit him? If I contact local > authorities here in Germany I'm afraid months will pass by and Comcast will > have possible already deleted their logs by then (?). Any advice? Hi Markus, A couple of suggestions: 1. Ask Comcast to preserve the records associated with the IP addresses and timeframe in which the problem occurred. They can't give them to you absent a valid US subpoena but they can save them from automatic deletion while you work on that. 2. Be specific about the problem. Be liberal with the shared details! Comcast can be your partner in this endeavor. If you treat them as your enemy by being cagey, they may behave as your enemy by doing the minimum required by law. Which turns out to be not much. 3. Once you have done these things, then go to the police. Share information about your specific contact with Comcast with the police and share your specific police contact with Comcast. This will start them talking, which is half the battle in getting the police to investigate a computer crime. Who knows, U.S. authorities may already be investigating the same user which would make your job so much easier. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From LarrySheldon at cox.net Wed Mar 12 16:07:38 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 12 Mar 2014 11:07:38 -0500 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> Message-ID: <5320864A.1010309@cox.net> On 3/12/2014 5:41 AM, Dobbins, Roland wrote: > TIINAL - The Internet Is Not A Lawyer. NANOGINTI There ARE rules in the environment, however. For example, there is one that I am too lazy to look-up that argues for the use of a .sig separator "-- ". > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From wbailey at satelliteintelligencegroup.com Wed Mar 12 16:16:13 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 12 Mar 2014 16:16:13 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <5320864A.1010309@cox.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> ,<5320864A.1010309@cox.net> Message-ID: I heard cheese works really well for catching crackers. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Larry Sheldon Date: 03/12/2014 9:08 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: How to catch a cracker in the US? On 3/12/2014 5:41 AM, Dobbins, Roland wrote: > TIINAL - The Internet Is Not A Lawyer. NANOGINTI There ARE rules in the environment, however. For example, there is one that I am too lazy to look-up that argues for the use of a .sig separator "-- ". > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From oscar.vives at gmail.com Wed Mar 12 16:36:08 2014 From: oscar.vives at gmail.com (Tei) Date: Wed, 12 Mar 2014 17:36:08 +0100 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> Message-ID: On 12 March 2014 14:56, William Herrin wrote: >.. Who knows, U.S. authorities may already > be investigating the same user which would make your job so much > easier. > Also, if you just want a deterrent. Having a cop visit the home of the cracker just making questions may send the message "we know where you live, so calm the fuck up". -- -- ?in del ?ensaje. From trelane at trelane.net Wed Mar 12 16:37:55 2014 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 12 Mar 2014 12:37:55 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> , <5320864A.1010309@cox.net> Message-ID: <53208D63.2090303@trelane.net> Hi, I found that finding them on IRC, or wherever it is that they congregate, and simply talking to them until they incriminate themselves tends to work best. I also found that firewalls, IDS, security audits, antivirus, antimalware etc work almost not at all. The reason for this is pretty simple. Cybercrime is not a technical problem and does not have a technical solution. The solution is just like any other criminal act, find them, get them to confess, and then put a real world face and location to the IRC persona. Easy. Andrew On 3/12/2014 12:16 PM, Warren Bailey wrote: > I heard cheese works really well for catching crackers. > > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: Larry Sheldon > Date: 03/12/2014 9:08 AM (GMT-08:00) > To: nanog at nanog.org > Subject: Re: How to catch a cracker in the US? > > > On 3/12/2014 5:41 AM, Dobbins, Roland wrote: > >> TIINAL - The Internet Is Not A Lawyer. > NANOGINTI > > There ARE rules in the environment, however. For example, there is one > that I am too lazy to look-up that argues for the use of a .sig > separator "-- ". > >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Luck is the residue of opportunity and design. >> >> -- John Milton >> >> >> > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From Joshua_Sholes at cable.comcast.com Wed Mar 12 16:58:41 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Wed, 12 Mar 2014 16:58:41 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <53208D63.2090303@trelane.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <53208D63.2090303@trelane.net> Message-ID: Ha! ?Easy?, in my personal experience (having once upon a time caught a hacker in .ro, but it took six months of work to seal the deal with handcuffs). -- Josh Sholes On 3/12/14, 12:37 PM, "Andrew D Kirch" wrote: >Hi, > >I found that finding them on IRC, or wherever it is that they >congregate, and simply talking to them until they incriminate themselves >tends to work best. I also found that firewalls, IDS, security audits, >antivirus, antimalware etc work almost not at all. The reason for this >is pretty simple. Cybercrime is not a technical problem and does not >have a technical solution. The solution is just like any other criminal >act, find them, get them to confess, and then put a real world face and >location to the IRC persona. Easy. > >Andrew > > >On 3/12/2014 12:16 PM, Warren Bailey wrote: >> I heard cheese works really well for catching crackers. >> >> >> Sent from my T-Mobile 4G LTE Device >> >> >> >> -------- Original message -------- >> From: Larry Sheldon >> Date: 03/12/2014 9:08 AM (GMT-08:00) >> To: nanog at nanog.org >> Subject: Re: How to catch a cracker in the US? >> >> >> On 3/12/2014 5:41 AM, Dobbins, Roland wrote: >> >>> TIINAL - The Internet Is Not A Lawyer. >> NANOGINTI >> >> There ARE rules in the environment, however. For example, there is one >> that I am too lazy to look-up that argues for the use of a .sig >> separator "-- ". >> >>> ----------------------------------------------------------------------- >>> Roland Dobbins // >>> >>> Luck is the residue of opportunity and design. >>> >>> -- John Milton >>> >>> >>> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen >>Pinker) >> > > From eugen at leitl.org Wed Mar 12 17:14:53 2014 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 12 Mar 2014 18:14:53 +0100 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> Message-ID: <20140312171453.GD26986@leitl.org> On Wed, Mar 12, 2014 at 04:16:13PM +0000, Warren Bailey wrote: > I heard cheese works really well for catching crackers. That's racist. From wbailey at satelliteintelligencegroup.com Wed Mar 12 17:21:13 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 12 Mar 2014 17:21:13 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <20140312171453.GD26986@leitl.org> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: Since when do crackers have a stated ethnicity? Isn?t racism based on race, and not flour content in a baked snack? LOL We accept crackers of all types here.. Flour, rice, wheat, grain, etc. On 3/12/14, 10:14 AM, "Eugen Leitl" wrote: >On Wed, Mar 12, 2014 at 04:16:13PM +0000, Warren Bailey wrote: > >> I heard cheese works really well for catching crackers. > >That's racist. > From bill at herrin.us Wed Mar 12 17:56:46 2014 From: bill at herrin.us (William Herrin) Date: Wed, 12 Mar 2014 13:56:46 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: On Wed, Mar 12, 2014 at 1:21 PM, Warren Bailey wrote: > Since when do crackers have a stated ethnicity? Isn?t racism based on > race, and not flour content in a baked snack? LOL http://en.wikipedia.org/wiki/Cracker_%28pejorative%29 -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wbailey at satelliteintelligencegroup.com Wed Mar 12 18:01:57 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 12 Mar 2014 18:01:57 +0000 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: Being caucasian myself, I am inherently aware of the terminology ?cracker". How a joke relating to catching crackers with ?cheese? was translated into a racial slur is completely beyond my comprehension. In my country, we eat cheese with crackers .. So it would be safe to assume the entirety of my comment was related to molded milk fat and baked grain. ;) On 3/12/14, 10:56 AM, "William Herrin" wrote: >On Wed, Mar 12, 2014 at 1:21 PM, Warren Bailey > wrote: >> Since when do crackers have a stated ethnicity? Isn?t racism based on >> race, and not flour content in a baked snack? LOL > >http://en.wikipedia.org/wiki/Cracker_%28pejorative%29 > > > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 From swm at emanon.com Wed Mar 12 18:05:32 2014 From: swm at emanon.com (Scott Morris) Date: Wed, 12 Mar 2014 14:05:32 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: And if they were the intended application of the term, I would think that ?cheese? would not the the appropriate choice to catch them. However, cheese and crackers would seem to be more a snack, which is at least how >I< interpreted that original comment. Perhaps I need to drink more? Scott -----Original Message----- From: William Herrin Date: Wednesday, March 12, 2014 at 1:56 PM To: Warren Bailey Cc: "nanog at nanog.org" Subject: Re: How to catch a cracker in the US? >On Wed, Mar 12, 2014 at 1:21 PM, Warren Bailey > wrote: >> Since when do crackers have a stated ethnicity? Isn?t racism based on >> race, and not flour content in a baked snack? LOL > >http://en.wikipedia.org/wiki/Cracker_%28pejorative%29 > > > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 > From bzs at world.std.com Wed Mar 12 18:29:33 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 12 Mar 2014 14:29:33 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> Message-ID: <21280.42893.223559.443397@world.std.com> There's an almost, I don't know the right word, jealous reaction to someone asking for help like this sometimes where people speculate on the legal success etc generally concluding failure. There are many good reasons to try to track a criminal. For one thing, often this is not their only criminal activity so plausibly denying this one activity may not help them in the end. But not if everyone throws up their hands and focuses only on the difficulties! Also, if they stole money or identity information and used it then there should be a trail of that activity. If I steal your credit card and it got used and it got used by the person you suspect stole it for other reasons (e.g., a phishing site was running at their IP) then that's a pretty good hint beyond just proving the one fact (it was their IP.) On the one hand this is not a great forum for getting this advice because of this sort of thing, people who have little to offer in advice start speculating on legalities etc. OTOH, it is likely that people on this list have had first-hand experience with this sort of thing and can usefully recommend what the OP might do next. I've had good and not so great experiences, but it's changed over the years. I've seen real creeps tracked aggressively in real time with warrants flying. I've also had LEO shout at me that they have only very limited resources which sounded like "if they rob a congressman call us, otherwise call your congressman and get us more budget first!" -- -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 mis at seiden.com Wed Mar 12 18:38:39 2014 From: mis at seiden.com (Mark Seiden) Date: Wed, 12 Mar 2014 14:38:39 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> Message-ID: On Mar 12, 2014, at 9:56 AM, William Herrin wrote: > On Tue, Mar 11, 2014 at 3:00 AM, Markus wrote: >> I'm an ISP in Germany and a cracker (not a hacker :) ) has targeted a >> customers of mine in the last days. The cracker was successful and caused >> financial damage / was successful with data theft. I set a trap and finally >> caught his real IP address - a Comcast user in the US (100% not a proxy or >> bot). What would be the next steps to pursuit him? If I contact local >> authorities here in Germany I'm afraid months will pass by and Comcast will >> have possible already deleted their logs by then (?). Any advice? > > Hi Markus, > > A couple of suggestions: > > 1. Ask Comcast to preserve the records associated with the IP > addresses and timeframe in which the problem occurred. They can't give > them to you absent a valid US subpoena but they can save them from > automatic deletion while you work on that. > > 2. Be specific about the problem. Be liberal with the shared details! > Comcast can be your partner in this endeavor. If you treat them as > your enemy by being cagey, they may behave as your enemy by doing the > minimum required by law. Which turns out to be not much. > > 3. Once you have done these things, then go to the police. Share > information about your specific contact with Comcast with the police > and share your specific police contact with Comcast. This will start > them talking, which is half the battle in getting the police to > investigate a computer crime. Who knows, U.S. authorities may already > be investigating the same user which would make your job so much > easier. how long ago did this happen? they preserve subscriber information forever, and dhcp logs for quite a long time. the police = your local federal police. there is an mlat between .de and .us which means the us police has to cooperate and pursue german cases and vice versa. yes, it takes longer. there is also a hotline system where the .de police can request records preservation by US entities with the promise that an mlat request is forthcoming. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Wed Mar 12 19:48:07 2014 From: bill at herrin.us (William Herrin) Date: Wed, 12 Mar 2014 15:48:07 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: On Wed, Mar 12, 2014 at 2:01 PM, Warren Bailey wrote: > Being caucasian myself, I am inherently aware of the terminology > "cracker". How a joke relating to catching crackers with "cheese" was > translated into a racial slur is completely beyond my comprehension. Hi Warren, Were you not aware that in the U.S., every statement you could possibly make as well as no statement at all is racist, sexist or in some other way impugns anyone wishing to take offense? The retort, "That's racist!" is made tongue in cheek. Similar to Freud's phallic symbols, it's offered in response to the use of any word or phrase which has the slightest connection in any context to racism. Which is most of them. If I said, "The snow is falling, covering the dirty city in a layer of pristine white," it would be perfectly normal for someone to jokingly return, "That's racist!" By describing the *city* as *dirty* and then changed not just to *white* but *pristine* white I practically begged for it. When someone says something that actually is racist, we have a whole different vocabulary for expressing disgust. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wbailey at satelliteintelligencegroup.com Wed Mar 12 19:50:25 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 12 Mar 2014 19:50:25 +0000 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: So like.. Nerds have a sense of humor all the sudden?? Did I miss a slashdot post or something? ;) (and I used nerd lovingly..) On 3/12/14, 12:48 PM, "William Herrin" wrote: >On Wed, Mar 12, 2014 at 2:01 PM, Warren Bailey > wrote: >> Being caucasian myself, I am inherently aware of the terminology >> "cracker". How a joke relating to catching crackers with "cheese" was >> translated into a racial slur is completely beyond my comprehension. > >Hi Warren, > >Were you not aware that in the U.S., every statement you could >possibly make as well as no statement at all is racist, sexist or in >some other way impugns anyone wishing to take offense? > >The retort, "That's racist!" is made tongue in cheek. Similar to >Freud's phallic symbols, it's offered in response to the use of any >word or phrase which has the slightest connection in any context to >racism. Which is most of them. > >If I said, "The snow is falling, covering the dirty city in a layer of >pristine white," it would be perfectly normal for someone to jokingly >return, "That's racist!" By describing the *city* as *dirty* and then >changed not just to *white* but *pristine* white I practically begged >for it. > >When someone says something that actually is racist, we have a whole >different vocabulary for expressing disgust. > >Regards, >Bill Herrin > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 From Joshua_Sholes at cable.comcast.com Wed Mar 12 19:56:23 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Wed, 12 Mar 2014 19:56:23 +0000 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: On 3/12/14, 2:05 PM, "Scott Morris" wrote: >Perhaps I need to drink more? If you?re on this list, that?s practically a given regardless of circumstances. ?Josh From bill at herrin.us Wed Mar 12 19:57:09 2014 From: bill at herrin.us (William Herrin) Date: Wed, 12 Mar 2014 15:57:09 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: On Wed, Mar 12, 2014 at 3:50 PM, Warren Bailey wrote: > So like.. Nerds have a sense of humor all the sudden?? Did I miss a > slashdot post or something? Geeks, man. Geeks. Nerds have pocket protectors. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alexander at neilson.net.nz Wed Mar 12 20:06:25 2014 From: alexander at neilson.net.nz (Alexander Neilson) Date: Thu, 13 Mar 2014 09:06:25 +1300 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011CFA22@EX01.swan.local> <5320864A.1010309@cox.net> <20140312171453.GD26986@leitl.org> Message-ID: <6EF5D228-1C1D-4CFE-A2BE-59A937893D5B@neilson.net.nz> I just thought it was Nerds didn't have social lives (not likely to be drinking) They fail the blood alcohol test on sign up to the list here. Regards Alexander Alexander Neilson Neilson Productions Ltd Alexander at Neilson.net.nz 021 329 681 > On 13/03/2014, at 8:57 am, William Herrin wrote: > > On Wed, Mar 12, 2014 at 3:50 PM, Warren Bailey > wrote: >> So like.. Nerds have a sense of humor all the sudden?? Did I miss a >> slashdot post or something? > > Geeks, man. Geeks. Nerds have pocket protectors. > > -Bill > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6151 bytes Desc: not available URL: From ag4ve.us at gmail.com Thu Mar 13 04:35:12 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 13 Mar 2014 00:35:12 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: On Mar 11, 2014 3:09 AM, "Dobbins, Roland" wrote: > > > On Mar 11, 2014, at 2:00 PM, Markus wrote: > > > Any advice? > > Start with CERT-BUND, maybe? > That is the correct answer, if you want something less settle (and possibly illegal), there were discussions on 'hacking back'. That is, basically having malicious documents with fake (or not) bank/personal information. If you can find who is using the info (some Comcast business IPs have the address in whois) and go OSINT from there (though if you go this route, try to contact LE before you post something and burn bridges). A note on terminology - whether you know what you're doing, actually break into a system, or obtain a thumb drive with data that you weren't supposed to have - it has the same end so I'd refer to it by the same term - hacking. Trying to differentiate terms based on skill, target, or data type is kinda dumb. From mysidia at gmail.com Thu Mar 13 05:52:19 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 13 Mar 2014 00:52:19 -0500 Subject: How to catch a cracker in the US? In-Reply-To: <531EB48A.3020609@truemetal.org> References: <531EB48A.3020609@truemetal.org> Message-ID: On Tue, Mar 11, 2014 at 2:00 AM, Markus wrote: > Hi, > Your goal should be to keep together and preserve all the evidence/documentation you have: make sure you have and can verify the authenticity and chain of custody for all relevant materials that you say evidence attacks and their source, including your "trap" and how that works, and how it proves the apparent source/origin, contact the local authorities. By the way, without surveillance of the source network, it is really quite impossible to 100% prove that a given IP address is not running a bot and not being used as a proxy or traffic relay. This does not necessarily preclude contacting Comcast as well, to request they preserve records. > > I'm an ISP in Germany and a cracker (not a hacker :) ) has targeted a > customers of mine in the last days. The cracker was successful and caused > financial damage / was successful with data theft. I set a trap and finally > caught his real IP address - a Comcast user in the US (100% not a proxy or > bot). What would be the next steps to pursuit him? If I contact local > authorities here in Germany I'm afraid months will pass by and Comcast will > have possible already deleted their logs by then (?). Any advice? > > Thank you! > Markus > > -- -JH From me at anuragbhatia.com Thu Mar 13 07:35:23 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 13 Mar 2014 13:05:23 +0530 Subject: DNS resolver reaction to non-reachable authoritative DNS server Message-ID: Hello there! I am trying to troubleshoot a case of DNS failure issue with one of Indian Govt's domain (nic.in). I can see that 1 out of 4 authoritative DNS server is IPv6 only. We have quite a few users running IPv4 only setup and hence 1/4 of these DNS servers are non-reachable from the recursor hosted by our clients. How is DNS query expected to respond in such case? Will it give SRVFAIL and terminate immediately (causing DNS resolution failure) OR it will just see one of the auth DNS as non-reachable and next will proceed with either of other three thus slowing down but with no failure? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From Joshua_Sholes at cable.comcast.com Thu Mar 13 13:22:40 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Thu, 13 Mar 2014 13:22:40 +0000 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: On 3/13/14, 12:35 AM, "shawn wilson" wrote: >A note on terminology - whether you know what you're doing, actually break >into a system, or obtain a thumb drive with data that you weren't supposed >to have - it has the same end so I'd refer to it by the same term - >hacking. Trying to differentiate terms based on skill, target, or data >type >is kinda dumb. If one came up in this field with a mentor who was old school, or if one is old school oneself, one tends use the original (as I understand it) definitions--a "cracker" breaks security or obtains data unlawfully, a "hacker" is someone who likes ethically playing (in the "joyful exploration" sense) with complicated systems. People who are culturally younger tend use "hacker", as you are doing, for the former and as far as I can tell no specific term for the latter. If you ask me, this is something of a cultural loss. --Josh From Valdis.Kletnieks at vt.edu Thu Mar 13 14:13:52 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 13 Mar 2014 10:13:52 -0400 Subject: How to catch a cracker in the US? In-Reply-To: Your message of "Thu, 13 Mar 2014 13:22:40 -0000." References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: <93200.1394720032@turing-police.cc.vt.edu> On Thu, 13 Mar 2014 13:22:40 -0000, "Sholes, Joshua" said: > If one came up in this field with a mentor who was old school, or if one > is old school oneself, one tends use the original (as I understand it) > definitions--a "cracker" breaks security or obtains data unlawfully, a > "hacker" is someone who likes ethically playing (in the "joyful > exploration" sense) with complicated systems. For the old-schoolers, a "cracker" would violate the CFAA to get into a system. A hacker would produce a long list of ways to get in without violating the CFAA. Unfortunately, we no longer have a well-established word for the latter class of people. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bill at herrin.us Thu Mar 13 15:08:31 2014 From: bill at herrin.us (William Herrin) Date: Thu, 13 Mar 2014 11:08:31 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <93200.1394720032@turing-police.cc.vt.edu> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> Message-ID: On Thu, Mar 13, 2014 at 10:13 AM, wrote: > On Thu, 13 Mar 2014 13:22:40 -0000, "Sholes, Joshua" said: > >> If one came up in this field with a mentor who was old school, or if one >> is old school oneself, one tends use the original (as I understand it) >> definitions--a "cracker" breaks security or obtains data unlawfully, a >> "hacker" is someone who likes ethically playing (in the "joyful >> exploration" sense) with complicated systems. > > For the old-schoolers, a "cracker" would violate the CFAA to get into a system. > > A hacker would produce a long list of ways to get in without violating the CFAA. > > Unfortunately, we no longer have a well-established word for the latter > class of people. You're all talkin' 1990s redefinitions here. 1980s crackers cracked the copy protections on software (DRM in modern parlance) while hackers broke in to online systems. Even that is a redefinition. Before that, hackers were anyone who jovially pranked a system in a manner typically unlawful which involved creativity and technical challenge. For example, "hackers" might arrange for live cattle to appear on the top of the great dome at MIT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From james.cutler at consultant.com Thu Mar 13 15:45:16 2014 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 13 Mar 2014 11:45:16 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> Message-ID: <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> On Mar 13, 2014, at 11:08 AM, William Herrin wrote: > > On Thu, Mar 13, 2014 at 10:13 AM, wrote: >> On Thu, 13 Mar 2014 13:22:40 -0000, "Sholes, Joshua" said: >> >>> If one came up in this field with a mentor who was old school, or if one >>> is old school oneself, one tends use the original (as I understand it) >>> definitions--a "cracker" breaks security or obtains data unlawfully, a >>> "hacker" is someone who likes ethically playing (in the "joyful >>> exploration" sense) with complicated systems. >> >> For the old-schoolers, a "cracker" would violate the CFAA to get into a system. >> >> A hacker would produce a long list of ways to get in without violating the CFAA. >> >> Unfortunately, we no longer have a well-established word for the latter >> class of people. > > > You're all talkin' 1990s redefinitions here. 1980s crackers cracked > the copy protections on software (DRM in modern parlance) while > hackers broke in to online systems. Even that is a redefinition. > Before that, hackers were anyone who jovially pranked a system in a > manner typically unlawful which involved creativity and technical > challenge. > > For example, "hackers" might arrange for live cattle to appear on the > top of the great dome at MIT. > > Regards, > Bill Herrin And Bill documents yet another redefinition. Prior to that time, at MIT a ?hacker? produced a novel variation of technology using it in ways not previously envisioned but not necessarily unlawful. Mating two different generations of telephone keysets or reducing a complex rack mount filter to a single small circuit board with an FET or two are just a couple of examples. One was just a ?hack?, the other an ?elegant hack?. We just called the moving of the rocket a ?prank?. Cutler -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Thu Mar 13 16:46:06 2014 From: bill at herrin.us (William Herrin) Date: Thu, 13 Mar 2014 12:46:06 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> Message-ID: On Thu, Mar 13, 2014 at 11:45 AM, James R Cutler wrote: > And Bill documents yet another redefinition. Prior to that time, at MIT a "hacker" produced a novel variation of technology using it in ways not previously envisioned but not necessarily unlawful. > > Mating two different generations of telephone keysets or reducing a complex rack mount filter to a single small circuit board with an FET or two are just a couple of examples. One was just a "hack", the other an "elegant hack". We just called Hi James, Correct me if I'm wrong, but by the time "hacker" emerged as a word distinct from "hack" it already carried implications of mischief and disregard for the rules in addition to the original implication of creatively solving a technical challenge. Is that mistaken? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From amitchell at isipp.com Thu Mar 13 17:06:25 2014 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 13 Mar 2014 11:06:25 -0600 Subject: How to catch a cracker in the US? In-Reply-To: References: Message-ID: <32592CBB-0131-4135-88A3-4804672875AF@isipp.com> >> I'm an ISP in Germany and a cracker (not a hacker :) ) has targeted a >> customers of mine in the last days. The cracker was successful and caused >> financial damage / was successful with data theft. I set a trap and finally >> caught his real IP address - a Comcast user in the US (100% not a proxy or >> bot). What would be the next steps to pursuit him? If I contact local >> authorities here in Germany I'm afraid months will pass by and Comcast will >> have possible already deleted their logs by then (?). Any advice? > Marcus, if you have not already connected with them, ping me offlist and I will try to connect you with our FBI cybercrime contact. A preservation letter from them to Comcast, to start, will likely be far more effective than one from you. I'm sorry for not responding sooner; I only just saw this as I'm on digest here. Anne Anne P. Mitchell, Attorney at Law CEO/President Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Author: Section 6 of the Federal CAN-SPAM Act of 2003 From bzs at world.std.com Thu Mar 13 17:23:05 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 13 Mar 2014 13:23:05 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: <21281.59769.748952.888466@world.std.com> Re: hackers vs crackers I was at one of the early "Hackers Conferences" in the late 1980s, organized by Stewart Brand (The Whole Earth Catalog, The Well.) The attendees were quite impressive, not sure why I was invited :-) Todd Rundgren, Jerry Pournelle, Ted Nelson, the founders of a number of now big famous companies who probably would rather I didn't list their names, etc were all just some of the attendees. Although there were a lot of computer and network people they were maybe a bare majority. There were also authors, social innovators, artists, etc. Just "interesting people". The press heard the word "HACKERS" and showed up convinced this was a black hat conference. Nothing would dissuade the reporters and wow people tried. They kept churning out 6PM news reports and articles during the conference about how this was a black hat conference where nefarious no-goodniks had gotten together to create evil plots to (who knows what?) Based on nothing, absolutely nothing. They were even given access to the conference to see what was going on for themselves. All because of the word "hackers" in the conference name. And this was the late 1980s, few of them even knew what a hacker might hack. But it was good press (as in: got eyeballs)! And then of course law enforcement saw the TV spots etc. and showed up to ask some questions and infer some threats. Fortunately not much bad really happened but it was more than a little distracting from the intent of the conference which was just to bring some really bright and creative people together with little structure and let them interact. Hmm, I vaguely rememember someone was in the midst of a criminal case or on parole for something like political activism and was forced to leave (not by the conference, by their parole officer or lawyer or court or some such) because their status forbid "consorting with known criminals" and they were "just asking for trouble". A lot of us vowed to try to keep the "hackers" vs "crackers" distinction alive in the public's mind but I can't say it worked. Having lost that battle I guess the term "Makers" is used today. -- -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 dougb at dougbarton.us Thu Mar 13 17:28:24 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Mar 2014 10:28:24 -0700 Subject: DNS resolver reaction to non-reachable authoritative DNS server In-Reply-To: References: Message-ID: <5321EAB8.3010200@dougbarton.us> On 03/13/2014 12:35 AM, Anurag Bhatia wrote: > Hello there! > > > I am trying to troubleshoot a case of DNS failure issue with one of Indian > Govt's domain (nic.in). I can see that 1 out of 4 authoritative DNS server > is IPv6 only. We have quite a few users running IPv4 only setup and hence > 1/4 of these DNS servers are non-reachable from the recursor hosted by our > clients. > > > How is DNS query expected to respond in such case? Will it give SRVFAIL and > terminate immediately (causing DNS resolution failure) OR it will just see > one of the auth DNS as non-reachable and next will proceed with either of > other three thus slowing down but with no failure? Basically the latter. If your customers are using BIND there is a flag you can supply to named to cause it to operate only in IPv4. That would avoid this problem altogether. hope this helps, Doug From mike-nanog at tiedyenetworks.com Thu Mar 13 18:05:09 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 13 Mar 2014 11:05:09 -0700 Subject: .org dns trouble? Message-ID: <5321F355.3090709@tiedyenetworks.com> Hi, Sorry if there's another list for this, but Im observing a strange problem with a .org domain. Right now when I query dns, I am getting only a SOA for '.org' which looks like this: dig -t ns somedomain.org ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t ns somedomain.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38840 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;somedomain.org. IN NS ;; AUTHORITY SECTION: org. 899 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2010937269 1800 900 604800 86400 ;; Query time: 51 msec ;; SERVER: x.x.x.x#53(y.y.y.y) ;; WHEN: Thu Mar 13 11:00:56 2014 ;; MSG SIZE rcvd: 99 When I do a +trace, I get a list of the authoratative servers for .org but Im manually polled them none of them know the NS for my domain. The domain doesn't expire till next year according to whois, although it does say Creation Date: 2009-06-22T22:56:30Z Updated Date: 2014-03-12T15:33:33Z Registry Expiry Date: 2015-06-22T22:56:30Z The registered nameservers for it are correct. Wondering if anyone else has a clue? The registrar is tucows... Mike- From Valdis.Kletnieks at vt.edu Thu Mar 13 18:09:34 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 13 Mar 2014 14:09:34 -0400 Subject: How to catch a cracker in the US? In-Reply-To: Your message of "Thu, 13 Mar 2014 12:46:06 -0400." References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> Message-ID: <6582.1394734174@turing-police.cc.vt.edu> On Thu, 13 Mar 2014 12:46:06 -0400, William Herrin said: > Correct me if I'm wrong, but by the time "hacker" emerged as a word > distinct from "hack" it already carried implications of mischief and > disregard for the rules in addition to the original implication of > creatively solving a technical challenge. Is that mistaken? To the contrary - there was a period of time when "hacker" included those who were responsible for creative hacks that followed the rules *as they actually were*, not as they were generally believed to be. "It had the virtue of never having been tried before". James T Kirk was (will be?e?) an old-school hacker of epic level. (Contemplate for a bit why Kirk wasn't bounced out on his butt from the Academy) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Mar 13 18:13:26 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Mar 2014 14:13:26 -0400 Subject: .org dns trouble? In-Reply-To: <5321F355.3090709@tiedyenetworks.com> References: <5321F355.3090709@tiedyenetworks.com> Message-ID: time travel, they haz it. On Thu, Mar 13, 2014 at 2:05 PM, Mike wrote: > Hi, > > Sorry if there's another list for this, but Im observing a strange problem > with a .org domain. Right now when I query dns, I am getting only a SOA for > '.org' which looks like this: > > > > dig -t ns somedomain.org > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t ns somedomain.org > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38840 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;somedomain.org. IN NS > > ;; AUTHORITY SECTION: > org. 899 IN SOA a0.org.afilias-nst.info. > noc.afilias-nst.info. 2010937269 1800 900 604800 86400 > > ;; Query time: 51 msec > ;; SERVER: x.x.x.x#53(y.y.y.y) > ;; WHEN: Thu Mar 13 11:00:56 2014 > ;; MSG SIZE rcvd: 99 > > > > When I do a +trace, I get a list of the authoratative servers for .org but > Im manually polled them none of them know the NS for my domain. > > The domain doesn't expire till next year according to whois, although it > does say > > Creation Date: 2009-06-22T22:56:30Z > Updated Date: 2014-03-12T15:33:33Z > Registry Expiry Date: 2015-06-22T22:56:30Z > > > The registered nameservers for it are correct. Wondering if anyone else has > a clue? The registrar is tucows... > > Mike- > From matt at conundrum.com Thu Mar 13 18:46:53 2014 From: matt at conundrum.com (Matthew Pounsett) Date: Thu, 13 Mar 2014 14:46:53 -0400 Subject: .org dns trouble? In-Reply-To: <5321F355.3090709@tiedyenetworks.com> References: <5321F355.3090709@tiedyenetworks.com> Message-ID: <9826D68E-0C82-4891-9099-60B6399E654B@conundrum.com> On Mar 13, 2014, at 14:05 , Mike wrote: > Hi, > > Sorry if there's another list for this, but Im observing a strange problem with a .org domain. Right now when I query dns, I am getting only a SOA for '.org' which looks like this: Your example query is only checking your local recursive server, which could be suffering from any number of problems. The org zone definitely has your domain in it: $ for host in a0 a2 b0 b2 c0 d0; do echo ${host}; dig +norec +noall +authority IN NS somedomain.org @${host}.org.afilias-nst.info; done a0 somedomain.org. 86400 IN NS ns1019.hostgator.com. somedomain.org. 86400 IN NS ns1020.hostgator.com. a2 somedomain.org. 86400 IN NS ns1019.hostgator.com. somedomain.org. 86400 IN NS ns1020.hostgator.com. b0 somedomain.org. 86400 IN NS ns1020.hostgator.com. somedomain.org. 86400 IN NS ns1019.hostgator.com. b2 somedomain.org. 86400 IN NS ns1019.hostgator.com. somedomain.org. 86400 IN NS ns1020.hostgator.com. c0 somedomain.org. 86400 IN NS ns1020.hostgator.com. somedomain.org. 86400 IN NS ns1019.hostgator.com. d0 somedomain.org. 86400 IN NS ns1020.hostgator.com. somedomain.org. 86400 IN NS ns1019.hostgator.com. From Joshua_Sholes at cable.comcast.com Thu Mar 13 18:46:58 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Thu, 13 Mar 2014 18:46:58 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <21281.59769.748952.888466@world.std.com> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <21281.59769.748952.888466@world.std.com> Message-ID: On 3/13/14, 1:23 PM, "Barry Shein" wrote: >A lot of us vowed to try to keep the "hackers" vs "crackers" >distinction alive in the public's mind but I can't say it worked. Yeah, that battle had already been lost by the time I entered the field (even though I tried to fight it for a while anyway.) >Having lost that battle I guess the term "Makers" is used today. I will note that "hackerspace" seems to be somewhat more common parlance than "makerspace" in the circles I operate in as a description of "area where a bunch of people in various disciplines go to create things in a shared environment", so that's some reclamation of what I would consider the original meaning of "hacker". -- Josh From joelja at bogus.com Thu Mar 13 18:50:46 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 13 Mar 2014 11:50:46 -0700 Subject: How to catch a cracker in the US? In-Reply-To: <6582.1394734174@turing-police.cc.vt.edu> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> <6582.1394734174@turing-police.cc.vt.edu> Message-ID: <5321FE06.90706@bogus.com> On 3/13/14, 11:09 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 13 Mar 2014 12:46:06 -0400, William Herrin said: > (Contemplate for a bit why Kirk > wasn't bounced out on his butt from the Academy) Apparently the thinking about hacking was a little more permissive in 1966. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From james.cutler at consultant.com Thu Mar 13 19:15:13 2014 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 13 Mar 2014 15:15:13 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> Message-ID: On Mar 13, 2014, at 12:46 PM, William Herrin wrote: > > On Thu, Mar 13, 2014 at 11:45 AM, James R Cutler > wrote: >> And Bill documents yet another redefinition. Prior to that time, at MIT a "hacker" produced a novel variation of technology using it in ways not previously envisioned but not necessarily unlawful. >> >> Mating two different generations of telephone keysets or reducing a complex rack mount filter to a single small circuit board with an FET or two are just a couple of examples. One was just a "hack", the other an "elegant hack". We just called > > Hi James, > > Correct me if I'm wrong, but by the time "hacker" emerged as a word > distinct from "hack" it already carried implications of mischief and > disregard for the rules in addition to the original implication of > creatively solving a technical challenge. Is that mistaken? > > Regards, > Bill Herrin Bill, Mistaken? Yes. As of early 1960?s - See history of WTBS, Ralph Zaorski, Dick Gruen, Alan Kent, and many others - The then current usage of ?hacker? was simply one who produced a ?hack? - an unusual or unexpected design or configuration or action which either did the same old thing done more simply/elegantly or which did something new or unexpected altogether. Putting an Western Electric power plant on an Automatic Electric step-by-step for the East Campus telephone switch was one of my ?hacks?. James R. Cutler - james.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mike-nanog at tiedyenetworks.com Thu Mar 13 19:16:25 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 13 Mar 2014 12:16:25 -0700 Subject: .org dns trouble? In-Reply-To: <9826D68E-0C82-4891-9099-60B6399E654B@conundrum.com> References: <5321F355.3090709@tiedyenetworks.com> <9826D68E-0C82-4891-9099-60B6399E654B@conundrum.com> Message-ID: <53220409.6040402@tiedyenetworks.com> Problem identified. My domain is on hold... ugh, my eyes are tired, thanks to those who were able to help me (in email). Also my information hiding was a bit weak, I should have used 'example.org' to make it clear I was deleting the real info. Thanks all. Mike- From bill at herrin.us Thu Mar 13 19:24:54 2014 From: bill at herrin.us (William Herrin) Date: Thu, 13 Mar 2014 15:24:54 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> Message-ID: On Thu, Mar 13, 2014 at 3:15 PM, James R Cutler wrote: > As of early 1960's - See history of WTBS, Ralph Zaorski, Dick Gruen, > Alan Kent, and many others - The then current usage of "hacker" was > simply one who produced a "hack" - an unusual or unexpected design > or configuration or action which either did the same old thing done more > simply/elegantly or which did something new or unexpected altogether. Hi James, I'm afraid my google-fu doesn't reach back to the 1960's. You don't happen to have a handy reference do you? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jloiacon at csc.com Thu Mar 13 19:29:14 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 13 Mar 2014 15:29:14 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <6582.1394734174@turing-police.cc.vt.edu> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> <6582.1394734174@turing-police.cc.vt.edu> Message-ID: Another use of 'hacking' has been around in software for awhile ... Newsgroups: comp.lang.perl.misc Subject: Re: Who is Just another Perl hacker? From: merlyn at stonehenge.com (Randal L. Schwartz) Message-ID: >>>>> "Juho" == Juho Cederstrom writes: Juho> But when do I become Just another Perl hacker? Who are they? I've read Juho> the FAQ, but it doesn't answer my question. If I replace my email Juho> signature with JAPH, do I break some kind of law? Juho> Or is Just another Perl Hacker a person who just hacks Perl? Well, this ol' JAPH thing started back in 88-ish when I was posting to a bunch of different newsgroups, and would sign each message somewhat individualized above the "-- " cut. For a while, it was stuff like: Valdis.Kletnieks at vt.edu wrote on 03/13/2014 02:09:34 PM: > To the contrary - there was a period of time when "hacker" included those who > were responsible for creative hacks that followed the rules *as they actually > were*, not as they were generally believed to be. From egon at egon.cc Thu Mar 13 19:30:41 2014 From: egon at egon.cc (James Downs) Date: Thu, 13 Mar 2014 12:30:41 -0700 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> Message-ID: <8EECE935-C544-4770-B355-9F6943BDF32F@egon.cc> On Mar 13, 2014, at 12:24 PM, William Herrin wrote: > I'm afraid my google-fu doesn't reach back to the 1960's. You don't > happen to have a handy reference do you? http://en.wikipedia.org/wiki/Hacker_%28term%29 From matt at conundrum.com Thu Mar 13 19:32:23 2014 From: matt at conundrum.com (Matthew Pounsett) Date: Thu, 13 Mar 2014 15:32:23 -0400 Subject: .org dns trouble? In-Reply-To: <53220409.6040402@tiedyenetworks.com> References: <5321F355.3090709@tiedyenetworks.com> <9826D68E-0C82-4891-9099-60B6399E654B@conundrum.com> <53220409.6040402@tiedyenetworks.com> Message-ID: <1BB9CAB3-E9DA-43DB-844B-F866D68EBC09@conundrum.com> On Mar 13, 2014, at 15:16 , Mike wrote: > Problem identified. My domain is on hold... ugh, my eyes are tired, thanks to those who were able to help me (in email). > Also my information hiding was a bit weak, I should have used 'example.org' to make it clear I was deleting the real info. example.org is real domain too, although that one is held by IANA. % dig +short IN NS example.org a.iana-servers.net. b.iana-servers.net. Anonymizing DNS questions about specific problems, generally speaking, makes it very difficult for anyone to help you effectively. From fergdawgster at mykolab.com Thu Mar 13 19:36:24 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 13 Mar 2014 12:36:24 -0700 Subject: How to catch a cracker in the US? In-Reply-To: <8EECE935-C544-4770-B355-9F6943BDF32F@egon.cc> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> <8EECE935-C544-4770-B355-9F6943BDF32F@egon.cc> Message-ID: <532208B8.40100@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/13/2014 12:30 PM, James Downs wrote: > > On Mar 13, 2014, at 12:24 PM, William Herrin > wrote: > >> I'm afraid my google-fu doesn't reach back to the 1960's. You >> don't happen to have a handy reference do you? > > http://en.wikipedia.org/wiki/Hacker_%28term%29 > > > See also the seminal book by Steven Levy: https://en.wikipedia.org/wiki/Hackers:_Heroes_of_the_Computer_Revolution - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMiCLgACgkQKJasdVTchbIXyQD/dWWRPOhRO+1f7qUTRcHJzxUd IhYnNime7L3jSOP15gAA/2GKBai4KZf8hfSPiPgmGl6te+2QwznZ5Js9KouIpk7l =qLdK -----END PGP SIGNATURE----- From james.cutler at consultant.com Thu Mar 13 19:38:26 2014 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 13 Mar 2014 15:38:26 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> Message-ID: <0ED3F107-F599-4363-BCDA-37EAA719CCB2@consultant.com> On Mar 13, 2014, at 3:24 PM, William Herrin wrote: > > On Thu, Mar 13, 2014 at 3:15 PM, James R Cutler > wrote: >> As of early 1960's - See history of WTBS, Ralph Zaorski, Dick Gruen, >> Alan Kent, and many others - The then current usage of "hacker" was >> simply one who produced a "hack" - an unusual or unexpected design >> or configuration or action which either did the same old thing done more >> simply/elegantly or which did something new or unexpected altogether. > > Hi James, > > I'm afraid my google-fu doesn't reach back to the 1960's. You don't > happen to have a handy reference do you? > > Regards, > Bill Herrin I carry that data in wet storage, interfaced via voice or eyes-on-screen/fingers-on-keyboard. I haven?t been on the MIT campus for more than a few minutes since late 1963. Regarding the Wikipedia entry for ?Hacker?: The TMRC/MITAL history ignores the pioneering audio systems work that came out of WTBS (pre-sale to Ted). Ralph Zaorski and Barry Blesser were the best around at that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cboyd at gizmopartners.com Thu Mar 13 19:42:35 2014 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 13 Mar 2014 14:42:35 -0500 Subject: How to catch a cracker in the US? In-Reply-To: <8EECE935-C544-4770-B355-9F6943BDF32F@egon.cc> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <93200.1394720032@turing-police.cc.vt.edu> <1348B75D-EC47-44E3-87B7-D0A04D5EFA64@consultant.com> <8EECE935-C544-4770-B355-9F6943BDF32F@egon.cc> Message-ID: <8F869F14-B455-499F-A465-1A905331B430@gizmopartners.com> On Mar 13, 2014, at 2:30 PM, James Downs wrote: > > On Mar 13, 2014, at 12:24 PM, William Herrin wrote: > >> I'm afraid my google-fu doesn't reach back to the 1960's. You don't >> happen to have a handy reference do you? > > http://en.wikipedia.org/wiki/Hacker_%28term%29 > http://www.catb.org/jargon/html/H/hacker.html From godomus27 at gmail.com Thu Mar 13 20:27:34 2014 From: godomus27 at gmail.com (Maxime Godonou Dossou) Date: Thu, 13 Mar 2014 16:27:34 -0400 Subject: Dell Power Volt 124T software Message-ID: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> Hello all I just want to know someone here is using Dell Power Volt 124T as tape backup. I just get it but I would like to use Linux redhat 6.3 server as OS on my backup server. Can tell me if you know any open source software I can use to drive it . Sent from IPad From brenno at bsd.com.br Thu Mar 13 21:19:38 2014 From: brenno at bsd.com.br (Brenno Oliveira) Date: Thu, 13 Mar 2014 18:19:38 -0300 Subject: Dell Power Volt 124T software In-Reply-To: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> References: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> Message-ID: Hello, You can use Bacula. this is a CentOS 6 running bacula: # mtx -f /dev/changer inquiry Product Type: Medium Changer Vendor ID: 'DELL ' Product ID: 'PV-124T ' Revision: '0086' Attached Changer API: No # mtx -f /dev/changer status Storage Changer /dev/changer:1 Drives, 8 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Storage Element 1:Full :VolumeTag=000040L2 Storage Element 2:Full :VolumeTag=000009L2 Storage Element 3:Full :VolumeTag=000035L2 Storage Element 4:Full :VolumeTag=000033L2 Storage Element 5:Full :VolumeTag=000043L2 Storage Element 6:Full :VolumeTag=000045L2 Storage Element 7:Full :VolumeTag=000039L2 Storage Element 8:Full :VolumeTag=000041L2 # /opt/bacula/scripts/mtx-changer /dev/changer list 0 /dev/sr0 0 1:000040L2 2:000009L2 3:000035L2 4:000033L2 5:000043L2 6:000045L2 7:000039L2 8:000041L2 2014-03-13 17:27 GMT-03:00 Maxime Godonou Dossou : > Hello all > I just want to know someone here is using Dell Power Volt 124T as tape > backup. > I just get it but I would like to use Linux redhat 6.3 server as OS on my > backup server. > Can tell me if you know any open source software I can use to drive it . > > Sent from IPad From piotr.1234 at interia.pl Thu Mar 13 22:42:36 2014 From: piotr.1234 at interia.pl (Piotr) Date: Thu, 13 Mar 2014 23:42:36 +0100 Subject: open source with flowspec ? In-Reply-To: References: Message-ID: <5322345C.6030708@interia.pl> Hi, There is some open source sflow collector wich can talk via flowspec with juniper routers ? something like snort + nfdump ? I looking something besides Arbor because itis too expensive for me. thanks for help Peter From ml at kenweb.org Thu Mar 13 23:02:54 2014 From: ml at kenweb.org (ML) Date: Thu, 13 Mar 2014 19:02:54 -0400 Subject: open source with flowspec ? In-Reply-To: <5322345C.6030708@interia.pl> References: <5322345C.6030708@interia.pl> Message-ID: <5322391E.9020706@kenweb.org> On 3/13/2014 6:42 PM, Piotr wrote: > Hi, > > There is some open source sflow collector wich can talk via flowspec > with juniper routers ? something like snort + nfdump ? I looking > something besides Arbor because itis too expensive for me. > > thanks for help > Peter > > I believe the goal of ExaDDOS is what you're looking for. https://github.com/Exa-Networks/exaddos From joelja at bogus.com Thu Mar 13 23:13:10 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 13 Mar 2014 16:13:10 -0700 Subject: open source with flowspec ? In-Reply-To: <5322345C.6030708@interia.pl> References: <5322345C.6030708@interia.pl> Message-ID: <53223B86.3070703@bogus.com> exabgp from ripe labs can inject flowspec routes. typically some helper app would generate the policy for exabgp and then exabgp would do the heavy lifting. joel On 3/13/14, 3:42 PM, Piotr wrote: > Hi, > > There is some open source sflow collector wich can talk via flowspec > with juniper routers ? something like snort + nfdump ? I looking > something besides Arbor because itis too expensive for me. > > thanks for help > Peter > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From LarrySheldon at cox.net Thu Mar 13 23:35:00 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 13 Mar 2014 18:35:00 -0500 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: <532240A4.2040108@cox.net> On 3/13/2014 8:22 AM, Sholes, Joshua wrote: > On 3/13/14, 12:35 AM, "shawn wilson" wrote: >> A note on terminology - whether you know what you're doing, actually break >> into a system, or obtain a thumb drive with data that you weren't supposed >> to have - it has the same end so I'd refer to it by the same term - >> hacking. Trying to differentiate terms based on skill, target, or data >> type is kinda dumb. > > If one came up in this field with a mentor who was old school, or if one > is old school oneself, one tends use the original (as I understand it) > definitions--a "cracker" breaks security or obtains data unlawfully, a > "hacker" is someone who likes ethically playing (in the "joyful > exploration" sense) with complicated systems. > > People who are culturally younger tend use "hacker", as you are doing, for > the former and as far as I can tell no specific term for the latter. > > If you ask me, this is something of a cultural loss. Not sure I can agree with that. I have been in this game for a very long time, but for most of it in places where the world's population cleaved neatly into two parts: "Authorized Users" who could be identified by the facts that they had ID cards, Badges, and knew the door code; and "trespassers" who were all others. Then you new kids came along and (pointlessly, in my opinion) divided the later group into the two described above. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From no.spam at comcast.net Thu Mar 13 23:46:32 2014 From: no.spam at comcast.net (Keegan Holley) Date: Thu, 13 Mar 2014 19:46:32 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <531EB48A.3020609@truemetal.org> References: <531EB48A.3020609@truemetal.org> Message-ID: <0CA95B8B-BF6B-41F1-BB48-00F2301F3844@comcast.net> I?ve seen past employers contact the FBI for a similar issue, but we had control of the network and logs in question so that made it easier. You may be able to contact interpol or a similar agency in the EU. They will at least be able to tell you the right agency to call. You can also have a lawyer contact comcast on your behalf. Many times a company will retrieve and store logs in preparation of various legal proceedings. Comcast is a very large company so there?s no way to be sure that this will spur them into action, but it?s a start. On Mar 11, 2014, at 3:00 AM, Markus wrote: > Hi, > > I'm an ISP in Germany and a cracker (not a hacker :) ) has targeted a customers of mine in the last days. The cracker was successful and caused financial damage / was successful with data theft. I set a trap and finally caught his real IP address - a Comcast user in the US (100% not a proxy or bot). What would be the next steps to pursuit him? If I contact local authorities here in Germany I'm afraid months will pass by and Comcast will have possible already deleted their logs by then (?). Any advice? > > Thank you! > Markus > From marka at isc.org Fri Mar 14 00:23:15 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 14 Mar 2014 11:23:15 +1100 Subject: DNS resolver reaction to non-reachable authoritative DNS server In-Reply-To: Your message of "Thu, 13 Mar 2014 10:28:24 -0700." <5321EAB8.3010200@dougbarton.us> References: <5321EAB8.3010200@dougbarton.us> Message-ID: <20140314002315.B75C31162426@rock.dv.isc.org> In message <5321EAB8.3010200 at dougbarton.us>, Doug Barton writes: > On 03/13/2014 12:35 AM, Anurag Bhatia wrote: > > Hello there! > > > > > > I am trying to troubleshoot a case of DNS failure issue with one of Indian > > Govt's domain (nic.in). I can see that 1 out of 4 authoritative DNS server > > is IPv6 only. We have quite a few users running IPv4 only setup and hence > > 1/4 of these DNS servers are non-reachable from the recursor hosted by our > > clients. > > > > > > How is DNS query expected to respond in such case? Will it give SRVFAIL and > > terminate immediately (causing DNS resolution failure) OR it will just see > > one of the auth DNS as non-reachable and next will proceed with either of > > other three thus slowing down but with no failure? > > Basically the latter. > > If your customers are using BIND there is a flag you can supply to named > to cause it to operate only in IPv4. That would avoid this problem > altogether. And is basically not needed as the IP stack (with the exception of Solaris) informs named when there isn't a route to the destination and named moves onto the next address to try. As to the original question. NS records without matching addresses records happen pretty regularly. All nameservers deal with them. Mark > hope this helps, > > Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mike-nanog at tiedyenetworks.com Fri Mar 14 01:11:18 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 13 Mar 2014 18:11:18 -0700 Subject: microsoft / xbox contact Message-ID: <53225736.60000@tiedyenetworks.com> Hi, I can't seem to find a contact for microsoft / xbox security. I have some punks ddos'ing a customer of mine and I'd like to see if those folks from xbox could help us out here. Thank you. Mike From mehmet at akcin.net Fri Mar 14 01:13:31 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 13 Mar 2014 18:13:31 -0700 Subject: microsoft / xbox contact In-Reply-To: <53225736.60000@tiedyenetworks.com> References: <53225736.60000@tiedyenetworks.com> Message-ID: <96902461-55E8-4AFB-BEFD-480B5FD91539@akcin.net> Replied offlist. Mehmet > On Mar 13, 2014, at 18:11, Mike wrote: > > Hi, > > I can't seem to find a contact for microsoft / xbox security. I have some punks ddos'ing a customer of mine and I'd like to see if those folks from xbox could help us out here. > > Thank you. > Mike > From dougb at dougbarton.us Fri Mar 14 01:29:28 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Mar 2014 18:29:28 -0700 Subject: DNS resolver reaction to non-reachable authoritative DNS server In-Reply-To: <20140314002315.B75C31162426@rock.dv.isc.org> References: <5321EAB8.3010200@dougbarton.us> <20140314002315.B75C31162426@rock.dv.isc.org> Message-ID: <53225B78.9010902@dougbarton.us> On 3/13/2014 5:23 PM, Mark Andrews wrote: >> If your customers are using BIND there is a flag you can supply to named >> >to cause it to operate only in IPv4. That would avoid this problem >> >altogether. > > And is basically not needed as the IP stack (with the exception of > Solaris) informs named when there isn't a route to the destination > and named moves onto the next address to try. Sure, but by using the flag you skip that step, and the accompanying error message in the logs. The fact that this issue has risen to the level of "annoyance" rather than just "oddity" as it used to be is actually a good thing. It's a sign that more and more sites are deploying IPv6 for critical infrastructure. Doug From nick.crocker at gmail.com Thu Mar 13 16:32:29 2014 From: nick.crocker at gmail.com (Nick Crocker) Date: Thu, 13 Mar 2014 11:32:29 -0500 Subject: Comcast DIA VoIP degradation Message-ID: Has anyone been seeing voice degradation reports coming in from customers using Comcast DIA? We have several complaints that have came in the last week or so and the commonality is Comcast. Tracing out to the customer sites we are directly peered with L3 which drops the traffic straight into Comcast, we are picking up an additional 20-30ms or so once on Comcast but the latency varies quite a bit once in the Comcast network. Anyone on from Comcast available to talk offline? Regards, Nick From Ray.Sanders at sheknows.com Thu Mar 13 20:55:31 2014 From: Ray.Sanders at sheknows.com (Ray Sanders) Date: Thu, 13 Mar 2014 20:55:31 +0000 Subject: Dell Power Volt 124T software In-Reply-To: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> References: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> Message-ID: <9256086890744f509e8317c2a8461e2c@BN1PR05MB233.namprd05.prod.outlook.com> Not that this is particularly network operations related, but... A quick Google search (https://www.google.com/search?q=Dell+Power+Volt+124T+red+hat+enterprise&oq=Dell+Power+Volt+124T+red+hat+enterprise&aqs=chrome..69i57.6018j0j7&sourceid=chrome&espv=2&es_sm=141&ie=UTF-8) yielded the User's Guide (ftp://ftp.dell.com/Manuals/all-products/esuprt_ser_stor_net/esuprt_powervault/powervault-124t_User's%20Guide12_en-us.pdf) which appears to show how to use the Power Vault 124 with Red Hat Linux. Dell and IBM historically have had decent support for their products with "Enterprise" versions of Red Hat, Ubuntu, and SuSE. RAY SANDERS Senior Systems Engineer ray.sanders at sheknows.com SHEKNOWS ________________________________________ From: Maxime Godonou Dossou Sent: Thursday, March 13, 2014 1:27 PM To: nanog at nanog.org Subject: Dell Power Volt 124T software Hello all I just want to know someone here is using Dell Power Volt 124T as tape backup. I just get it but I would like to use Linux redhat 6.3 server as OS on my backup server. Can tell me if you know any open source software I can use to drive it . Sent from IPad From fledwidge at secureauth.com Thu Mar 13 21:31:13 2014 From: fledwidge at secureauth.com (Feargal Ledwidge) Date: Thu, 13 Mar 2014 14:31:13 -0700 Subject: Dell Power Volt 124T software In-Reply-To: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> References: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> Message-ID: <1fdde7238fd5040706ac544519f132bb@mail.gmail.com> AMANDA (http://amanda.org/) also supports the 124T See here: http://wiki.zmanda.com/index.php/Tapetype_definitions#Dell_PV124T_LTO3 -----Original Message----- From: Maxime Godonou Dossou [mailto:godomus27 at gmail.com] Sent: Thursday, March 13, 2014 1:28 PM To: nanog at nanog.org Subject: Dell Power Volt 124T software Hello all I just want to know someone here is using Dell Power Volt 124T as tape backup. I just get it but I would like to use Linux redhat 6.3 server as OS on my backup server. Can tell me if you know any open source software I can use to drive it . Sent from IPad From mloftis at wgops.com Fri Mar 14 02:16:24 2014 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 13 Mar 2014 19:16:24 -0700 Subject: Dell Power Volt 124T software In-Reply-To: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> References: <19C3F9CC-3132-4197-A92C-B95A267B92E8@gmail.com> Message-ID: Basically anything. It works as a standard SCSI tape changer device using mtx, my, and your favorite archiving software, tar, Amanda, bacula, arkeia, many others. On Thursday, March 13, 2014, Maxime Godonou Dossou wrote: > Hello all > I just want to know someone here is using Dell Power Volt 124T as tape > backup. > I just get it but I would like to use Linux redhat 6.3 server as OS on my > backup server. > Can tell me if you know any open source software I can use to drive it . > > Sent from IPad -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From ag4ve.us at gmail.com Fri Mar 14 04:14:00 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 14 Mar 2014 00:14:00 -0400 Subject: How to catch a cracker in the US? In-Reply-To: <532240A4.2040108@cox.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <532240A4.2040108@cox.net> Message-ID: On Mar 13, 2014 7:37 PM, "Larry Sheldon" wrote: > > On 3/13/2014 8:22 AM, Sholes, Joshua wrote: >> >> On 3/13/14, 12:35 AM, "shawn wilson" wrote: >>> >>> A note on terminology - whether you know what you're doing, actually break >>> into a system, or obtain a thumb drive with data that you weren't supposed >>> to have - it has the same end so I'd refer to it by the same term - >>> hacking. Trying to differentiate terms based on skill, target, or data >>> type is kinda dumb. >> >> >> If one came up in this field with a mentor who was old school, or if one >> is old school oneself, one tends use the original (as I understand it) >> definitions--a "cracker" breaks security or obtains data unlawfully, a >> "hacker" is someone who likes ethically playing (in the "joyful >> exploration" sense) with complicated systems. >> >> People who are culturally younger tend use "hacker", as you are doing, for >> the former and as far as I can tell no specific term for the latter. >> >> If you ask me, this is something of a cultural loss. > > > Not sure I can agree with that. I have been in this game for a very long time, but for most of it in places where the world's population cleaved neatly into two parts: "Authorized Users" who could be identified by the facts that they had ID cards, Badges, and knew the door code; and "trespassers" who were all others. > > Then you new kids came along and (pointlessly, in my opinion) divided the later group into the two described above. > Sorry for my note. Didn't mean it to sidetrack the question (I probably should've). /me o_O From jsimola at gmail.com Fri Mar 14 05:22:08 2014 From: jsimola at gmail.com (Jon Simola) Date: Thu, 13 Mar 2014 22:22:08 -0700 Subject: microsoft / xbox contact In-Reply-To: <53225736.60000@tiedyenetworks.com> References: <53225736.60000@tiedyenetworks.com> Message-ID: I've had the same problem with several customers in the last 6 months. It's always someone playing games on Xbox live. I have one (extremely angry) customer that we've blocked the Xbox live ports on, as somehow within minutes of signing on he'd be the target of a >1 Gbps DDoS. I'd never thought to track down someone at Microsoft about that, so now I feel pretty dumb asking about the same contact info, if anyone would be so kind? On Thu, Mar 13, 2014 at 6:11 PM, Mike wrote: > Hi, > > I can't seem to find a contact for microsoft / xbox security. I have > some punks ddos'ing a customer of mine and I'd like to see if those folks > from xbox could help us out here. > > Thank you. > Mike > > Regards, -- Jon From oscar.vives at gmail.com Fri Mar 14 11:12:00 2014 From: oscar.vives at gmail.com (Tei) Date: Fri, 14 Mar 2014 12:12:00 +0100 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <532240A4.2040108@cox.net> Message-ID: On 14 March 2014 05:14, shawn wilson wrote: > On Mar 13, 2014 7:37 PM, "Larry Sheldon" wrote: .. > > Sorry for my note. Didn't mean it to sidetrack the question (I probably > should've). > > /me o_O Social perception of hacking affect law-making. Computing security is controlled by moral panic and security theater. Maybe someday a young men will enter prision, for "possession of hacking tools"... a compiler and a debugger. Fighting paranoia and moral panic is something we should be doing. Making the distinction hacker vs cracker is like a small effort for this. -- -- ?in del ?ensaje. From rekordmeister at gmail.com Fri Mar 14 13:41:05 2014 From: rekordmeister at gmail.com (MKS) Date: Fri, 14 Mar 2014 13:41:05 +0000 Subject: No subject Message-ID: Hi list I'm looking for a DNS solution to do a parental controls for a small ISP, as in ISP branded services. OpenDNS only supports corporate customers . Please contact me off or on-list, if you have any vendors that you can recommend. Regards MKS From mallman at icir.org Fri Mar 14 13:45:16 2014 From: mallman at icir.org (Mark Allman) Date: Fri, 14 Mar 2014 09:45:16 -0400 Subject: new DNS forwarder vulnerability Message-ID: <20140314134516.BA770396DEA7@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nick at foobar.org Fri Mar 14 13:59:27 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Mar 2014 13:59:27 +0000 Subject: new DNS forwarder vulnerability In-Reply-To: <20140314134516.BA770396DEA7@lawyers.icir.org> References: <20140314134516.BA770396DEA7@lawyers.icir.org> Message-ID: <53230B3F.7050509@foobar.org> On 14/03/2014 13:45, Mark Allman wrote: > - We have found 7--9% of the open resolver population---or 2-3 million > boxes---to be vulnerable to this cache poisoning attack. (The > variance is from different runs of our experiments.) did you characterise what dns servers / embedded kit were vulnerable? If so, can you share the results? Nick From bortzmeyer at nic.fr Fri Mar 14 14:06:57 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 14 Mar 2014 15:06:57 +0100 Subject: new DNS forwarder vulnerability In-Reply-To: <53230B3F.7050509@foobar.org> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> Message-ID: <20140314140656.GA1703@nic.fr> On Fri, Mar 14, 2014 at 01:59:27PM +0000, Nick Hilliard wrote a message of 10 lines which said: > did you characterise what dns servers / embedded kit were > vulnerable? He said "We have not been able to nail this vulnerability down to a single box or manufacturer" so it seems the answer is No. From merike at doubleshotsecurity.com Fri Mar 14 16:05:00 2014 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Fri, 14 Mar 2014 09:05:00 -0700 Subject: new DNS forwarder vulnerability In-Reply-To: <20140314140656.GA1703@nic.fr> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> Message-ID: <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> On Mar 14, 2014, at 7:06 AM, Stephane Bortzmeyer wrote: > On Fri, Mar 14, 2014 at 01:59:27PM +0000, > Nick Hilliard wrote > a message of 10 lines which said: > >> did you characterise what dns servers / embedded kit were >> vulnerable? > > He said "We have not been able to nail this vulnerability down to a > single box or manufacturer" so it seems the answer is No. It is my understanding that many CPEs work off of same reference implementation(s). I haven't had any cycles for this but with all the CPE issues out there it would be interesting to have a matrix of which CPEs utilize which reference implementation. That may start giving some clues. Has someone / is someone doing this? - merike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Fri Mar 14 16:20:52 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Mar 2014 16:20:52 +0000 Subject: new DNS forwarder vulnerability In-Reply-To: <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> Message-ID: <53232C64.9030502@foobar.org> On 14/03/2014 16:05, Merike Kaeo wrote: > Has someone / is someone doing this? someone has, and many CPEs use dnsmasq. current uplink too slow to find references. Nick From Jason_Livingood at cable.comcast.com Fri Mar 14 16:45:20 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 14 Mar 2014 16:45:20 +0000 Subject: new DNS forwarder vulnerability In-Reply-To: <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> Message-ID: Well, at least all this CPE checks in for security updates every night so this should be fixable. Oh wait, no, nevermind, they don't. :-( This is getting to be the vulnerability of the week club for home gateway devices - quite concerning. JL On 3/14/14, 12:05 PM, "Merike Kaeo" wrote: > >On Mar 14, 2014, at 7:06 AM, Stephane Bortzmeyer >wrote: > >> On Fri, Mar 14, 2014 at 01:59:27PM +0000, >> Nick Hilliard wrote >> a message of 10 lines which said: >> >>> did you characterise what dns servers / embedded kit were >>> vulnerable? >> >> He said "We have not been able to nail this vulnerability down to a >> single box or manufacturer" so it seems the answer is No. > > > >It is my understanding that many CPEs work off of same reference >implementation(s). I haven't >had any cycles for this but with all the CPE issues out there it would be >interesting to have >a matrix of which CPEs utilize which reference implementation. That may >start giving some clues. > >Has someone / is someone doing this? > >- merike > From cscora at apnic.net Fri Mar 14 18:07:44 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Mar 2014 04:07:44 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201403141807.s2EI7il0030350@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Mar, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 486892 Prefixes after maximum aggregation: 192121 Deaggregation factor: 2.53 Unique aggregates announced to Internet: 240652 Total ASes present in the Internet Routing Table: 46343 Prefixes per ASN: 10.51 Origin-only ASes present in the Internet Routing Table: 35634 Origin ASes announcing only one prefix: 16400 Transit ASes present in the Internet Routing Table: 6057 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2802 Unregistered ASNs in the Routing Table: 663 Number of 32-bit ASNs allocated by the RIRs: 6109 Number of 32-bit ASNs visible in the Routing Table: 4652 Prefixes from 32-bit ASNs in the Routing Table: 14980 Number of bogon 32-bit ASNs visible in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 440 Number of addresses announced to Internet: 2660005124 Equivalent to 158 /8s, 140 /16s and 117 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.9 Total number of prefixes smaller than registry allocations: 169973 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 115497 Total APNIC prefixes after maximum aggregation: 34586 APNIC Deaggregation factor: 3.34 Prefixes being announced from the APNIC address blocks: 118111 Unique aggregates announced from the APNIC address blocks: 49513 APNIC Region origin ASes present in the Internet Routing Table: 4897 APNIC Prefixes per ASN: 24.12 APNIC Region origin ASes announcing only one prefix: 1228 APNIC Region transit ASes present in the Internet Routing Table: 858 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 869 Number of APNIC addresses announced to Internet: 730595712 Equivalent to 43 /8s, 140 /16s and 1 /24s Percentage of available APNIC address space announced: 85.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 166689 Total ARIN prefixes after maximum aggregation: 82915 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 168137 Unique aggregates announced from the ARIN address blocks: 78297 ARIN Region origin ASes present in the Internet Routing Table: 16185 ARIN Prefixes per ASN: 10.39 ARIN Region origin ASes announcing only one prefix: 6122 ARIN Region transit ASes present in the Internet Routing Table: 1667 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 73 Number of ARIN addresses announced to Internet: 1066989184 Equivalent to 63 /8s, 152 /16s and 246 /24s Percentage of available ARIN address space announced: 56.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, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 122591 Total RIPE prefixes after maximum aggregation: 61950 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 126624 Unique aggregates announced from the RIPE address blocks: 80164 RIPE Region origin ASes present in the Internet Routing Table: 17635 RIPE Prefixes per ASN: 7.18 RIPE Region origin ASes announcing only one prefix: 8297 RIPE Region transit ASes present in the Internet Routing Table: 2867 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2661 Number of RIPE addresses announced to Internet: 657112964 Equivalent to 39 /8s, 42 /16s and 191 /24s Percentage of available RIPE address space announced: 95.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 54888 Total LACNIC prefixes after maximum aggregation: 9988 LACNIC Deaggregation factor: 5.50 Prefixes being announced from the LACNIC address blocks: 60793 Unique aggregates announced from the LACNIC address blocks: 28005 LACNIC Region origin ASes present in the Internet Routing Table: 2073 LACNIC Prefixes per ASN: 29.33 LACNIC Region origin ASes announcing only one prefix: 547 LACNIC Region transit ASes present in the Internet Routing Table: 425 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1036 Number of LACNIC addresses announced to Internet: 153001600 Equivalent to 9 /8s, 30 /16s and 158 /24s Percentage of available LACNIC address space announced: 91.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12134 Total AfriNIC prefixes after maximum aggregation: 2645 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 12787 Unique aggregates announced from the AfriNIC address blocks: 4303 AfriNIC Region origin ASes present in the Internet Routing Table: 708 AfriNIC Prefixes per ASN: 18.06 AfriNIC Region origin ASes announcing only one prefix: 206 AfriNIC Region transit ASes present in the Internet Routing Table: 153 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 13 Number of AfriNIC addresses announced to Internet: 51984640 Equivalent to 3 /8s, 25 /16s and 57 /24s Percentage of available AfriNIC address space announced: 51.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2979 11582 896 Korea Telecom 17974 2761 903 78 PT Telekomunikasi Indonesia 7545 2206 320 117 TPG Telecom Limited 4755 1837 396 197 TATA Communications formerly 9829 1585 1285 40 National Internet Backbone 4808 1337 2204 383 CNCGROUP IP network China169 9583 1307 102 533 Sify Limited 9498 1243 311 76 BHARTI Airtel Ltd. 7552 1239 1082 13 Viettel Corporation 24560 1123 384 176 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3019 3688 53 BellSouth.net Inc. 22773 2416 2938 140 Cox Communications Inc. 1785 2184 693 128 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1693 1673 578 Charter Communications 4323 1620 1089 413 tw telecom holdings, inc. 701 1492 11174 763 MCI Communications Services, 30036 1386 298 555 Mediacom Communications Corp 6983 1328 816 309 ITC^Deltacom 22561 1300 401 228 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1731 544 16 OJSC "Vimpelcom" 34984 1505 264 248 TELLCOM ILETISIM HIZMETLERI A 20940 1304 511 972 Akamai International B.V. 13188 1047 100 34 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 943 370 41 Bezeq International-Ltd 6849 831 361 34 JSC "Ukrtelecom" 6830 762 2329 425 Liberty Global Operations B.V 12479 712 798 51 France Telecom Espana SA 35228 555 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3547 1939 94 NET Servi?os de Comunica??o S 10620 2771 443 202 Telmex Colombia S.A. 18881 1916 972 21 Global Village Telecom 7303 1752 1172 222 Telecom Argentina S.A. 8151 1388 2914 414 Uninet S.A. de C.V. 6503 1043 434 61 Axtel, S.A.B. de C.V. 7738 911 1754 40 Telemar Norte Leste S.A. 11830 866 364 15 Instituto Costarricense de El 27947 854 113 48 Telconet S.A 3816 786 319 128 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1638 240 6 Sudanese Mobile Telephone (ZA 24863 873 376 27 Link Egypt (Link.NET) 6713 603 701 28 Office National des Postes et 8452 529 958 13 TE-AS 24835 299 144 9 Vodafone Data 36992 274 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29571 210 22 17 Cote d'Ivoire Telecom 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3547 1939 94 NET Servi?os de Comunica??o S 6389 3019 3688 53 BellSouth.net Inc. 4766 2979 11582 896 Korea Telecom 10620 2771 443 202 Telmex Colombia S.A. 17974 2761 903 78 PT Telekomunikasi Indonesia 22773 2416 2938 140 Cox Communications Inc. 7545 2206 320 117 TPG Telecom Limited 1785 2184 693 128 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1916 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3019 2966 BellSouth.net Inc. 17974 2761 2683 PT Telekomunikasi Indonesia 10620 2771 2569 Telmex Colombia S.A. 22773 2416 2276 Cox Communications Inc. 7545 2206 2089 TPG Telecom Limited 4766 2979 2083 Korea Telecom 1785 2184 2056 PaeTec Communications, Inc. 18881 1916 1895 Global Village Telecom 18566 2048 1870 MegaPath Corporation 8402 1731 1715 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 30097 UNALLOCATED 8.3.250.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:16 /9:12 /10:30 /11:90 /12:255 /13:477 /14:951 /15:1653 /16:12868 /17:6772 /18:11510 /19:23911 /20:33757 /21:36439 /22:52081 /23:45376 /24:258473 /25:787 /26:937 /27:421 /28:12 /29:18 /30:7 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 6389 1696 3019 BellSouth.net Inc. 22773 1654 2416 Cox Communications Inc. 36998 1599 1638 Sudanese Mobile Telephone (ZA 8402 1417 1731 OJSC "Vimpelcom" 30036 1224 1386 Mediacom Communications Corp 11492 1176 1223 CABLE ONE, INC. 1785 1169 2184 PaeTec Communications, Inc. 6983 1043 1328 ITC^Deltacom 34984 1000 1505 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:991 2:733 3:3 4:16 5:916 6:19 8:660 12:1861 13:4 14:958 15:13 16:3 17:29 18:21 20:35 23:700 24:1728 27:1767 31:1495 32:44 33:2 34:5 36:119 37:1809 38:929 39:4 40:190 41:3177 42:246 44:18 46:2136 47:15 49:671 50:916 52:12 54:47 55:7 57:26 58:1171 59:593 60:380 61:1511 62:1241 63:1994 64:4370 65:2254 66:4237 67:2055 68:1033 69:3297 70:854 71:460 72:1969 74:2664 75:314 76:396 77:1211 78:1045 79:691 80:1303 81:1109 82:671 83:746 84:750 85:1295 86:439 87:1205 88:523 89:1742 90:150 91:5774 92:662 93:1697 94:2055 95:1514 96:538 97:352 98:1099 99:42 100:50 101:804 103:4444 105:552 106:166 107:567 108:551 109:1993 110:996 111:1293 112:628 113:831 114:871 115:1106 116:1041 117:845 118:1348 119:1312 120:362 121:786 122:1909 123:1272 124:1447 125:1452 128:644 129:246 130:352 131:657 132:360 133:159 134:317 135:74 136:268 137:319 138:349 139:159 140:213 141:362 142:558 143:417 144:503 145:106 146:598 147:463 148:791 149:343 150:161 151:578 152:422 153:204 154:100 155:463 156:336 157:367 158:220 159:872 160:354 161:474 162:1237 163:220 164:690 165:622 166:280 167:601 168:1028 169:124 170:1253 171:195 172:20 173:1621 174:679 175:602 176:1477 177:2795 178:1968 179:584 180:1653 181:1013 182:1512 183:506 184:716 185:1394 186:2812 187:1473 188:1876 189:1334 190:7448 191:121 192:7160 193:5456 194:4029 195:3380 196:1352 197:1134 198:4978 199:5590 200:6041 201:2697 202:8957 203:8877 204:4659 205:2665 206:2961 207:2914 208:3963 209:3738 210:3075 211:1682 212:2225 213:2037 214:891 215:84 216:5522 217:1677 218:560 219:321 220:1284 221:592 222:343 223:609 End of report From me at anuragbhatia.com Fri Mar 14 19:58:45 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 15 Mar 2014 01:28:45 +0530 Subject: DNS resolver reaction to non-reachable authoritative DNS server In-Reply-To: <53225B78.9010902@dougbarton.us> References: <5321EAB8.3010200@dougbarton.us> <20140314002315.B75C31162426@rock.dv.isc.org> <53225B78.9010902@dougbarton.us> Message-ID: Got it! Thankyou very much for help. Have a good weekend ahead. On Fri, Mar 14, 2014 at 6:59 AM, Doug Barton wrote: > On 3/13/2014 5:23 PM, Mark Andrews wrote: > >> If your customers are using BIND there is a flag you can supply to named >>> >to cause it to operate only in IPv4. That would avoid this problem >>> >altogether. >>> >> > > >> And is basically not needed as the IP stack (with the exception of >> Solaris) informs named when there isn't a route to the destination >> and named moves onto the next address to try. >> > > Sure, but by using the flag you skip that step, and the accompanying error > message in the logs. > > The fact that this issue has risen to the level of "annoyance" rather than > just "oddity" as it used to be is actually a good thing. It's a sign that > more and more sites are deploying IPv6 for critical infrastructure. > > Doug > > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From ulf at alameda.net Fri Mar 14 20:28:24 2014 From: ulf at alameda.net (Ulf Zimmermann) Date: Fri, 14 Mar 2014 13:28:24 -0700 Subject: Verizon FIOS issues in the Washington DC issue with HTTPS traffic? Message-ID: We have a number of customers in the DC area on Verizon Fios who can talk to us using http, but not https. Linkedin also tweeted there are issues via Verzion Fios. Verizon support so far denies everything. Anyone else seeing issues? -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From morrowc.lists at gmail.com Fri Mar 14 20:46:49 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Mar 2014 16:46:49 -0400 Subject: Verizon FIOS issues in the Washington DC issue with HTTPS traffic? In-Reply-To: References: Message-ID: which site is 'us' in this instance? ie: How would I test this for you? On Fri, Mar 14, 2014 at 4:28 PM, Ulf Zimmermann wrote: > We have a number of customers in the DC area on Verizon Fios who can talk > to us using http, but not https. Linkedin also tweeted there are issues via > Verzion Fios. > > Verizon support so far denies everything. > > Anyone else seeing issues? > > > -- > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 > You can find my resume at: http://www.Alameda.net/~ulf/resume.html From cidr-report at potaroo.net Fri Mar 14 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Mar 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201403142200.s2EM01mk079534@wattle.apnic.net> This report has been generated at Fri Mar 14 21:37:59 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-03-14 492316 277492 08-03-14 492358 277551 09-03-14 492428 277706 10-03-14 492702 277871 11-03-14 492846 277726 12-03-14 492683 277638 13-03-14 493044 278302 14-03-14 493502 278423 AS Summary 46518 Number of ASes in routing system 19038 Number of ASes announcing only one prefix 3562 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A. 119788544 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'). --- 14Mar14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 493956 278399 215557 43.6% All ASes AS28573 3562 588 2974 83.5% NET Servi?os de Comunica??o S.A. AS6389 3019 56 2963 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2761 241 2520 91.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2979 905 2074 69.6% KIXS-AS-KR Korea Telecom AS18881 1916 25 1891 98.7% Global Village Telecom AS1785 2184 361 1823 83.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS36998 1638 99 1539 94.0% SDN-MOBITEL AS18566 2048 565 1483 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2928 1514 1414 48.3% TWTC - tw telecom holdings, inc. AS10620 2771 1442 1329 48.0% Telmex Colombia S.A. AS7303 1752 451 1301 74.3% Telecom Argentina S.A. AS4755 1837 623 1214 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 2209 1077 1132 51.2% TPG-INTERNET-AP TPG Telecom Limited AS22561 1300 237 1063 81.8% AS22561 - CenturyTel Internet Holdings, Inc. AS7552 1231 174 1057 85.9% VIETEL-AS-AP Viettel Corporation AS6983 1328 316 1012 76.2% ITCDELTA - ITC^Deltacom AS22773 2420 1410 1010 41.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS9829 1585 668 917 57.9% BSNL-NIB National Internet Backbone AS4808 1337 424 913 68.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 1123 296 827 73.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4788 997 231 766 76.8% TMNET-AS-AP TM Net, Internet Service Provider AS7738 911 148 763 83.8% Telemar Norte Leste S.A. AS35908 857 97 760 88.7% VPLSNET - Krypt Technologies AS18101 918 163 755 82.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS701 1493 764 729 48.8% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1396 679 717 51.4% Uninet S.A. de C.V. AS855 761 57 704 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6147 785 113 672 85.6% Telefonica del Peru S.A.A. AS4780 1031 366 665 64.5% SEEDNET Digital United Inc. AS11492 1223 567 656 53.6% CABLEONE - CABLE ONE, INC. Total 52300 14657 37643 72.0% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc. 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 103.244.236.0/22 AS58794 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 162.244.140.0/22 AS17246 VOXITYNET - Voxity Telecom, Inc 163.47.22.0/23 AS33688 SUMMITEIS-AS - SummitEIS 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc. 172.85.0.0/24 AS29571 CITelecom-AS 172.85.1.0/24 AS29571 CITelecom-AS 172.85.2.0/24 AS29571 CITelecom-AS 172.85.3.0/24 AS29571 CITelecom-AS 172.86.0.0/24 AS29571 CITelecom-AS 172.86.1.0/24 AS29571 CITelecom-AS 172.86.2.0/24 AS29571 CITelecom-AS 172.87.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company 192.75.23.0/24 AS2579 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc. 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.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc. 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V. 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 192.241.20.0/24 AS7381 SASUSA SunGard Availability Services USA 192.241.21.0/24 AS7381 SASUSA SunGard Availability Services USA 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.19.106.0/23 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd 193.28.14.0/24 AS34309 LINK11 Link11 GmbH 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.33.106.0/23 AS42444 193.33.252.0/23 AS3356 LEVEL3 Level 3 Communications 193.36.229.0/24 AS15404 COLT Technology Services Group Limited 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd 193.84.187.0/24 AS16276 OVH OVH SAS 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS 193.111.229.0/24 AS3356 LEVEL3 Level 3 Communications 193.142.249.0/24 AS12389 ROSTELECOM-AS OJSC Rostelecom 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A. 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.26.0/24 AS16095 JAYNET jay.net a/s 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd. 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd. 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB 194.9.8.0/23 AS2863 SPRITELINK Centor AB 194.9.8.0/24 AS2863 SPRITELINK Centor AB 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd. 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.55.104.0/23 AS7244 ALAMEDANET - Alameda Networks 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.145.136.0/22 AS34820 DANNAX-SK-AS DANNAX spol. s.r.o. 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB 194.156.179.0/24 AS3209 VODANET Vodafone GmbH 194.165.56.0/24 AS16095 JAYNET jay.net a/s 194.176.123.0/24 AS28717 ZENSYSTEMS-AS Zen Systems A/S 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL 195.39.252.0/23 AS29004 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.85.201.0/24 AS3356 LEVEL3 Level 3 Communications 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.178.120.0/23 AS39385 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 196.3.182.0/24 AS37004 196.3.183.0/24 AS37004 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.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS SES WORLD SKIES ARIN AS, for routing RIPE space. 196.45.0.0/21 AS26625 196.45.10.0/24 AS26625 196.216.129.0/24 AS36886 196.216.130.0/24 AS36886 196.216.131.0/24 AS36886 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.72.78.0/23 AS3967 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc. 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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 199.30.138.0/24 AS23319 199.30.139.0/24 AS23319 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC 199.68.72.0/24 AS174 COGENT Cogent/PSI 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc. 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC 199.91.240.0/21 AS174 COGENT Cogent/PSI 199.116.200.0/21 AS22830 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.188.28.0/22 AS46802 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.0.0.0/16 AS7545 TPG-INTERNET-AP TPG Telecom Limited 203.83.16.0/21 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.16.96.0/24 AS19972 204.16.97.0/24 AS19972 204.16.98.0/24 AS19972 204.16.99.0/24 AS19972 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.164.0/22 AS46099 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.203.80.0/20 AS27021 216.203.80.0/21 AS27021 216.203.87.0/24 AS27021 216.203.88.0/21 AS27021 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 14 22:00:03 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Mar 2014 22:00:03 GMT Subject: BGP Update Report Message-ID: <201403142200.s2EM033H079580@wattle.apnic.net> BGP Update Report Interval: 06-Mar-14 -to- 13-Mar-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29571 48376 2.4% 267.3 -- CITelecom-AS 2 - AS10620 36314 1.8% 14.4 -- Telmex Colombia S.A. 3 - AS8402 34000 1.6% 22.1 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 32270 1.6% 36.9 -- BSNL-NIB National Internet Backbone 5 - AS39382 30104 1.5% 15052.0 -- TRANCETELECOM-AS Trance Telecom Inc 6 - AS28573 28211 1.4% 15.0 -- NET Servi?os de Comunica??o S.A. 7 - AS13118 22545 1.1% 805.2 -- ASN-YARTELECOM OJSC Rostelecom 8 - AS25184 22283 1.1% 184.2 -- AFRANET AFRANET Co. Tehran, Iran 9 - AS17974 21353 1.0% 7.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS41691 19792 1.0% 1799.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 11 - AS4775 17846 0.9% 557.7 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS23893 14605 0.7% 374.5 -- BPL-BD House No:03, Road no: 23/A 13 - AS8151 13801 0.7% 18.1 -- Uninet S.A. de C.V. 14 - AS24323 12780 0.6% 206.1 -- AAMRA-NETWORKS-AS-AP aamra networks limited, 15 - AS11976 12383 0.6% 1375.9 -- FIDN - Fidelity Communication International Inc. 16 - AS647 12202 0.6% 111.9 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 17 - AS45899 11239 0.5% 28.7 -- VNPT-AS-VN VNPT Corp 18 - AS6629 10704 0.5% 164.7 -- NOAA-AS - NOAA 19 - AS7552 10632 0.5% 9.6 -- VIETEL-AS-AP Viettel Corporation 20 - AS28024 10010 0.5% 14.6 -- Nuevatel PCS de Bolivia S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS39382 30104 1.5% 15052.0 -- TRANCETELECOM-AS Trance Telecom Inc 2 - AS6459 7806 0.4% 7806.0 -- TRANSBEAM - I-2000, Inc. 3 - AS47033 6544 0.3% 3272.0 -- BASENINE-RIVERSIDE - BaseNine, Inc. 4 - AS54465 8433 0.4% 2811.0 -- QPM-AS-1 - QuickPlay Media Inc. 5 - AS59217 2376 0.1% 2376.0 -- AZONNELIMITED-AS-AP Azonne Limited 6 - AS37367 1866 0.1% 1866.0 -- CALLKEY 7 - AS41691 19792 1.0% 1799.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 8 - AS16561 3019 0.1% 1509.5 -- ARIBANETWORK Ariba Inc. Autonomous System 9 - AS3 1454 0.1% 3297.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology 10 - AS11976 12383 0.6% 1375.9 -- FIDN - Fidelity Communication International Inc. 11 - AS18135 8937 0.4% 1276.7 -- BTV BTV Cable television 12 - AS45924 1092 0.1% 1092.0 -- GLOBAL-AS-AP Global Technologies Limited 13 - AS34912 4326 0.2% 1081.5 -- IFN-AS INTERFUSION INET AS 14 - AS59606 935 0.1% 935.0 -- IT-SVYAZ-SERVICE-AS IT Svyaz Service Ltd. 15 - AS14340 1758 0.1% 879.0 -- SALESFORCE - Salesforce.com, Inc. 16 - AS53041 838 0.0% 838.0 -- Infoclique Telecomunicacoes Ltda Me 17 - AS13118 22545 1.1% 805.2 -- ASN-YARTELECOM OJSC Rostelecom 18 - AS57201 776 0.0% 776.0 -- EDF-AS Estonian Defence Forces 19 - AS62431 722 0.0% 722.0 -- NCSC-IE-AS National Cyber Security Centre 20 - AS20450 1359 0.1% 679.5 -- THL16-ASN - Trojan Hosting, LLC. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22463 1.0% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 89.221.206.0/24 19739 0.9% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 3 - 195.178.105.0/24 15052 0.7% AS39382 -- TRANCETELECOM-AS Trance Telecom Inc 4 - 195.178.104.0/24 15052 0.7% AS39382 -- TRANCETELECOM-AS Trance Telecom Inc 5 - 192.58.232.0/24 10576 0.5% AS6629 -- NOAA-AS - NOAA 6 - 78.109.192.0/20 9911 0.5% AS25184 -- AFRANET AFRANET Co. Tehran, Iran 7 - 216.109.107.0/24 9783 0.4% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 8 - 42.83.48.0/20 8925 0.4% AS18135 -- BTV BTV Cable television 9 - 120.28.62.0/24 8896 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 10 - 222.127.0.0/24 8711 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 11 - 206.152.15.0/24 8421 0.4% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 12 - 205.247.12.0/24 7806 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 13 - 200.23.126.0/24 7658 0.3% AS8151 -- Uninet S.A. de C.V. 14 - 103.11.61.0/24 7634 0.3% AS9387 -- AUGERE-PK AUGERE-Pakistan 15 - 67.210.190.0/23 7333 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 16 - 67.210.188.0/23 5035 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 17 - 121.52.144.0/24 4619 0.2% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 18 - 5.150.145.0/24 4283 0.2% AS34912 -- IFN-AS INTERFUSION INET AS 19 - 199.187.118.0/24 3745 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 20 - 2.93.235.0/24 3434 0.2% AS8402 -- CORBINA-AS OJSC "Vimpelcom" Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From web at typo.org Fri Mar 14 22:06:16 2014 From: web at typo.org (Wayne E Bouchard) Date: Fri, 14 Mar 2014 15:06:16 -0700 Subject: new DNS forwarder vulnerability In-Reply-To: <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> Message-ID: <20140314220616.GA69028@wakko.typo.org> Have we ascertained if there is a typical configuration adjustment that can be made to reduce or eliminate the likelihood of impact? (From the description it sounds as though this is not possible but it doesn't hurt to ask.) On Fri, Mar 14, 2014 at 09:05:00AM -0700, Merike Kaeo wrote: > > On Mar 14, 2014, at 7:06 AM, Stephane Bortzmeyer wrote: > > > On Fri, Mar 14, 2014 at 01:59:27PM +0000, > > Nick Hilliard wrote > > a message of 10 lines which said: > > > >> did you characterise what dns servers / embedded kit were > >> vulnerable? > > > > He said "We have not been able to nail this vulnerability down to a > > single box or manufacturer" so it seems the answer is No. > > > > It is my understanding that many CPEs work off of same reference implementation(s). I haven't > had any cycles for this but with all the CPE issues out there it would be interesting to have > a matrix of which CPEs utilize which reference implementation. That may start giving some clues. > > Has someone / is someone doing this? > > - merike > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From patrick at ianai.net Fri Mar 14 23:42:44 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 14 Mar 2014 23:42:44 +0000 Subject: US to relinquish control of Internet Message-ID: (As if the US has "control" anyway....) It's all over the "popular press", strange I haven't seen it here. Etc., etc. It's nice of the DoC to "relinquish" control, but I really don't see it changing much other than quieting down some hype from countries that were saying they were pissed at the US for "controlling" the Internet. And I couldn't really see those countries doing anything about it unless the US did something actually bad, which they wouldn't do IMHO. Was I being a pollyanna? -- TTFN, patrick From johnl at iecc.com Sat Mar 15 01:19:53 2014 From: johnl at iecc.com (John Levine) Date: 15 Mar 2014 01:19:53 -0000 Subject: US to relinquish control of Internet In-Reply-To: Message-ID: <20140315011953.89073.qmail@joyce.lan> >Was I being a pollyanna? I look forward to the ITU equitably allocating domain names and IP addresses. R's, John From jcurran at arin.net Sat Mar 15 03:02:45 2014 From: jcurran at arin.net (John Curran) Date: Sat, 15 Mar 2014 03:02:45 +0000 Subject: US to relinquish control of Internet In-Reply-To: <20140315011953.89073.qmail@joyce.lan> References: <20140315011953.89073.qmail@joyce.lan> Message-ID: On Mar 14, 2014, at 9:19 PM, John Levine wrote: > > I look forward to the ITU equitably allocating domain names and IP > addresses. While it is not possible to know what will happen in the future, we do have some idea of what _won't_ happen: >From - "NTIA will not accept a proposal that replaces the NTIA role with a government or an inter-governmental organization solution." FYI, /John John Curran President and CEO ARIN From johnl at iecc.com Sat Mar 15 03:13:23 2014 From: johnl at iecc.com (John R. Levine) Date: 14 Mar 2014 23:13:23 -0400 Subject: US to relinquish control of Internet In-Reply-To: References: <20140315011953.89073.qmail@joyce.lan> Message-ID: >> I look forward to the ITU equitably allocating domain names and IP >> addresses. > "NTIA will not accept a proposal that replaces the NTIA role with a > government or an inter-governmental organization solution." Let's hope you're right, but I note that the ITU isn't an inter-governmental organization, it's (depending on which part of their web site you believe) a specialized agency of the United Nations, or an organization based on public-private partnership since its inception, with a membership of 193 countries and over 700 private-sector entities and academic institutions. Sounds totally multistakeholder to me. Unhelpfully, John PS: And the ITU is definitely not a solution. From jcurran at arin.net Sat Mar 15 03:28:36 2014 From: jcurran at arin.net (John Curran) Date: Sat, 15 Mar 2014 03:28:36 +0000 Subject: US to relinquish control of Internet In-Reply-To: References: <20140315011953.89073.qmail@joyce.lan> Message-ID: <6749D622-355F-4557-9703-1CAC17C8BE8E@arin.net> On Mar 14, 2014, at 11:13 PM, John R. Levine wrote: > >> "NTIA will not accept a proposal that replaces the NTIA role with a government or an inter-governmental organization solution." > > Let's hope you're right, but I note that the ITU isn't an inter-governmental organization, it's (depending on which part of their web site you believe) a specialized agency of the United Nations, or an organization based on public-private partnership since its inception, with a membership of 193 countries and over 700 private-sector entities and academic institutions. Sounds totally multistakeholder to me. > > Unhelpfully, > John > > PS: And the ITU is definitely not a solution. Excellent point... given that ITU's (full) Members are governments, I suspect it would be deemed an inter-governmental organization, but in the end it's the NTIA's views on this question that will actually matter. Thanks! /John John Curran President and CEO ARIN From owen at delong.com Sat Mar 15 04:53:11 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Mar 2014 21:53:11 -0700 Subject: US to relinquish control of Internet In-Reply-To: References: <20140315011953.89073.qmail@joyce.lan> Message-ID: <5DF442A3-81AA-4B24-B5FF-6417DF425336@delong.com> On Mar 14, 2014, at 8:13 PM, John R. Levine wrote: >>> I look forward to the ITU equitably allocating domain names and IP >>> addresses. > >> "NTIA will not accept a proposal that replaces the NTIA role with a government or an inter-governmental organization solution." > > Let's hope you're right, but I note that the ITU isn't an inter-governmental organization, it's (depending on which part of their web site you believe) a specialized agency of the United Nations, or an organization based on public-private partnership since its inception, with a membership of 193 countries and over 700 private-sector entities and academic institutions. Sounds totally multistakeholder to me. > The United Nations _IS_ an inter-governmental organization and the ITU would be considered part of the UN in this context, I believe. Owen From springer at inlandnet.com Sat Mar 15 05:37:35 2014 From: springer at inlandnet.com (John Springer) Date: Fri, 14 Mar 2014 22:37:35 -0700 (PDT) Subject: US to relinquish control of Internet In-Reply-To: References: Message-ID: On Fri, 14 Mar 2014, Patrick W. Gilmore wrote: > (As if the US has "control" anyway....) > > It's all over the "popular press", strange I haven't seen it here. > > > > > > > > Etc., etc. > > It's nice of the DoC to "relinquish" control, but I really don't see it changing much other than quieting down some hype from countries that were saying they were pissed at the US for "controlling" the Internet. And I couldn't really see those countries doing anything about it unless the US did something actually bad, which they wouldn't do IMHO. > > Was I being a pollyanna? With respect, I don't think so. John Springer > -- > TTFN, > patrick > > > > From mysidia at gmail.com Sat Mar 15 11:38:11 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 15 Mar 2014 06:38:11 -0500 Subject: new DNS forwarder vulnerability In-Reply-To: <20140314220616.GA69028@wakko.typo.org> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> <20140314220616.GA69028@wakko.typo.org> Message-ID: On Fri, Mar 14, 2014 at 5:06 PM, Wayne E Bouchard wrote: > Have we ascertained if there is a typical configuration adjustment > that can be made to reduce or eliminate the likelihood of impact? > I think your best tactic is: Provide specified DNS resolver cache servers. Don't use CPEs for DNS forwarders. The trouble is.... a CPE's management/locally-bound IP address is in many cases... often the same IP address that is a NAT address shared with user traffic; instead of a dedicated separate IP address that traffic can be managed and security controlled. Providing you ensure that the CPE's IP bound address is not overloaded or shared with user traffic ---- you might try firewalling destination port 53 to the CPE, except from the proper upstream DNS resolvers, since nothing else should be "replying" to a DNS request made by the CPE. Look into whether the CPE can use a different, lesser-used UDP port than 53 to forward DNS requests to; use device firewall rules or upstream ACLs to limit which source IP addresses can talk to the service on the CPE's IP. To ascertain effectiveness for a specific CPE, you would need to run a sample exploit with a before and after test. > (From the description it sounds as though this is not possible but it > doesn't hurt to ask.) > -- -JH From bill at herrin.us Sat Mar 15 13:27:07 2014 From: bill at herrin.us (William Herrin) Date: Sat, 15 Mar 2014 09:27:07 -0400 Subject: Verizon FIOS issues in the Washington DC issue with HTTPS traffic? In-Reply-To: References: Message-ID: On Fri, Mar 14, 2014 at 4:28 PM, Ulf Zimmermann wrote: > We have a number of customers in the DC area on Verizon Fios who can talk > to us using http, but not https. Linkedin also tweeted there are issues via > Verzion Fios. > > Verizon support so far denies everything. > > Anyone else seeing issues? I had major issues with FIOS in the DC area yesterday which cleared after power-cycling the ONT. It wasn't protocol-specific though; all suffered major packet loss. No idea if it's related to your issue but it was proximate in time and location. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gary at baribault.net Sat Mar 15 16:26:02 2014 From: gary at baribault.net (Gary Baribault) Date: Sat, 15 Mar 2014 12:26:02 -0400 Subject: new DNS forwarder vulnerability In-Reply-To: References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> Message-ID: <53247F1A.8020404@baribault.net> Why would a CPE have an open DNS resolver from the WAN side? Gary Baribault On 03/14/2014 12:45 PM, Livingood, Jason wrote: > Well, at least all this CPE checks in for security updates every night so > this should be fixable. Oh wait, no, nevermind, they don't. :-( > > > This is getting to be the vulnerability of the week club for home gateway > devices - quite concerning. > > JL > > On 3/14/14, 12:05 PM, "Merike Kaeo" wrote: > >> On Mar 14, 2014, at 7:06 AM, Stephane Bortzmeyer >> wrote: >> >>> On Fri, Mar 14, 2014 at 01:59:27PM +0000, >>> Nick Hilliard wrote >>> a message of 10 lines which said: >>> >>>> did you characterise what dns servers / embedded kit were >>>> vulnerable? >>> He said "We have not been able to nail this vulnerability down to a >>> single box or manufacturer" so it seems the answer is No. >> >> >> It is my understanding that many CPEs work off of same reference >> implementation(s). I haven't >> had any cycles for this but with all the CPE issues out there it would be >> interesting to have >> a matrix of which CPEs utilize which reference implementation. That may >> start giving some clues. >> >> Has someone / is someone doing this? >> >> - merike >> > > From jgreco at ns.sol.net Sat Mar 15 12:36:34 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 15 Mar 2014 07:36:34 -0500 (CDT) Subject: new DNS forwarder vulnerability In-Reply-To: <53247F1A.8020404@baribault.net> Message-ID: <201403151236.s2FCaZOr088596@aurora.sol.net> > Why would a CPE have an open DNS resolver from the WAN side? Honest to god, are you new to computers or something? People have been writing "just good enough" code since the beginning. A resolver package binds to *:53 by default. Some poor firmware guys with no security experience, deadlines, and too few bytes for code storage don't notice or don't know or don't care and install the resolver feature on the firmware that they're designing, then promptly never think about it again "because that feature works and is therefore done." ... 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 fw at deneb.enyo.de Sat Mar 15 16:34:45 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 15 Mar 2014 17:34:45 +0100 Subject: US to relinquish control of Internet In-Reply-To: (John R. Levine's message of "14 Mar 2014 23:13:23 -0400") References: <20140315011953.89073.qmail@joyce.lan> Message-ID: <87siqjmndm.fsf@mid.deneb.enyo.de> * John R. Levine: > Let's hope you're right, but I note that the ITU isn't an > inter-governmental organization, It was able to obtain a delegation for ITU.INT, so it's inter-governmental enough in DNS terms. From laszlo at heliacal.net Sat Mar 15 16:36:09 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sat, 15 Mar 2014 16:36:09 +0000 Subject: new DNS forwarder vulnerability In-Reply-To: <53247F1A.8020404@baribault.net> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> <53247F1A.8020404@baribault.net> Message-ID: <55FA1F45-4BFF-4917-B7AC-C86495B53E11@heliacal.net> Good question, but the reality is that a lot of them are this way. They just forward everything from any source. Maybe it was designed that way to support DDoS as a use case. Imagine a simple iptables rule like -p udp --dport 53 -j DNAT --to 4.2.2.4 I think some forwarders work this way - the LAN addresses can be reconfigured and so it's probably easier if the rule doesn't check the source address.. or maybe it was designed to work this way on purpose, because it's easy to explain as a 'bug' or oversight, rather than deliberate action. Of course, it's crazy to think that some person or organization deliberately did this so they would have a practically unlimited amount of DoS sources. -Laszlo On Mar 15, 2014, at 4:26 PM, Gary Baribault wrote: > Why would a CPE have an open DNS resolver from the WAN side? > > Gary Baribault > > On 03/14/2014 12:45 PM, Livingood, Jason wrote: >> Well, at least all this CPE checks in for security updates every night so >> this should be fixable. Oh wait, no, nevermind, they don't. :-( >> >> >> This is getting to be the vulnerability of the week club for home gateway >> devices - quite concerning. >> >> JL >> >> On 3/14/14, 12:05 PM, "Merike Kaeo" wrote: >> >>> On Mar 14, 2014, at 7:06 AM, Stephane Bortzmeyer >>> wrote: >>> >>>> On Fri, Mar 14, 2014 at 01:59:27PM +0000, >>>> Nick Hilliard wrote >>>> a message of 10 lines which said: >>>> >>>>> did you characterise what dns servers / embedded kit were >>>>> vulnerable? >>>> He said "We have not been able to nail this vulnerability down to a >>>> single box or manufacturer" so it seems the answer is No. >>> >>> >>> It is my understanding that many CPEs work off of same reference >>> implementation(s). I haven't >>> had any cycles for this but with all the CPE issues out there it would be >>> interesting to have >>> a matrix of which CPEs utilize which reference implementation. That may >>> start giving some clues. >>> >>> Has someone / is someone doing this? >>> >>> - merike >>> >> >> > > From fergdawgster at mykolab.com Sat Mar 15 16:36:20 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sat, 15 Mar 2014 09:36:20 -0700 Subject: new DNS forwarder vulnerability In-Reply-To: <53247F1A.8020404@baribault.net> References: <20140314134516.BA770396DEA7@lawyers.icir.org> <53230B3F.7050509@foobar.org> <20140314140656.GA1703@nic.fr> <022DA097-3756-4B62-8EB1-1F4539F46EE4@doubleshotsecurity.com> <53247F1A.8020404@baribault.net> Message-ID: <53248184.7050404@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 That's a good question, but I know that during the ongoing survey within the Open Resolver Project [http://openresolverproject.org/], Jared found thousands of CPE devices which responded as resolvers. Further work needs to go into fingerprinting these devices to determine the vendor, version, etc., but it is disturbing to see such brokenness. :-/ - - ferg On 3/15/2014 9:26 AM, Gary Baribault wrote: > Why would a CPE have an open DNS resolver from the WAN side? > > Gary Baribault > > On 03/14/2014 12:45 PM, Livingood, Jason wrote: >> Well, at least all this CPE checks in for security updates every >> night so this should be fixable. Oh wait, no, nevermind, they >> don't. :-( >> >> >> This is getting to be the vulnerability of the week club for home >> gateway devices - quite concerning. >> >> JL >> >> On 3/14/14, 12:05 PM, "Merike Kaeo" >> wrote: >> >>> On Mar 14, 2014, at 7:06 AM, Stephane Bortzmeyer >>> wrote: >>> >>>> On Fri, Mar 14, 2014 at 01:59:27PM +0000, Nick Hilliard >>>> wrote a message of 10 lines which said: >>>> >>>>> did you characterise what dns servers / embedded kit were >>>>> vulnerable? >>>> He said "We have not been able to nail this vulnerability >>>> down to a single box or manufacturer" so it seems the answer >>>> is No. >>> >>> >>> It is my understanding that many CPEs work off of same >>> reference implementation(s). I haven't had any cycles for this >>> but with all the CPE issues out there it would be interesting >>> to have a matrix of which CPEs utilize which reference >>> implementation. That may start giving some clues. >>> >>> Has someone / is someone doing this? >>> >>> - merike >>> >> >> > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMkgYQACgkQKJasdVTchbLR1AD9Ey+ISQtaVoJKReLZ6ZzHI7/4 91h+HIQgvazMAne+NMsA/3CCQVw9KG1U6oZdouKexi8ycVw1Y4d4poH+7Yfh4zEh =bFpE -----END PGP SIGNATURE----- From johnl at iecc.com Sat Mar 15 17:17:54 2014 From: johnl at iecc.com (John Levine) Date: 15 Mar 2014 17:17:54 -0000 Subject: US to relinquish control of Internet In-Reply-To: <87siqjmndm.fsf@mid.deneb.enyo.de> Message-ID: <20140315171754.96061.qmail@joyce.lan> >> Let's hope you're right, but I note that the ITU isn't an >> inter-governmental organization, > >It was able to obtain a delegation for ITU.INT, so it's >inter-governmental enough in DNS terms. Yes, it was delegated a month before TPC.INT was. Could you clarify the point you're making? R's, John From bob at FiberInternetCenter.com Sat Mar 15 12:39:18 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 15 Mar 2014 05:39:18 -0700 Subject: US to relinquish control of Internet In-Reply-To: References: Message-ID: > (As if the US has "control" anyway....) > > It's all over the "popular press", strange I haven't seen it here. > > > > > > > > Etc., etc. > > It's nice of the DoC to "relinquish" control, but I really don't see it > changing much other than quieting down some hype from countries that were > saying they were pissed at the US for "controlling" the Internet. And I > couldn't really see those countries doing anything about it unless the US > did something actually bad, which they wouldn't do IMHO. > > Was I being a pollyanna? Yep, way to optimistic. The world always wants the success of capitalism as long as they don't have to create the climate for it, they just want it handed to them. Once they have it they turn it back toward socialism and proceed to F%^$ it up. Gee, sound like the direction our system's been trying to go in for the last 6 years. Bob Evans > > -- > TTFN, > patrick > > From LarrySheldon at cox.net Sat Mar 15 22:07:33 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 15 Mar 2014 17:07:33 -0500 Subject: US to relinquish control of Internet In-Reply-To: References: Message-ID: <5324CF25.6050002@cox.net> On 3/15/2014 7:39 AM, Bob Evans wrote: >> It's nice of the DoC to "relinquish" control, but I really don't see it >> changing much other than quieting down some hype from countries that were >> saying they were pissed at the US for "controlling" the Internet. And I >> couldn't really see those countries doing anything about it unless the US >> did something actually bad, which they wouldn't do IMHO. >> >> Was I being a pollyanna? > > Yep, way to optimistic. The world always wants the success of capitalism > as long as they don't have to create the climate for it, they just want it > handed to them. Once they have it they turn it back toward socialism and > proceed to F%^$ it up. Gee, sound like the direction our system's been > trying to go in for the last 6 years. Or 101 years. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mfidelman at meetinghouse.net Sat Mar 15 22:40:25 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 15 Mar 2014 18:40:25 -0400 Subject: US to relinquish control of Internet In-Reply-To: References: Message-ID: <5324D6D9.6050505@meetinghouse.net> Bob Evans wrote: >> (As if the US has "control" anyway....) >> >> It's all over the "popular press", strange I haven't seen it here. >> >> >> >> >> >> >> >> Etc., etc. >> >> It's nice of the DoC to "relinquish" control, but I really don't see it >> changing much other than quieting down some hype from countries that were >> saying they were pissed at the US for "controlling" the Internet. And I >> couldn't really see those countries doing anything about it unless the US >> did something actually bad, which they wouldn't do IMHO. >> >> Was I being a pollyanna? > Yep, way to optimistic. The world always wants the success of capitalism > as long as they don't have to create the climate for it, they just want it > handed to them. Once they have it they turn it back toward socialism and > proceed to F%^$ it up. Gee, sound like the direction our system's been > trying to go in for the last 6 years. > Not for nothing, but what does capitalism have to do with this? The Internet was a creation of a combination of Government investment (not just US mind you, the ARPANET was not the only early network that ended up merging into the early Internet, there were European networks as well). Today's Internet is a cooperative endeavor that is not "owned" by anyone (the pieces, of course, are); and the governance is mostly a cooperative endeavor (yes ICANN is under contract to the US Government, but primarily operates on its own). Capitalism, if anything, is a negative factor in the mix - as evidenced by the practices of some of the backbone owners and particularly the large cable and telephone companies who own a lot of the network edge (at least in the US, where access costs are higher, and bandwidths are lower, than some far more socialist countries). Now one can argue about under- and over- regulation; and who is to do the regulating (treating US carriers under common carriage regimes would, IMHO, would have positive results. Handing ICANN over to the ITU would create a bureacratic nightmare, for example). But that's a separate issue entirely - and coincidentally, the issue on the table. As to being a pollyanna: I agree, way to optimistic. But not for reasons having to do with communism vs. socialism - but for reasons of a proven system that works vs. handing control over to bureaucrats who might F&^k it up. Personally, I think the caveats that NTIA has attached to "relinquishing control" sound like somebody has got it right - handing ICANN over to, say ISOC might work very well (nobody complains about ISOC control of the IETF). The question is, whether political pressures will lead to a horribly bad decision. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mysidia at gmail.com Sat Mar 15 23:06:54 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 15 Mar 2014 18:06:54 -0500 Subject: US to relinquish control of Internet In-Reply-To: <20140315171754.96061.qmail@joyce.lan> References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> Message-ID: On Sat, Mar 15, 2014 at 12:17 PM, John Levine wrote: > >> Let's hope you're right, but I note that the ITU isn't an > >> inter-governmental organization, > >It was able to obtain a delegation for ITU.INT, so it's > >inter-governmental enough in DNS terms. > Yes, it was delegated a month before TPC.INT was. Could you clarify > the point you're making? > The ITU is an agency of the United Nations. Which is an organization created by treaty, of which various nations' governments are members. How is the ITU _not_ an Inter-governmental organization? If it is not, then what kind of organizations does the NTIA memo say will be excluded? > R's, > John > -- -JH From johnl at iecc.com Sun Mar 16 00:08:47 2014 From: johnl at iecc.com (John R. Levine) Date: 15 Mar 2014 20:08:47 -0400 Subject: US to relinquish control of Internet In-Reply-To: References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> Message-ID: > The ITU is an agency of the United Nations. Which is an organization > created by treaty, of which various nations' governments are members. Actually, the ITU is more than twice as old as the UN, and merged with the UN in 1947. As noted in a previous message, the ITU has both government and non-government members, more of the later than the former, which arguably makes it a multi-stakeholder entity. I entirely believe that NTIA doesn't want the ITU involved with ICANN, but the ITU has made it abundantly clear over the years that it wants a seat at the table, preferably its own table. I listened to the ICANN press conference this morning, the gist of which was don't worry, nothing will change, but once the NTIA opens up the ICANN management contract (or whatever it's called these days) to other parties, keeping the ITU out will be a challenge. R's, John From web at typo.org Sun Mar 16 00:25:03 2014 From: web at typo.org (Wayne E Bouchard) Date: Sat, 15 Mar 2014 17:25:03 -0700 Subject: US to relinquish control of Internet In-Reply-To: References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> Message-ID: <20140316002503.GA73167@wakko.typo.org> On Sat, Mar 15, 2014 at 08:08:47PM -0400, John R. Levine wrote: > >The ITU is an agency of the United Nations. Which is an organization > >created by treaty, of which various nations' governments are members. > > Actually, the ITU is more than twice as old as the UN, and merged with the > UN in 1947. As noted in a previous message, the ITU has both government > and non-government members, more of the later than the former, which > arguably makes it a multi-stakeholder entity. I entirely believe that > NTIA doesn't want the ITU involved with ICANN, but the ITU has made it > abundantly clear over the years that it wants a seat at the table, > preferably its own table. > > I listened to the ICANN press conference this morning, the gist of which > was don't worry, nothing will change, but once the NTIA opens up the ICANN > management contract (or whatever it's called these days) to other parties, > keeping the ITU out will be a challenge. > > R's, > John Yes, the ITU is a very old agreement. It's also been more or less painless to us on the low end of the ladder even though of late they are doing their best to screw it up. Personally, I'm not too terribly worried about ICANN. Granted, the politicians have gotten markedly more efficient at converting gold into sh** in recent years but I think it will take them quite a while to royally fk up the internet, especially if they are relying on going through ICANN to do it. What's the worst they can do at this point? Make .bobtodd and .bubbagump TLDs? This is different from some of the crap we've got now in what way?? -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From johnl at iecc.com Sun Mar 16 01:02:57 2014 From: johnl at iecc.com (John R. Levine) Date: 15 Mar 2014 21:02:57 -0400 Subject: US to relinquish control of Internet In-Reply-To: <20140316002503.GA73167@wakko.typo.org> References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> <20140316002503.GA73167@wakko.typo.org> Message-ID: > What's the worst they can do at this point? Make .bobtodd and > .bubbagump TLDs? This is different from some of the crap we've got now > in what way?? Well, ICANN has come pretty close to delegating .HOME and .CORP to domain speculators, despite the vast amount of informal use which would get badly screwed up. Like I said, I look forward to the ITU equitably delegating domain names and IP addresses. Sorry the US has enough names already, the next ten million go to underserved areas. And since we know that phone numbers work great with per-country prefixes, we're going to improve the DNS so domain names always start with the country code. R's, John From owen at delong.com Sun Mar 16 02:36:27 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Mar 2014 19:36:27 -0700 Subject: US to relinquish control of Internet In-Reply-To: <20140316002503.GA73167@wakko.typo.org> References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> <20140316002503.GA73167@wakko.typo.org> Message-ID: > > What's the worst they can do at this point? Make .bobtodd and > .bubbagump TLDs? This is different from some of the crap we've got now > in what way?? I?m not too worried about what they could do to TLDs? It would be hard to make a bigger mess than ICANN already has. On the other hand, I am very concerned about what they would do to the numbers side of things.. Owen From mfidelman at meetinghouse.net Sun Mar 16 03:01:13 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 15 Mar 2014 23:01:13 -0400 Subject: US to relinquish control of Internet In-Reply-To: References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> <20140316002503.GA73167@wakko.typo.org> Message-ID: <532513F9.4020700@meetinghouse.net> Owen DeLong wrote: >> What's the worst they can do at this point? Make .bobtodd and >> .bubbagump TLDs? This is different from some of the crap we've got now >> in what way?? > I?m not too worried about what they could do to TLDs? It would be hard to make a bigger mess than ICANN already has. > > On the other hand, I am very concerned about what they would do to the numbers side of things.. > > Owen > And try to horn their way into the standards side of things. Can you say X.25? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mysidia at gmail.com Sun Mar 16 05:47:21 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Mar 2014 00:47:21 -0500 Subject: US to relinquish control of Internet In-Reply-To: References: <87siqjmndm.fsf@mid.deneb.enyo.de> <20140315171754.96061.qmail@joyce.lan> <20140316002503.GA73167@wakko.typo.org> Message-ID: On Sat, Mar 15, 2014 at 9:36 PM, Owen DeLong wrote: >On the other hand, I am very concerned about what they would do to the >numbers side of things.. Just keep their grubby paws off the IETF and the internet standards process..... I doubt there's much reason for concern. IPv4 is pretty much already spoken for, and probably even they could not screw up IPv6 allocation. It's not as if they would be free to invent crazy new numbering schemes. I'm not too worried about what they could do to TLDs... It would be hard to > make a bigger mess than ICANN already has. > What comes to mind is scrapping WHOIS due to "privacy concerns", and replacing it with a filing with a private national authority for the TLD, accessible primarily to law enforcement (and not incident responders/operators/infosec/anti-spam people). How TLDs COULD be screwed up worse than ICANN...... introducing "regional TLDs", for coded regions (similar to DVD region locking), and region-locking existing TLDs --- Or certain agreements and fees will be required for an ISP to "subscribe" to a certain TLD, including agreement to pay kickbacks for "Data transfer" and termination fees related to DNS queries and site access, according to rate schedules that the receiving country will be free to set, however exorbitantly they like ---- to the benefit of certain countries desiring to limit access or charge access fees for subscription to out-of-region DNS content; and splitting the root zone, so that domains registered in a certain region cannot be resolved in other regions, > Owen > > > -- -Mysid From me at anuragbhatia.com Sun Mar 16 09:11:30 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 16 Mar 2014 14:41:30 +0530 Subject: Global Vs local node data in www.root-servers.org Message-ID: Hello everyone! It seems like http://www.root-servers.org/index.html has been updated after quite sometime. Seems like data about local Vs global for many of root servers nodes is incorrect. E.g for Netnod i root all nodes are marked as Global nodes. As far as I understand it means that routes announced by these nodes are announced to transit links as well to make routes visible globally. Likely that is not case here right? Same seems with L root and few others. Do we have webmaster of the project on mailing list? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From rz+nng at zwart.com Sun Mar 16 11:45:40 2014 From: rz+nng at zwart.com (Romeo Zwart) Date: Sun, 16 Mar 2014 12:45:40 +0100 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: <53258EE4.3040509@zwart.com> Hi Anurag, On 16 mrt. 2014, at 10:11, Anurag Bhatia > wrote: > Hello everyone! > > > It seems like http://www.root-servers.org/index.html has been updated > after quite sometime. The root-servers.org site has indeed been updated recently. We will investigate if the mentioned data errors are related to the change. > Seems like data about local Vs global for many of root servers nodes > is incorrect. Details of all instances, incl. global vs. local information, are provided directly by individual root-server operators. I will ask the responsible people to verify their instances' details, and if necessary correct these, asap. Kind regards, Romeo > E.g for Netnod i root all nodes are marked as Global nodes. As far as > I understand it means that routes announced by these nodes are > announced to transit links as well to make routes visible globally. > Likely that is not case here right? > > Same seems with L root and few others. Do we have webmaster of the > project on mailing list? > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | Twitter > > Skype: anuragbhatia.com > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From jloiacon at csc.com Sun Mar 16 17:50:01 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Sun, 16 Mar 2014 13:50:01 -0400 Subject: US to relinquish control of Internet In-Reply-To: <5324CF25.6050002@cox.net> References: <5324CF25.6050002@cox.net> Message-ID: Larry Sheldon wrote on 03/15/2014 06:07:33 PM: > From: Larry Sheldon > To: nanog at nanog.org > Date: 03/15/2014 06:09 PM > Subject: Re: US to relinquish control of Internet > > On 3/15/2014 7:39 AM, Bob Evans wrote: > >> Was I being a pollyanna? > > > > Yep, way to optimistic. The world always wants the success of capitalism > > as long as they don't have to create the climate for it, they just want it > > handed to them. Once they have it they turn it back toward socialism and > > proceed to F%^$ it up. Gee, sound like the direction our system's been > > trying to go in for the last 6 years. > > Or 101 years. Exactly! (the fed) From rwebb at ropeguru.com Sun Mar 16 21:38:06 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Sun, 16 Mar 2014 17:38:06 -0400 Subject: ATT Postmaster Contact Message-ID: <532619BE.8030509@ropeguru.com> Anyone have a contact for postmaster at att.net? I have one user on an email list I send to and they are blocking for abuse. This list might get 15 email a month that go out. Filled out their "form" but would like to get this resolved in less than "2 days" as they state. Robert From ops.lists at gmail.com Mon Mar 17 01:54:42 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 17 Mar 2014 07:24:42 +0530 Subject: ATT Postmaster Contact In-Reply-To: <532619BE.8030509@ropeguru.com> References: <532619BE.8030509@ropeguru.com> Message-ID: They will respond usefully to you if you are the admin of that server. If you are on shared hosting, you might ask your provider to contact them. And two days is not an unreasonable time to handle a block issue. On 17-Mar-2014 3:09 am, "Robert Webb" wrote: > Anyone have a contact for postmaster at att.net? I have one user on an > email list I send to and they are blocking for abuse. This list might get > 15 email a month that go out. > > Filled out their "form" but would like to get this resolved in less than > "2 days" as they state. > > Robert > > From rwebb at ropeguru.com Mon Mar 17 02:06:37 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Sun, 16 Mar 2014 22:06:37 -0400 Subject: ATT Postmaster Contact In-Reply-To: References: <532619BE.8030509@ropeguru.com> Message-ID: <532658AD.4040602@ropeguru.com> Thanks. I am the admin of the server. I only have one user of my list that has a bellsouth.net email address. As I stated before, the list might get 15 emails a month sent out. All users are put on the list by request only and only one person has authorization to send out. So there was NO way I was sending any unauthorized email of ANY type in order to get blocked. Robert On 03/16/2014 09:54 PM, Suresh Ramasubramanian wrote: > > They will respond usefully to you if you are the admin of that server. > If you are on shared hosting, you might ask your provider to contact > them. > > And two days is not an unreasonable time to handle a block issue. > > On 17-Mar-2014 3:09 am, "Robert Webb" > wrote: > > Anyone have a contact for postmaster at att.net ? > I have one user on an email list I send to and they are blocking > for abuse. This list might get 15 email a month that go out. > > Filled out their "form" but would like to get this resolved in > less than "2 days" as they state. > > Robert > From jay at west.net Mon Mar 17 03:51:24 2014 From: jay at west.net (Jay Hennigan) Date: Sun, 16 Mar 2014 20:51:24 -0700 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> Message-ID: <5326713C.2060606@west.net> On 3/13/14 6:22 AM, Sholes, Joshua wrote: > If one came up in this field with a mentor who was old school, or if one > is old school oneself, one tends use the original (as I understand it) > definitions--a "cracker" breaks security or obtains data unlawfully, a > "hacker" is someone who likes ethically playing (in the "joyful > exploration" sense) with complicated systems. And both terms are so defined in RFC 1392, dates January 1993. -- 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 dougb at dougbarton.us Mon Mar 17 04:32:42 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Mar 2014 21:32:42 -0700 Subject: How to catch a cracker in the US? In-Reply-To: <5326713C.2060606@west.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <5326713C.2060606@west.net> Message-ID: <53267AEA.4020102@dougbarton.us> On 03/16/2014 08:51 PM, Jay Hennigan wrote: > On 3/13/14 6:22 AM, Sholes, Joshua wrote: > >> If one came up in this field with a mentor who was old school, or if one >> is old school oneself, one tends use the original (as I understand it) >> definitions--a "cracker" breaks security or obtains data unlawfully, a >> "hacker" is someone who likes ethically playing (in the "joyful >> exploration" sense) with complicated systems. > > And both terms are so defined in RFC 1392, dates January 1993. ... but that's only informational. :) From jabley at hopcount.ca Mon Mar 17 14:17:56 2014 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 17 Mar 2014 10:17:56 -0400 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: On 17 Mar 2014, at 7:39, John Bond wrote: > Global and Local nodes are very loosely defined terms. However general > consensus of a local node is one that has a desired routing policy which > does not allow the service supernets to propagate globally. As we impose > no policy we mark all nodes as global. I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt the pertinent text of which is this: Two classes of node are described in this document: Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet. Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area. Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node. Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes. The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"): Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast Address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast Address. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Joshua_Sholes at cable.comcast.com Mon Mar 17 14:21:41 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Mon, 17 Mar 2014 14:21:41 +0000 Subject: How to catch a cracker in the US? In-Reply-To: <532240A4.2040108@cox.net> References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <532240A4.2040108@cox.net> Message-ID: On 3/13/14, 7:35 PM, "Larry Sheldon" wrote: >Not sure I can agree with that. I have been in this game for a very >long time, but for most of it in places where the world's population >cleaved neatly into two parts: "Authorized Users" who could be >identified by the facts that they had ID cards, Badges, and knew the >door code; and "trespassers" who were all others. > >Then you new kids came along and (pointlessly, in my opinion) divided >the later group into the two described above. See, the way *I* learned it was that part of the creed of the "hacker" involved "why would I want to play with your systems, mine are much cooler."; that is, by definition a "hacker" is in the first group. --Josh From bmanning at isi.edu Mon Mar 17 14:27:29 2014 From: bmanning at isi.edu (manning bill) Date: Mon, 17 Mar 2014 07:27:29 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> alas, our service predates Joe?s marvelous text. ?B? provides its services locally to its upstream ISPs. We don?t play routing tricks, impose routing policy, or attempt to influence prefix announcement. /bill Neca eos omnes. Deus suos agnoscet. On 17March2014Monday, at 7:17, Joe Abley wrote: > > On 17 Mar 2014, at 7:39, John Bond wrote: > >> Global and Local nodes are very loosely defined terms. However general >> consensus of a local node is one that has a desired routing policy which >> does not allow the service supernets to propagate globally. As we impose >> no policy we mark all nodes as global. > > I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote > > http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt > > the pertinent text of which is this: > > Two classes of node are described in this document: > > Global Nodes advertise their service supernets such that they are > propagated globally through the routing system (i.e. they > advertise them for transit), and hence potentially provide service > for the entire Internet. > > Local Nodes advertise their service supernets such that the radius of > propagation in the routing system is limited, and hence provide > service for a contained local catchment area. > > Global Nodes provide a baseline degree of proximity to the entire > Internet. Multiple global nodes are deployed to ensure that the > general availability of the service does not rely on the availability > or reachability of a single global node. > > Local Nodes provide contained regions of optimisation. Clients within > the catchment area of a local node may have their queries serviced by > a Local Node, rather than one of the Global Nodes. > > The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). > > We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"): > > Local-Scope Anycast: reachability information for the anycast > Service Address is propagated through a routing system in such a > way that a particular anycast node is only visible to a subset of > the whole routing system. > > Local Node: an Anycast Node providing service using a Local-Scope > Anycast Address. > > Global-Scope Anycast: reachability information for the anycast > Service Address is propagated through a routing system in such a > way that a particular anycast node is potentially visible to the > whole routing system. > > Global Node: an Anycast Node providing service using a Global-Scope > Anycast Address. > > > Joe From jabley at hopcount.ca Mon Mar 17 15:11:40 2014 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 17 Mar 2014 11:11:40 -0400 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> References: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> Message-ID: <527E0ACC-B700-456E-A844-BF67F9A334DD@hopcount.ca> On 17 Mar 2014, at 10:27, manning bill wrote: > alas, our service predates Joe?s marvelous text. > > ?B? provides its services locally to its upstream ISPs. > We don?t play routing tricks, impose routing policy, or attempt to > influence prefix announcement. In the taxonomy I just shared, that makes the origin nodes of B all "global nodes". To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. It's specifically the terms "local" and "global" in a DNS anycast context that I was apologising for :-) Joe From bmanning at vacation.karoshi.com Mon Mar 17 15:51:03 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 17 Mar 2014 08:51:03 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <527E0ACC-B700-456E-A844-BF67F9A334DD@hopcount.ca> References: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> <527E0ACC-B700-456E-A844-BF67F9A334DD@hopcount.ca> Message-ID: <20140317155103.GA17402@vacation.karoshi.com> On Mon, Mar 17, 2014 at 11:11:40AM -0400, Joe Abley wrote: > > On 17 Mar 2014, at 10:27, manning bill wrote: > > > alas, our service predates Joe?s marvelous text. > > > > ?B? provides its services locally to its upstream ISPs. > > We don?t play routing tricks, impose routing policy, or attempt to > > influence prefix announcement. > > In the taxonomy I just shared, that makes the origin nodes of B all "global nodes". > > To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. > > It's specifically the terms "local" and "global" in a DNS anycast context that I was apologising for :-) > > > Joe No apology needed. I was clarifying why "B" is listed as a local node. That it doesn't fit you taxonomy is fine - but it does need an explaination. /bill From koalafil at gmail.com Mon Mar 17 15:56:18 2014 From: koalafil at gmail.com (Filiz Yilmaz) Date: Mon, 17 Mar 2014 16:56:18 +0100 Subject: Last Call and Draft program for RIPE 68 Message-ID: <9146D5AD-CD35-4605-9BA3-248DF586FBA3@gmail.com> Dear Colleagues, A list of currently accepted RIPE 68 presentations is now published at: https://ripe68.ripe.net/programme/meeting-plan/draft/ There are still few slots remaining for a final RIPE 68 programme and RIPE Programme Committee will accept new proposals until 6 April 2014. This is our last call for you to submit your proposals. Kind regards Filiz Yilmaz Chair, RIPE Programme Committee Begin forwarded message: > From: Filiz Yilmaz > Subject: Call for Presentations RIPE 68 > Date: 19 Nov 2013 19:04:34 GMT+1 > To: ripe-list at ripe.net, "nanog at nanog.org" > Cc: "pc at ripe.net Committee" > > > Dear colleagues, > > Please find the CFP for RIPE 68 below or at https://ripe68.ripe.net/submit-topic/cfp/. > > The deadline for submissions is 2 March 2014. > Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. > > Kind regards > > Filiz Yilmaz > RIPE PC Chair > http://www.ripe.net/ripe/meetings/ripe-meetings/pc > > > --------------------- > > Call for Presentations > > A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. > > RIPE 68 will take place from 12 ? 16 May 2014 in Warsaw, Poland. > > The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 68. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: > > ? IPv6 deployment > ? Managing IPv4 scarcity in operations > ? Commercial transactions of IPv4 addresses > ? Data centre technologies > ? Network and DNS operations > ? Internet governance and regulatory practices > ? Network and routing security > ? Content delivery > ? Internet peering and mobile data exchange > > Submissions > > RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. > > The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at > https://ripe68.ripe.net/submit-topic/presentation-formats/ > > Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. > > In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for ?lightning talks?, which are selected immediately before or during the conference. > > The following general requirements apply: > > - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 2 March 2014, using the meeting submission system at https://ripe68.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. > > - Lightning talks should also be submitted using the meeting submission system (https://ripe68.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice ? in some cases on the same day but often one day prior to the relevant session. > > - Presenters should indicate how much time they will require. > See more information on time slot allocations per presentation format at https://ripe68.ripe.net/submit-topic/presentation-formats/ > > - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. > > - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. > > If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. > > --------------------- > > From matthew at matthew.at Mon Mar 17 18:43:08 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 17 Mar 2014 11:43:08 -0700 Subject: pay.gov and IPv6 Message-ID: <5327423C.7090603@matthew.at> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman From arturo.servin at gmail.com Mon Mar 17 18:46:10 2014 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 17 Mar 2014 11:46:10 -0700 Subject: pay.gov and IPv6 In-Reply-To: <5327423C.7090603@matthew.at> References: <5327423C.7090603@matthew.at> Message-ID: No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman wrote: > Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail > when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of > client computers that should be dual-stacked are now relegated to IPv4-only > until someone remembers to turn it back on for each of them... sigh. > > Matthew Kaufman > > From matthew at matthew.at Mon Mar 17 18:55:29 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 17 Mar 2014 11:55:29 -0700 Subject: pay.gov and IPv6 In-Reply-To: References: <5327423C.7090603@matthew.at> Message-ID: <53274521.2050708@matthew.at> Windows 8 running Google Chrome as the browser. Matthew Kaufman On 3/17/2014 11:46 AM, Arturo Servin wrote: > > No Happy Eyeballs? > > Perhaps also time to ditch XP and IE for something new as well. > > -as > > > > > On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman > wrote: > > Random IPv6 complaint of the day: redirects from FCC.gov to > pay.gov fail when clients have IPv6 enabled. Work > fine if IPv6 is off. One more set of client computers that should > be dual-stacked are now relegated to IPv4-only until someone > remembers to turn it back on for each of them... sigh. > > Matthew Kaufman > > From jared at puck.nether.net Mon Mar 17 19:35:23 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 17 Mar 2014 15:35:23 -0400 Subject: pay.gov and IPv6 In-Reply-To: <53274521.2050708@matthew.at> References: <5327423C.7090603@matthew.at> <53274521.2050708@matthew.at> Message-ID: <40CAB98A-D0A5-4DE7-9760-8A782F45C736@puck.nether.net> No issues for me over IPv6 on Comcast. Perhaps some local network issue? Any reported issues if you try to visit http://www.test-ipv6.com/ ? - Jared On Mar 17, 2014, at 2:55 PM, Matthew Kaufman wrote: > Windows 8 running Google Chrome as the browser. > > Matthew Kaufman > > On 3/17/2014 11:46 AM, Arturo Servin wrote: >> >> No Happy Eyeballs? >> >> Perhaps also time to ditch XP and IE for something new as well. >> >> -as >> >> >> >> >> On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman > wrote: >> >> Random IPv6 complaint of the day: redirects from FCC.gov to >> pay.gov fail when clients have IPv6 enabled. Work >> fine if IPv6 is off. One more set of client computers that should >> be dual-stacked are now relegated to IPv4-only until someone >> remembers to turn it back on for each of them... sigh. >> >> Matthew Kaufman >> >> From marco at paesani.it Mon Mar 17 19:41:02 2014 From: marco at paesani.it (Marco Paesani) Date: Mon, 17 Mar 2014 20:41:02 +0100 Subject: pay.gov and IPv6 In-Reply-To: <5327423C.7090603@matthew.at> References: <5327423C.7090603@matthew.at> Message-ID: Hi Matthew, in Italy I see the site pay.gov in IPv6, as you can see: [image: Immagine in linea 1] Regards, Marco 2014-03-17 19:43 GMT+01:00 Matthew Kaufman : > Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail > when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of > client computers that should be dual-stacked are now relegated to IPv4-only > until someone remembers to turn it back on for each of them... sigh. > > Matthew Kaufman > > -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 17893 bytes Desc: not available URL: From jared at puck.nether.net Mon Mar 17 20:02:04 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 17 Mar 2014 16:02:04 -0400 Subject: pay.gov and IPv6 In-Reply-To: <40CAB98A-D0A5-4DE7-9760-8A782F45C736@puck.nether.net> References: <5327423C.7090603@matthew.at> <53274521.2050708@matthew.at> <40CAB98A-D0A5-4DE7-9760-8A782F45C736@puck.nether.net> Message-ID: <2FF51044-7990-4D7A-9A40-1B7F848214D4@puck.nether.net> One more (498?) set(s) of data points: I used RIPE ATLAS probes to check the SSL certificate over IPv6 (a nice way to check reachability).. Measurement# 1584700 You can look through the data to determine where it's not reachable from, but it seems to be "generally reachable" without issue from nearly all the probes. JSON link as well: https://atlas.ripe.net/api/v1/measurement/1584700/result/ - Jared On Mar 17, 2014, at 3:35 PM, Jared Mauch wrote: > No issues for me over IPv6 on Comcast. > > Perhaps some local network issue? Any reported issues if you try to visit http://www.test-ipv6.com/ ? > > - Jared > > On Mar 17, 2014, at 2:55 PM, Matthew Kaufman wrote: > >> Windows 8 running Google Chrome as the browser. >> >> Matthew Kaufman >> >> On 3/17/2014 11:46 AM, Arturo Servin wrote: >>> >>> No Happy Eyeballs? >>> >>> Perhaps also time to ditch XP and IE for something new as well. >>> >>> -as >>> >>> >>> >>> >>> On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman > wrote: >>> >>> Random IPv6 complaint of the day: redirects from FCC.gov to >>> pay.gov fail when clients have IPv6 enabled. Work >>> fine if IPv6 is off. One more set of client computers that should >>> be dual-stacked are now relegated to IPv4-only until someone >>> remembers to turn it back on for each of them... sigh. >>> >>> Matthew Kaufman >>> >>> > From matthew at matthew.at Mon Mar 17 22:41:26 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 17 Mar 2014 15:41:26 -0700 Subject: pay.gov and IPv6 In-Reply-To: <2FF51044-7990-4D7A-9A40-1B7F848214D4@puck.nether.net> References: <5327423C.7090603@matthew.at> <53274521.2050708@matthew.at> <40CAB98A-D0A5-4DE7-9760-8A782F45C736@puck.nether.net> <2FF51044-7990-4D7A-9A40-1B7F848214D4@puck.nether.net> Message-ID: <0DC64CF0-D31F-4A8B-95F0-DB904F1CE8D6@matthew.at> It was reachable by hand-typed URL, but the machines trying to follow a redirect from the FCC site during payment flow failed. Had to be brought back online, so once it was determined that turning v6 off was sufficient, that was the end if the debugging. Matthew Kaufman (Sent from my iPhone) > On Mar 17, 2014, at 1:02 PM, Jared Mauch wrote: > > One more (498?) set(s) of data points: > > I used RIPE ATLAS probes to check the SSL certificate over IPv6 (a nice way to check reachability).. > > Measurement# 1584700 > > You can look through the data to determine where it's not reachable from, but it seems to be "generally reachable" without issue from nearly all the probes. > > JSON link as well: > > https://atlas.ripe.net/api/v1/measurement/1584700/result/ > > - Jared > >> On Mar 17, 2014, at 3:35 PM, Jared Mauch wrote: >> >> No issues for me over IPv6 on Comcast. >> >> Perhaps some local network issue? Any reported issues if you try to visit http://www.test-ipv6.com/ ? >> >> - Jared >> >>> On Mar 17, 2014, at 2:55 PM, Matthew Kaufman wrote: >>> >>> Windows 8 running Google Chrome as the browser. >>> >>> Matthew Kaufman >>> >>>> On 3/17/2014 11:46 AM, Arturo Servin wrote: >>>> >>>> No Happy Eyeballs? >>>> >>>> Perhaps also time to ditch XP and IE for something new as well. >>>> >>>> -as >>>> >>>> >>>> >>>> >>>> On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman > wrote: >>>> >>>> Random IPv6 complaint of the day: redirects from FCC.gov to >>>> pay.gov fail when clients have IPv6 enabled. Work >>>> fine if IPv6 is off. One more set of client computers that should >>>> be dual-stacked are now relegated to IPv4-only until someone >>>> remembers to turn it back on for each of them... sigh. >>>> >>>> Matthew Kaufman > From arturo.servin at gmail.com Mon Mar 17 23:18:53 2014 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 17 Mar 2014 16:18:53 -0700 Subject: pay.gov and IPv6 In-Reply-To: <53274521.2050708@matthew.at> References: <5327423C.7090603@matthew.at> <53274521.2050708@matthew.at> Message-ID: HE should work then, perhaps another problem + IPv6. -as On Mon, Mar 17, 2014 at 11:55 AM, Matthew Kaufman wrote: > Windows 8 running Google Chrome as the browser. > > Matthew Kaufman > > > On 3/17/2014 11:46 AM, Arturo Servin wrote: > > > No Happy Eyeballs? > > Perhaps also time to ditch XP and IE for something new as well. > > -as > > > > > On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman wrote: > >> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail >> when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of >> client computers that should be dual-stacked are now relegated to IPv4-only >> until someone remembers to turn it back on for each of them... sigh. >> >> Matthew Kaufman >> >> > > From ag4ve.us at gmail.com Tue Mar 18 02:10:06 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 17 Mar 2014 22:10:06 -0400 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <532240A4.2040108@cox.net> Message-ID: On Mon, Mar 17, 2014 at 10:21 AM, Sholes, Joshua wrote: > On 3/13/14, 7:35 PM, "Larry Sheldon" wrote: > >>Not sure I can agree with that. I have been in this game for a very >>long time, but for most of it in places where the world's population >>cleaved neatly into two parts: "Authorized Users" who could be >>identified by the facts that they had ID cards, Badges, and knew the >>door code; and "trespassers" who were all others. >> >>Then you new kids came along and (pointlessly, in my opinion) divided >>the later group into the two described above. > > See, the way *I* learned it was that part of the creed of the "hacker" > involved "why would I want to play with your systems, mine are much > cooler."; that is, by definition a "hacker" is in the first group. > The point is that 'computer security' involves innovation as much as is done at hacker spaces (which can be geared to hardware or computer security or whatever). I think the difference you're trying to argue is the legality and not the task or process. I think calling the illegal form of the study of computer security "cracking", the legal form "hacking" and people who are "cracking" who don't know what they're doing "script kiddies" is irrelevant, useless, and causes useless debates (that I started) like this. From LarrySheldon at cox.net Tue Mar 18 02:15:36 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 17 Mar 2014 21:15:36 -0500 Subject: How to catch a cracker in the US? In-Reply-To: References: <531EB48A.3020609@truemetal.org> <9B309CA4-BD32-44F0-8508-209445248A56@arbor.net> <532240A4.2040108@cox.net> Message-ID: <5327AC48.90909@cox.net> On 3/17/2014 9:10 PM, shawn wilson wrote: > The point is that 'computer security' involves innovation as much as > is done at hacker spaces (which can be geared to hardware or computer > security or whatever). I think the difference you're trying to argue > is the legality and not the task or process. I think calling the > illegal form of the study of computer security "cracking", the legal > form "hacking" and people who are "cracking" who don't know what > they're doing "script kiddies" is irrelevant, useless, and causes > useless debates (that I started) like this. SSSSCOOOOOOOOORRRRRRE! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From email at edylie.net Tue Mar 18 08:47:57 2014 From: email at edylie.net (Pui Edylie) Date: Tue, 18 Mar 2014 16:47:57 +0800 Subject: Fusion Splicer Message-ID: <5328083D.8040900@edylie.net> Dear Member, Anyone can recommend a reliable and "affordable" fusion splicer please? Thanks! From grobe0ba at gmail.com Tue Mar 18 11:48:20 2014 From: grobe0ba at gmail.com (Atticus) Date: Tue, 18 Mar 2014 07:48:20 -0400 Subject: NetBSD as a TimeCapsule? In-Reply-To: <47BE60D5-FD51-47C2-9E57-77304B140928@nordu.net> References: <47BE60D5-FD51-47C2-9E57-77304B140928@nordu.net> Message-ID: Use avahi. From shawnl at up.net Tue Mar 18 12:35:06 2014 From: shawnl at up.net (Shawn L) Date: Tue, 18 Mar 2014 08:35:06 -0400 Subject: Fusion Splicer In-Reply-To: <5328083D.8040900@edylie.net> References: <5328083D.8040900@edylie.net> Message-ID: It depends on what you mean by affordable.... and how much you're going to use it. On Tue, Mar 18, 2014 at 4:47 AM, Pui Edylie wrote: > Dear Member, > > Anyone can recommend a reliable and "affordable" fusion splicer please? > > Thanks! > > > From tb at tburke.us Tue Mar 18 18:51:54 2014 From: tb at tburke.us (Tim Burke) Date: Tue, 18 Mar 2014 12:51:54 -0600 (MDT) Subject: ATT Postmaster Contact In-Reply-To: <532658AD.4040602@ropeguru.com> References: <532619BE.8030509@ropeguru.com> <532658AD.4040602@ropeguru.com> Message-ID: <252493216.216257.1395168714624.JavaMail.zimbra@tburke.us> I've had decent luck reaching out to abuse_rbl at abuse-att.net, any other method of contact seems to just go to /dev/null. It does generally take longer than 2 days to hear back, patience is a virtue. ----- Original Message ----- From: "Robert Webb" To: "Suresh Ramasubramanian" Cc: nanog at nanog.org Sent: Sunday, March 16, 2014 9:06:37 PM Subject: Re: ATT Postmaster Contact Thanks. I am the admin of the server. I only have one user of my list that has a bellsouth.net email address. As I stated before, the list might get 15 emails a month sent out. All users are put on the list by request only and only one person has authorization to send out. So there was NO way I was sending any unauthorized email of ANY type in order to get blocked. Robert On 03/16/2014 09:54 PM, Suresh Ramasubramanian wrote: > > They will respond usefully to you if you are the admin of that server. > If you are on shared hosting, you might ask your provider to contact > them. > > And two days is not an unreasonable time to handle a block issue. > > On 17-Mar-2014 3:09 am, "Robert Webb" > wrote: > > Anyone have a contact for postmaster at att.net ? > I have one user on an email list I send to and they are blocking > for abuse. This list might get 15 email a month that go out. > > Filled out their "form" but would like to get this resolved in > less than "2 days" as they state. > > Robert > From rs at seastrom.com Tue Mar 18 18:53:52 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 18 Mar 2014 14:53:52 -0400 Subject: NetBSD as a TimeCapsule? In-Reply-To: (Atticus's message of "Tue, 18 Mar 2014 07:48:20 -0400") References: <47BE60D5-FD51-47C2-9E57-77304B140928@nordu.net> Message-ID: <86bnx3z6bj.fsf@valhalla.seastrom.com> Atticus writes: > Use avahi. Isn't that built into netatalk3? -r From joelja at bogus.com Tue Mar 18 19:07:57 2014 From: joelja at bogus.com (joel jaeggli) Date: Tue, 18 Mar 2014 12:07:57 -0700 Subject: NetBSD as a TimeCapsule? In-Reply-To: <86bnx3z6bj.fsf@valhalla.seastrom.com> References: <47BE60D5-FD51-47C2-9E57-77304B140928@nordu.net> <86bnx3z6bj.fsf@valhalla.seastrom.com> Message-ID: <5328998D.9070408@bogus.com> On 3/18/14, 11:53 AM, Rob Seastrom wrote: > > Atticus writes: > >> Use avahi. > > Isn't that built into netatalk3? netatalk does the mdns for my afp shares and seems to work. > -r > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From Bruce.Curtis at ndsu.edu Tue Mar 18 21:11:27 2014 From: Bruce.Curtis at ndsu.edu (Curtis, Bruce) Date: Tue, 18 Mar 2014 21:11:27 +0000 Subject: pay.gov and IPv6 In-Reply-To: <5327423C.7090603@matthew.at> References: <5327423C.7090603@matthew.at> Message-ID: <205F72D7-4898-48E7-8E50-6024543F5A10@ndsu.edu> www.eda.gov has been broken since January. It has a AAAA record but when clients connect via IPv6 they see "Bad Request (Invalid Hostname)? rather than the web site. On Mar 17, 2014, at 1:43 PM, Matthew Kaufman wrote: > Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. > > Matthew Kaufman > --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From amps at djlab.com Tue Mar 18 19:24:59 2014 From: amps at djlab.com (Randy) Date: Tue, 18 Mar 2014 15:24:59 -0400 Subject: L6-20P -> L6-30R Message-ID: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip cords...sanity check...are connectors 'similar' enough that this is possible (with force) or am I going to find we've actually got L6-20R's on the provider side? -- ~Randy From eyeronic.design at gmail.com Tue Mar 18 22:46:26 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 18 Mar 2014 15:46:26 -0700 Subject: L6-20P -> L6-30R In-Reply-To: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: They're different. You can't force them. On Tue, Mar 18, 2014 at 12:24 PM, Randy wrote: > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a > 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > cords...sanity check...are connectors 'similar' enough that this is possible > (with force) or am I going to find we've actually got L6-20R's on the > provider side? > > -- > ~Randy > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From web at typo.org Tue Mar 18 22:52:47 2014 From: web at typo.org (Wayne E Bouchard) Date: Tue, 18 Mar 2014 15:52:47 -0700 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <20140318225247.GA83805@wakko.typo.org> The whole point behind the locking connectors (like the IEC connectors) is to prevent you from plugging the wrong connectors together. Not only are the different dimensions, but the prongs are keyed differently as well. If you put a L6-20P device into a L6-30R, then it was done by physically replacing the plug on the PDU, not by "making it work". I have had to do this at times but it is not strictly allowed by codes and not at all recommended. -Wayne On Tue, Mar 18, 2014 at 03:46:26PM -0700, Mike Hale wrote: > They're different. You can't force them. > > On Tue, Mar 18, 2014 at 12:24 PM, Randy wrote: > > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a > > 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > > cords...sanity check...are connectors 'similar' enough that this is possible > > (with force) or am I going to find we've actually got L6-20R's on the > > provider side? > > > > -- > > ~Randy > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From niels=nanog at bakker.net Tue Mar 18 22:54:22 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 18 Mar 2014 23:54:22 +0100 Subject: L6-20P -> L6-30R In-Reply-To: <20140318225247.GA83805@wakko.typo.org> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> Message-ID: <20140318225422.GA36211@burnout.tpb.net> * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: >I have had to do this at times but it is not strictly allowed by >codes and not at all recommended. It's an active fire hazard. The cables aren't rated (= built) for the power draw. -- Niels. From michael at supermathie.net Tue Mar 18 22:54:06 2014 From: michael at supermathie.net (Michael Brown) Date: Tue, 18 Mar 2014 18:54:06 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <20140318225406.6566035.33630.5244@supermathie.net> ?The connectors are definitely distinct and incompatible, you won't be able to force a 20 into a 30 or vice versa.? So yes, one of the ends has been changed. M. ? Original Message ? From: Randy Sent: Tuesday, March 18, 2014 18:42 To: nanog at nanog.org Reply To: amps at djlab.com Subject: L6-20P -> L6-30R I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip cords...sanity check...are connectors 'similar' enough that this is possible (with force) or am I going to find we've actually got L6-20R's on the provider side? -- ~Randy From george.herbert at gmail.com Tue Mar 18 22:54:44 2014 From: george.herbert at gmail.com (George Herbert) Date: Tue, 18 Mar 2014 15:54:44 -0700 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: https://www.21cii.com/ITStudio/Content/Resources/Images/Appendix/Plug%20&%20Power/SB%202P-3W_505x447.png I think the 250 v 15 amp plugs fit in the 20 amp sockets, but the 20s don't fit in the 30 sockets. This sort of thing is usually an adapter, a little cylinder with a L6-20R on one end and a L6-30P on the other, since the loads are safe. Either that, or a short jumper cable wired the same way. On Tue, Mar 18, 2014 at 3:46 PM, Mike Hale wrote: > They're different. You can't force them. > > On Tue, Mar 18, 2014 at 12:24 PM, Randy wrote: > > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to > a > > 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > > cords...sanity check...are connectors 'similar' enough that this is > possible > > (with force) or am I going to find we've actually got L6-20R's on the > > provider side? > > > > -- > > ~Randy > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > -- -george william herbert george.herbert at gmail.com From ivanov_andrei at yahoo.com Tue Mar 18 22:55:28 2014 From: ivanov_andrei at yahoo.com (Andrei Ivanov) Date: Tue, 18 Mar 2014 15:55:28 -0700 (PDT) Subject: L6-20P -> L6-30R In-Reply-To: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <1395183328.92609.YahooMailNeo@web163401.mail.gq1.yahoo.com> Randy wrote: > >I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to >a 208v/30A circuit (L6-30R).???Before I order the correct PDU's and whip >cords...sanity check...are connectors 'similar' enough that this is >possible (with force) or am I going to find we've actually got L6-20R's >on the provider side? They are slightly different. ? http://www.stayonline.com/detail.aspx?id=6772 ? http://www.stayonline.com/detail.aspx?id=6775 -- andrei From george.herbert at gmail.com Tue Mar 18 22:57:27 2014 From: george.herbert at gmail.com (George Herbert) Date: Tue, 18 Mar 2014 15:57:27 -0700 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: Crap, was looking at the non-locking ones. Ignore that. On Tue, Mar 18, 2014 at 3:54 PM, George Herbert wrote: > > https://www.21cii.com/ITStudio/Content/Resources/Images/Appendix/Plug%20&%20Power/SB%202P-3W_505x447.png > > I think the 250 v 15 amp plugs fit in the 20 amp sockets, but the 20s > don't fit in the 30 sockets. > > This sort of thing is usually an adapter, a little cylinder with a L6-20R > on one end and a L6-30P on the other, since the loads are safe. Either > that, or a short jumper cable wired the same way. > > > On Tue, Mar 18, 2014 at 3:46 PM, Mike Hale wrote: > >> They're different. You can't force them. >> >> On Tue, Mar 18, 2014 at 12:24 PM, Randy wrote: >> > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked >> to a >> > 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip >> > cords...sanity check...are connectors 'similar' enough that this is >> possible >> > (with force) or am I going to find we've actually got L6-20R's on the >> > provider side? >> > >> > -- >> > ~Randy >> > >> >> >> >> -- >> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> >> > > > -- > -george william herbert > george.herbert at gmail.com > -- -george william herbert george.herbert at gmail.com From dhubbard at dino.hostasaurus.com Tue Mar 18 23:09:49 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 18 Mar 2014 19:09:49 -0400 Subject: L6-20P -> L6-30R References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: I've had to do that before; provider gave me a 208v/30a circuit and I already had a power strip I wanted to re-use that had a corded L6-20P connector on it. I purchased a L6-30P plug / L6-20R receptacle adapter from http://www.stayonline.com/nema-locking-6-30-amp-adapters.aspx They're only $25 and they ship overnight if needed. They have one foot cabled versions of the same thing too if you have tight working space and there's not enough room for both connectors back to back; works as a strain relief too so maybe that option is better regardless. If you're trying to go the other direction, plugging an L6-30P into an L6-20R 20 amp circuit, that I'd recommend against because it never fails that someone says hey, 30 amp power strip, let me plug some more stuff into it not realizing it's on a 20 amp breakered circuit, then all your stuff goes down while you try to find the facility staff to reset the breaker. David -----Original Message----- From: Randy [mailto:amps at djlab.com] Sent: Tuesday, March 18, 2014 3:25 PM To: nanog at nanog.org Subject: L6-20P -> L6-30R I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip cords...sanity check...are connectors 'similar' enough that this is possible (with force) or am I going to find we've actually got L6-20R's on the provider side? -- ~Randy From streiner at cluebyfour.org Tue Mar 18 20:03:24 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 18 Mar 2014 16:03:24 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: On Tue, 18 Mar 2014, Randy wrote: > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a > 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > cords...sanity check...are connectors 'similar' enough that this is possible > (with force) or am I going to find we've actually got L6-20R's on the > provider side? Generally, all common electrical plugs and receptacles (straight-blade, twist-lock, IEC, and CEE) are physically sized and keyed differently, so that they can't be connected together, to keep people from connecting loads that require a specific voltage/current to supplies that aren't intended to provide it. While it's not uncommon for someone to replace a plug with "the right kind", this can (in order of badness): 1. start a fire 2. short out and (hopefully) trip a breaker - that's what breakers are for! 3. violate building/electrical codes 4. void your device's warranty As others have mentioned, just "making it work", rather than making it work correctly, can be bad news. People often fancy themselves unlicensed/uncertified electricians. I've seen some of the handiwork from such people, and while their creativity is impressive, having to rip their stuff out and re-do it is not fun. jms From jra at baylink.com Tue Mar 18 23:11:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Mar 2014 19:11:56 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Randy" > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to > a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > cords...sanity check...are connectors 'similar' enough that this is > possible (with force) or am I going to find we've actually got > L6-20R's on the provider side? As it happens, the chart at http://www.stayonline.com/reference-nema-locking.aspx suggests that the L6-20 and L6-30 are less different than you'd expect. I *think* those are on different diameters, and a datacenter employee ought to friggin' know better... but I don't think it's 100% impossible that this has happened. If it did, you're gonna replace the plug anyway... As long as there's a 20A breaker on the PDU, you're safe, if not within code. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From stephen at sprunk.org Tue Mar 18 23:15:50 2014 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 18 Mar 2014 18:15:50 -0500 Subject: L6-20P -> L6-30R In-Reply-To: <20140318225422.GA36211@burnout.tpb.net> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> Message-ID: <5328D3A6.6060502@sprunk.org> On 18-Mar-14 17:54, Niels Bakker wrote: > * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: >> I have had to do this at times but it is not strictly allowed by >> codes and not at all recommended. > > It's an active fire hazard. The cables aren't rated (= built) for the > power draw. That's a problem in the other direction, but plugging a 20A device into a 30A feed shouldn't be a hazard at all. 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/pkcs7-signature Size: 2394 bytes Desc: S/MIME Cryptographic Signature URL: From alex at corp.nac.net Tue Mar 18 23:19:02 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 18 Mar 2014 19:19:02 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D967@EXCHMBX.hq.nac.net> Strictly speaking, no, you cannot do this. The diameter of the pattern of the pins are different 20 to 30 amps. If no electrical inspectors are looking, yes, you can bend the pins and "make it work." I've done it, others have done it, but you shouldn't do it and it is a clear electrical code violation. Go to Lowes or Home Depot, but the right end, and stick it on there. You do still have the issue where the wire size is wrong, but if you have a brain and don't overload it, you will be OK. But, this too is still a clear electrical code violation. > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to > a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > cords...sanity check...are connectors 'similar' enough that this is possible > (with force) or am I going to find we've actually got L6-20R's on the provider > side? > > -- > ~Randy From alex at corp.nac.net Tue Mar 18 23:20:34 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 18 Mar 2014 19:20:34 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <20140318225422.GA36211@burnout.tpb.net> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D968@EXCHMBX.hq.nac.net> Go look at any standard household lamp. It has a 5-15P on the end of it, which could be plugged into an outlet rated for 20 amps (5-20R), with 16 gauge lamp cord rated for 10 amps or less. It all depends on the connected load. > * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: > >I have had to do this at times but it is not strictly allowed by codes > >and not at all recommended. > > It's an active fire hazard. The cables aren't rated (= built) for the power draw. > > > -- Niels. From amps at djlab.com Tue Mar 18 23:28:26 2014 From: amps at djlab.com (Randy) Date: Tue, 18 Mar 2014 19:28:26 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> References: <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> Message-ID: On 03/18/2014 7:11 pm, Jay Ashworth wrote: > As it happens, the chart at > > http://www.stayonline.com/reference-nema-locking.aspx > > suggests that the L6-20 and L6-30 are less different than you'd expect. > > I *think* those are on different diameters, and a datacenter employee > ought > to friggin' know better... but I don't think it's 100% impossible that > this > has happened. > > If it did, you're gonna replace the plug anyway... I plan on installing the correct PDU/cords shortly so no adapter should be needed, assuming it's really a L6-30R on the provider end. Disclaimer -- I never intended to break any codes, it was an oversight by me sending the wrong PDU, and onsite staff should have know better before hooking it up. -- ~Randy From rcarpen at network1.net Tue Mar 18 23:30:23 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 18 Mar 2014 19:30:23 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: <5328D3A6.6060502@sprunk.org> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <5328D3A6.6060502@sprunk.org> Message-ID: <223685878.648223.1395185423334.JavaMail.zimbra@network1.net> ----- Original Message ----- > On 18-Mar-14 17:54, Niels Bakker wrote: > > * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: > >> I have had to do this at times but it is not strictly allowed by > >> codes and not at all recommended. > > > > It's an active fire hazard. The cables aren't rated (= built) for the > > power draw. > > That's a problem in the other direction, but plugging a 20A device into > a 30A feed shouldn't be a hazard at all. Unless the device you are plugging in does not have its own breaker. If it doesn't, then your 20A cord could catch on fire before the 30A breaker trips. Not incredibly likely, but possible. -Randy From jra at baylink.com Tue Mar 18 23:30:21 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Mar 2014 19:30:21 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: <5328D3A6.6060502@sprunk.org> Message-ID: <14912255.12071.1395185421254.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stephen Sprunk" > On 18-Mar-14 17:54, Niels Bakker wrote: > > * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: > >> I have had to do this at times but it is not strictly allowed by > >> codes and not at all recommended. > > > > It's an active fire hazard. The cables aren't rated (= built) for > > the power draw. > > That's a problem in the other direction, but plugging a 20A device > into a 30A feed shouldn't be a hazard at all. Plugging a 20A *PDU* into a 30A receptacle can be dangerous if a) there is more than 20A of load plugged into it b) it has no breaker, and c) the cordset is only 12A, which is what you would expect on a 20A PDU. Cheers, -- jr 'up the voltage' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From laszlo at heliacal.net Tue Mar 18 23:49:32 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 18 Mar 2014 23:49:32 +0000 Subject: L6-20P -> L6-30R In-Reply-To: <14912255.12071.1395185421254.JavaMail.root@benjamin.baylink.com> References: <14912255.12071.1395185421254.JavaMail.root@benjamin.baylink.com> Message-ID: <129108F7-F20B-402F-BB5C-8AA84D50034B@heliacal.net> It's temporary unless it works. -Laszlo On Mar 18, 2014, at 11:30 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Stephen Sprunk" > >> On 18-Mar-14 17:54, Niels Bakker wrote: >>> * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: >>>> I have had to do this at times but it is not strictly allowed by >>>> codes and not at all recommended. >>> >>> It's an active fire hazard. The cables aren't rated (= built) for >>> the power draw. >> >> That's a problem in the other direction, but plugging a 20A device >> into a 30A feed shouldn't be a hazard at all. > > Plugging a 20A *PDU* into a 30A receptacle can be dangerous if > > a) there is more than 20A of load plugged into it > b) it has no breaker, and > c) the cordset is only 12A, which is what you would expect on a 20A PDU. > > Cheers, > -- jr 'up the voltage' a > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > From bill at herrin.us Wed Mar 19 01:39:46 2014 From: bill at herrin.us (William Herrin) Date: Tue, 18 Mar 2014 21:39:46 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <20140318225422.GA36211@burnout.tpb.net> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> Message-ID: On Tue, Mar 18, 2014 at 6:54 PM, Niels Bakker wrote: > * web at typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: >> I have had to do this at times but it is not strictly allowed by codes and >> not at all recommended. > > It's an active fire hazard. The cables aren't rated (= built) for the power > draw. Meh. It depends. Plug that 30 amp power strip into a 20 amp circuit. Try to use more than 20 amps and the main breaker trips. No problem. Plug that 20 amp power strip into a 30 amp circuit. Try to use more than 20 amps and the strip's breaker trips. No problem. Get a short before the strip breaker and the main breaker trips before the wires can heat. There just aren't a whole lot of failure modes here that result in fire short of one or the other breaker failing. And that results in fire regardless of the amperage mismatch. This, by the way, is why you're allowed to plug that 22 gauge Christmas light wire into a 15 amp receptacle even though it can't handle 15 amps: the 3 amp fuse will blow if there's a short. Just don't plug in anything with lower-rated wire that doesn't have its own breaker or fuse. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From LarrySheldon at cox.net Wed Mar 19 01:45:33 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 18 Mar 2014 20:45:33 -0500 Subject: L6-20P -> L6-30R In-Reply-To: References: Message-ID: <5328F6BD.9020107@cox.net> On 3/18/2014 2:24 PM, Randy wrote: > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to > a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip > cords...sanity check...are connectors 'similar' enough that this is > possible (with force) or am I going to find we've actually got L6-20R's > on the provider side? > http://www.amazon.com/L6-20P-L6-30R-Locking-Power-Adapter/dp/B004W359W0 -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From web at typo.org Wed Mar 19 01:55:12 2014 From: web at typo.org (Wayne E Bouchard) Date: Tue, 18 Mar 2014 18:55:12 -0700 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> Message-ID: <20140319015512.GA84427@wakko.typo.org> On Tue, Mar 18, 2014 at 09:39:46PM -0400, William Herrin wrote: > There just aren't a whole lot of failure modes here that result in > fire short of one or the other breaker failing. And that results in > fire regardless of the amperage mismatch. > > > This, by the way, is why you're allowed to plug that 22 gauge > Christmas light wire into a 15 amp receptacle even though it can't > handle 15 amps: the 3 amp fuse will blow if there's a short. Just > don't plug in anything with lower-rated wire that doesn't have its own > breaker or fuse. > > Regards, > Bill Herrin And that is the result of the way things have been set down. The electrical code (as well as just general common sense) requires that there are multiple levels of protection specifically to try to avoid "weird failure modes". So what we end up with is wire that is overrated for the current it is supposed to carry, multiple fusable links inbetween point A and point B and a grounding system that is supposed to safely direct voltage away from people in the event that everything else fails. So back to what I said before, I don't like doing stuff like that and don't advocate it if for no other reason that it makes good sense not to put yourself into a potentially problematic situation. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From brez at brezworks.com Wed Mar 19 02:34:24 2014 From: brez at brezworks.com (Jeremy Bresley) Date: Tue, 18 Mar 2014 21:34:24 -0500 Subject: L6-20P -> L6-30R In-Reply-To: <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> References: <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> Message-ID: <53290230.1080907@brezworks.com> On 3/18/2014 6:11 PM, Jay Ashworth wrote: > From: "Randy" >> I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to >> a 208v/30A circuit (L6-30R). Before I order the correct PDU's and whip >> cords...sanity check...are connectors 'similar' enough that this is >> possible (with force) or am I going to find we've actually got >> L6-20R's on the provider side? > As it happens, the chart at > > http://www.stayonline.com/reference-nema-locking.aspx > > suggests that the L6-20 and L6-30 are less different than you'd expect. > > I *think* those are on different diameters, and a datacenter employee ought > to friggin' know better... but I don't think it's 100% impossible that this > has happened. > > If it did, you're gonna replace the plug anyway... > > As long as there's a 20A breaker on the PDU, you're safe, if not within > code. From experience with some electricians who couldn't follow simple written instructions, it is physically possible to put an L6-20 plug into an L6-30 receptacle. But it won't lock into place. Beyond all the other reasons it's not recommended, the slightest bump of the cable will likely knock it loose causing whatever is on there to drop. (Cue electricans knocking the production 6506E's offline 3 times in 20 minutes while they were replacing the breakers and the supposedly redundant power cords...) If you can unplug it to look, every one I've ever seen has had the voltage and amperage clearly molded into the face of it. Jeremy "TheBrez" Bresley brez at brezworks.com From email at edylie.net Wed Mar 19 02:43:21 2014 From: email at edylie.net (Pui Edylie) Date: Wed, 19 Mar 2014 10:43:21 +0800 Subject: Fusion Splicer In-Reply-To: References: <5328083D.8040900@edylie.net> Message-ID: <53290449.5010809@edylie.net> Hi Shawn, Maybe 3K USD but i am open to any recommendation. The usage is going to be almost daily It seems Fujikura is the top contender Cheers On 3/18/2014 8:35 PM, Shawn L wrote: > It depends on what you mean by affordable.... and how much you're going to > use it. > > > On Tue, Mar 18, 2014 at 4:47 AM, Pui Edylie wrote: > >> Dear Member, >> >> Anyone can recommend a reliable and "affordable" fusion splicer please? >> >> Thanks! >> >> >> From sh.vahabzadeh at gmail.com Wed Mar 19 06:50:40 2014 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Wed, 19 Mar 2014 11:20:40 +0430 Subject: Zabbix Template for Cisco 7606 Message-ID: Hi everybody, Any body has template for zabbix for Cisco 7606? I need: - In/Out interface traffic, uptime, cpu & memory utilization, temperatures, ... - Graph and Trigger Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From lear at cisco.com Wed Mar 19 07:51:39 2014 From: lear at cisco.com (Eliot Lear) Date: Wed, 19 Mar 2014 08:51:39 +0100 Subject: US to relinquish control of Internet In-Reply-To: References: Message-ID: <53294C8B.3040606@cisco.com> Patrick: On 3/15/14, 12:42 AM, Patrick W. Gilmore wrote: > (As if the US has "control" anyway....) > > It's all over the "popular press", strange I haven't seen it here. > > > > > > > > Etc., etc. > > It's nice of the DoC to "relinquish" control, but I really don't see it changing much other than quieting down some hype from countries that were saying they were pissed at the US for "controlling" the Internet. And I couldn't really see those countries doing anything about it unless the US did something actually bad, which they wouldn't do IMHO. > > Was I being a pollyanna? > How things change is up to every person in the community. Operators are an incredibly important part of the Internet ecosystem. Some questions you might want to ask yourself: 1. What is the current legal framework for the IANA functions contract? If you don't know it, it's a good time to learn, if you are interested. 2. How does it impact operators? 3. What do operators want out of the evolution that is likely to take place? Discussions are taking place now in a few fora, including on the IAB's internetgovtech mailing list[1], where the focus has largely been on protocol parameters, one of the IANA pillars. Olaf Kolkman has written a very interesting draft draft-iab-iana-framework[2] that gives you at least one view on how to think about the problem. The IETF has some draft principles that are being knocked around.[3] There is a separate 1net mailing list[4] in which mostly the ICANN component is being discussed. Also, there will be meetings, the ICANN one starting on Friday in Singapore, as but one example where this topic will be discussed in person. I'm going to hazard a guess that the RIRs will also be discussing this, both on lists and in person. Assuredly other governments are paying attention. While I speak only for myself in this email, I will also point out that Cisco did make a statement about the NTIA announcement.[5] So have others. Eliot [1] https://www.iab.org/mailman/listinfo/internetgovtech [2] http://tools.ietf.org/html/draft-iab-iana-framework-01 [3] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12562.html [4] http://1net-mail.1net.org/mailman/listinfo/discuss [5] http://blogs.cisco.com/gov/cisco-supports-u-s-department-of-commerce-decision-to-transition-internet-management-functions/ From rs at seastrom.com Wed Mar 19 11:33:49 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 19 Mar 2014 07:33:49 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D968@EXCHMBX.hq.nac.net> (Alex Rubenstein's message of "Tue, 18 Mar 2014 19:20:34 -0400") References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D968@EXCHMBX.hq.nac.net> Message-ID: <86mwgm1kyq.fsf@valhalla.seastrom.com> Alex Rubenstein writes: > Go look at any standard household lamp. It has a 5-15P on the end of > it, which could be plugged into an outlet rated for 20 amps (5-20R), > with 16 gauge lamp cord rated for 10 amps or less. Mine all seem to be NEMA 1-15P, some (most?) with 18 AWG wire. Have I been shortchanged? :) -r From alex at corp.nac.net Wed Mar 19 12:00:18 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 19 Mar 2014 08:00:18 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <86mwgm1kyq.fsf@valhalla.seastrom.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D968@EXCHMBX.hq.nac.net> <86mwgm1kyq.fsf@valhalla.seastrom.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D9D0@EXCHMBX.hq.nac.net> > > Go look at any standard household lamp. It has a 5-15P on the end of > > it, which could be plugged into an outlet rated for 20 amps (5-20R), > > with 16 gauge lamp cord rated for 10 amps or less. > > Mine all seem to be NEMA 1-15P, some (most?) with 18 AWG wire. > > Have I been shortchanged? :) I wrote that too fast, you are absolutely right. But my point remains. Appliance/load wire size is often, and many times smaller than the ampacity of the circuit. Heck, how many times have you plugged in a 14 gauge extension cord to a 5-20R? From lowen at pari.edu Wed Mar 19 13:07:23 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 19 Mar 2014 09:07:23 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <5329968B.6070608@pari.edu> On 03/18/2014 09:39 PM, William Herrin wrote: > Meh. It depends. Plug that 30 amp power strip into a 20 amp circuit. > Try to use more than 20 amps and the main breaker trips. No problem. > Plug that 20 amp power strip into a 30 amp circuit. Try to use more > than 20 amps and the strip's breaker trips. No problem. Get a short > before the strip breaker and the main breaker trips before the wires > can heat. There just aren't a whole lot of failure modes here that > result in fire short of one or the other breaker failing. And that > results in fire regardless of the amperage mismatch. The amount of misinformation in this thread is astonishing. > This, by the way, is why you're allowed to plug that 22 gauge > Christmas light wire into a 15 amp receptacle even though it can't > handle 15 amps: the 3 amp fuse will blow if there's a short. Just > don't plug in anything with lower-rated wire that doesn't have its own > breaker or fuse. Regards, Bill Herrin Note that in those cases the fuse is in the plug; anywhere else wouldn't be ok. As small as 18AWG may be used for fixture wire on a 20A circuit, per 240.5(B)(2)(1). 2011 NEC article 210.23(A) permits 15A receptacles on 20A branch circuits; 30A branch circuits must use 30A receptacles. If the OP's 30A branch circuit has an L6-20R on it then this would be a violation; see NEC Table 210.24 for a summary of the code. 406.8 is the article requiring that cord caps (plugs) are not supposed to be interchangeable. Now, article 240.5 is the relevant article in the NEC. This can get a bit tricky to apply; if the PDU in question is *listed* for connection to a 30A circuit then that's OK (240.5(B)(1)); the individual fixture wires within the PDU for a 30A PDU can be as small as 14AWG as long as they're protected (240.5(B)(2)(4)), but field assembled extension cord sets for a 30A circuit would need 10AWG conductors, as they aren't covered by the exception in 240.5(B)(4) and thus fall under 240.5(A). It's definitely allowed to connect a 30A PDU with 10AWG conductors to a 30A branch circuit; anything else could be OK, depending upon the local authority having jurisdiction and its interpretation of the 240.5 exceptions, which aren't the clearest section of the NEC, IMO. And article 645, dealing with ITE rooms, only requires that cords be listed for use with IT equipment and be less than 4.5m in length. IMO, and my degree is in EE, it is possible to have a fault condition in a 12AWG cord that won't trip a 30A breaker but could cause a fire and be prior to the input breaker in the PDU. The OP appears to be doing the right thing and getting a 30A PDU. From EDugas at zerofail.com Wed Mar 19 13:20:03 2014 From: EDugas at zerofail.com (Eric Dugas) Date: Wed, 19 Mar 2014 13:20:03 +0000 Subject: Fusion Splicer In-Reply-To: <53290449.5010809@edylie.net> References: <5328083D.8040900@edylie.net> <53290449.5010809@edylie.net> Message-ID: <656AAF5E8566DF47835F38F66FA8213A15EA681C@ZF-EXC1.Pre2Post.local> We have the 70S, it's pretty awesome. We paid around $15K CAD new. You might want to look for the 12S or 19S if the price is an issue. I believe you can also find them refurbished. Eric -----Original Message----- From: Pui Edylie [mailto:email at edylie.net] Sent: March 18, 2014 10:43 PM To: Shawn L; nanog Subject: Re: Fusion Splicer Hi Shawn, Maybe 3K USD but i am open to any recommendation. The usage is going to be almost daily It seems Fujikura is the top contender Cheers On 3/18/2014 8:35 PM, Shawn L wrote: > It depends on what you mean by affordable.... and how much you're > going to use it. > > > On Tue, Mar 18, 2014 at 4:47 AM, Pui Edylie wrote: > >> Dear Member, >> >> Anyone can recommend a reliable and "affordable" fusion splicer please? >> >> Thanks! >> >> >> From rs at seastrom.com Wed Mar 19 13:32:13 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 19 Mar 2014 09:32:13 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D9D0@EXCHMBX.hq.nac.net> (Alex Rubenstein's message of "Wed, 19 Mar 2014 08:00:18 -0400") References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D968@EXCHMBX.hq.nac.net> <86mwgm1kyq.fsf@valhalla.seastrom.com> <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D9D0@EXCHMBX.hq.nac.net> Message-ID: <86d2hi9uw2.fsf@valhalla.seastrom.com> Alex Rubenstein writes: > But my point remains. Appliance/load wire size is often, and many > times smaller than the ampacity of the circuit. > > Heck, how many times have you plugged in a 14 gauge extension cord > to a 5-20R? I do this all the time. In (all our) defense, lamp cord is the closest thing to conductors in free air that most people will ever run into, and although the insulation isn't high temperature stuff, the heat buildup isn't the same as a few dozen THHN conductors in EMT. If you want something that will make your head explode a little (until you think it through and realize that "ampacity" is just another way of expressing "i^2r losses plus dissipation rate), read NEC table 630.11(A), and then 630.12(A) and noodle on just how skinny a wire you can use for hooking up a (home, low duty cycle) welder that's breakered at 50 amps. 12 AWG anyone? -r From cra at WPI.EDU Wed Mar 19 13:49:08 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 19 Mar 2014 09:49:08 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <20140319134907.GW7867@angus.ind.WPI.EDU> On Tue, Mar 18, 2014 at 07:09:49PM -0400, David Hubbard wrote: > I've had to do that before; provider gave me a 208v/30a circuit and I > already had a power strip I wanted to re-use that had a corded L6-20P > connector on it. I purchased a L6-30P plug / L6-20R receptacle adapter > from http://www.stayonline.com/nema-locking-6-30-amp-adapters.aspx > They're only $25 and they ship overnight if needed. They have one foot > cabled versions of the same thing too if you have tight working space > and there's not enough room for both connectors back to back; works as a > strain relief too so maybe that option is better regardless. This is not really a safe thing to do unless the "adapter" has a 20A circuit breaker as part of it, or if you change out the upstream circuit breaker from 30A to 20A (and hopefully clearly mark the outlet as such). > If you're trying to go the other direction, plugging an L6-30P into an > L6-20R 20 amp circuit, that I'd recommend against because it never fails > that someone says hey, 30 amp power strip, let me plug some more stuff > into it not realizing it's on a 20 amp breakered circuit, then all your > stuff goes down while you try to find the facility staff to reset the > breaker. Going this way is safe, but as you say, you can only draw 20A (actually, you can usually only draw a derated 80% of that, so 16A). From bill at herrin.us Wed Mar 19 13:51:53 2014 From: bill at herrin.us (William Herrin) Date: Wed, 19 Mar 2014 09:51:53 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <5329968B.6070608@pari.edu> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <5329968B.6070608@pari.edu> Message-ID: On Wed, Mar 19, 2014 at 9:07 AM, Lamar Owen wrote: > 2011 NEC article 210.23(A) permits 15A receptacles on 20A branch circuits; > 30A branch circuits must use 30A receptacles. If the OP's 30A branch > circuit has an L6-20R on it then this would be a violation; see NEC Table > 210.24 for a summary of the code. Hi Lamar, Nobody is talking about putting an L6-20R on a 30 amp circuit. OP was talking about putting an L6-30P on a 20 amp appliance: a PDU that has its own 20 amp breaker. Big difference. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From paul at paulstewart.org Wed Mar 19 14:01:11 2014 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 19 Mar 2014 10:01:11 -0400 Subject: Customer Support Ticketing Message-ID: Hey folks?. We need a new customer ticketing system and I?m looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP?s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul From tb at tburke.us Wed Mar 19 14:35:45 2014 From: tb at tburke.us (Tim Burke) Date: Wed, 19 Mar 2014 08:35:45 -0600 (MDT) Subject: Customer Support Ticketing In-Reply-To: References: Message-ID: <910791771.44711.1395239745986.JavaMail.zimbra@tburke.us> Kayako is the way to go. IIRC they have a trial up on their website, may be worth checking out. Tim ----- Original Message ----- From: "Paul Stewart" To: nanog at nanog.org Sent: Wednesday, March 19, 2014 9:01:11 AM Subject: Customer Support Ticketing Hey folks?. We need a new customer ticketing system and I?m looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP?s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul From joe at nethead.com Wed Mar 19 14:50:09 2014 From: joe at nethead.com (Joe Hamelin) Date: Wed, 19 Mar 2014 07:50:09 -0700 Subject: Customer Support Ticketing In-Reply-To: <910791771.44711.1395239745986.JavaMail.zimbra@tburke.us> References: <910791771.44711.1395239745986.JavaMail.zimbra@tburke.us> Message-ID: Kayako is what we use. We're happy with it. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, Mar 19, 2014 at 7:35 AM, Tim Burke wrote: > Kayako is the way to go. IIRC they have a trial up on their website, may > be worth checking out. > > Tim > > ----- Original Message ----- > From: "Paul Stewart" > To: nanog at nanog.org > Sent: Wednesday, March 19, 2014 9:01:11 AM > Subject: Customer Support Ticketing > > Hey folks.... > > We need a new customer ticketing system and I'm looking for input. I am > still working on a scope document on everything we want to do with the new > system. > > The most common problem I run across is that a system is either built for > enterprise internal IT helpdesk or it is built like a CRM sales tracking > system. We are an ISP among other things and are looking for a powerful > and > yet reasonable cost system to answer email inquiries, allow customers to > open tickets via portal, mobile support, escalation/SLA support, and > several > other things. Solarwinds NPM integration would be a huge bonus but not a > deal breaker. If anyone has a system that they have integrated with Ivue > from NISC (our billing platform) I would be really interested in hearing > more as well. > > So my question is meant high level. For those folks that are ISP's > supporting business customers (including managed customers) along with > residential eyeball traffic what system(s) do you use and what do you > like/dislike? > > I've looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, > ZenDesk, HappyFox, Kayako and several others. All of them so far would > require a fair amount of configuration or modifications based on our still > developing wish list. Also worth noting is that we have no full time > development staff so hoping to find something that has a lot of promise and > then work with the vendor to evolve it into what we feel we need. > > **This is not an invitation for sales folks to call on me** > > Thanks, > > Paul > > > > > > From faisal at snappytelecom.net Wed Mar 19 14:56:43 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 19 Mar 2014 14:56:43 +0000 (GMT) Subject: Customer Support Ticketing In-Reply-To: References: Message-ID: <1834462319.77277.1395241003292.JavaMail.root@snappytelecom.net> The advice I will share with you is as follows:- Take your wish list and divide it into Core Functions (need to have), Functions (want to have) and Functions (nice to have). Be prepared to compromise, the most troublesome area is going to be the Functions (want to have).. Many of us want to fit new software to existing processes, while forgetting that the existing processes were designed to deal with current systems/limitations. Most of this can be resolved by some other form of external process or procedure change , be it manual or some sort of external reference... I am not a big fan of software customization, creates challenge with updates & upgrades, ( don't confuse software customization with software integration). Having said that, for us (we are an entity that is very much similar to what you have described in your email), we have been using Kayako. We found it to be very flexible for handling support tickets, email inquires and also a central repository for Alerts etc. We are now in the process of implementing a new Customer Billing package, (Freeside), which has RT integration, so we are most likely going to move a few of the mail queues to Freeside/RT, while leaving kayako to handle the other email queues. My point is, while it is nice to have a 'fully integrated' system, such a system starts to have it's shortcomings from day one... (e.g. if you tie it to your billing system, then what do you do with sales inquires ? you don't want to overload the system with junk.. or even system alert trouble tickets).... Over the years we have found it more practical to develop some process to tie the info together in billing and ticketing system (we record ticket # in the billing system, as a ref. for related tickets), than try to do some sort of automation / customization. Of Course your mileage may vary. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Paul Stewart" > To: nanog at nanog.org > Sent: Wednesday, March 19, 2014 10:01:11 AM > Subject: Customer Support Ticketing > > Hey folks?. > > We need a new customer ticketing system and I?m looking for input. I am > still working on a scope document on everything we want to do with the new > system. > > The most common problem I run across is that a system is either built for > enterprise internal IT helpdesk or it is built like a CRM sales tracking > system. We are an ISP among other things and are looking for a powerful and > yet reasonable cost system to answer email inquiries, allow customers to > open tickets via portal, mobile support, escalation/SLA support, and several > other things. Solarwinds NPM integration would be a huge bonus but not a > deal breaker. If anyone has a system that they have integrated with Ivue > from NISC (our billing platform) I would be really interested in hearing > more as well. > > So my question is meant high level. For those folks that are ISP?s > supporting business customers (including managed customers) along with > residential eyeball traffic what system(s) do you use and what do you > like/dislike? > > I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, > ZenDesk, HappyFox, Kayako and several others. All of them so far would > require a fair amount of configuration or modifications based on our still > developing wish list. Also worth noting is that we have no full time > development staff so hoping to find something that has a lot of promise and > then work with the vendor to evolve it into what we feel we need. > > **This is not an invitation for sales folks to call on me** > > Thanks, > > Paul > > > > > From david at mailplus.nl Wed Mar 19 15:02:06 2014 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Wed, 19 Mar 2014 16:02:06 +0100 Subject: Customer Support Ticketing In-Reply-To: References: Message-ID: <78C35D6C1A82D243B830523B4193CF5F75AE919CE1@SBS1.blinker.local> Hi Paul, I formerly worked at Topdesk http://www.topdesk.co.uk/. I use it at my current employer. It has a nice webbased GUI. It is not a simplistic IT helpdesk type of software (and therefore not ultra cheap). I don't know much about integration options (used to be fairly ok). If you get crazy prices then nag a little longer (and mention competitors). They have all the features you want: Create tickets from email, SLA, change management, escalation, ... I am a real complainer but I am quite happy with it. Another thing I noticed in the past is ManageEngine. I liked it but know not much about it. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: Paul Stewart [mailto:paul at paulstewart.org] Verzonden: Wednesday, March 19, 2014 3:01 PM Aan: nanog at nanog.org Onderwerp: Customer Support Ticketing Hey folks?. We need a new customer ticketing system and I?m looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP?s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul From dhubbard at dino.hostasaurus.com Wed Mar 19 15:04:33 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 19 Mar 2014 11:04:33 -0400 Subject: Customer Support Ticketing References: <910791771.44711.1395239745986.JavaMail.zimbra@tburke.us> Message-ID: Kayako is pretty reasonable with a few caveats. If you self host it, which I recommend from a security/supportability/customization standpoint, then you are also taking the trade off of dealing with upgrading it yourself, which is not always easy. Make use of their LoginShare functionality to offload authentication duties since their internal method is not particularly secure (unsalted SHA1). If you let it parse emails, with large attachments, you'll have to fine tune its memory allowance and how many emails it retrieves per attempt as well as how frequently it grabs them; it can use a lot of memory and it's not the fastest thing, so you don't want to have it happen to frequently where the prior job may still be running. The search functionality is absolutely horrible and has been for at least eight years now; it will turn up completely irrelevant tickets and rarely turns up the correct ones. If what you want to search for is in the ticket body rather than the private ticket notes, you do at least have the option of entering raw SQL LIKE arguments, so you can search for something like %parameter% and let MySQL do the work instead of Kayako, assuming your term is unique enough to find what you needed. If you need a better search of all fields, you'd have to write your own. I haven't personally used the Solarwinds product, but if it's like their others, the license fees will be outrageous, either now or they'll get you later, and their sales staff will bother you incessently with better and better short term promotions. David -----Original Message----- From: Tim Burke [mailto:tb at tburke.us] Sent: Wednesday, March 19, 2014 10:36 AM To: Paul Stewart Cc: nanog at nanog.org Subject: Re: Customer Support Ticketing Kayako is the way to go. IIRC they have a trial up on their website, may be worth checking out. Tim ----- Original Message ----- From: "Paul Stewart" To: nanog at nanog.org Sent: Wednesday, March 19, 2014 9:01:11 AM Subject: Customer Support Ticketing Hey folks.... We need a new customer ticketing system and I'm looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP's supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I've looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul From lowen at pari.edu Wed Mar 19 15:22:30 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 19 Mar 2014 11:22:30 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <5329B636.70107@pari.edu> On 03/19/2014 09:51 AM, William Herrin wrote: > Nobody is talking about putting an L6-20R on a 30 amp circuit. OP was > talking about putting an L6-30P on a 20 amp appliance: a PDU that has > its own 20 amp breaker. Big difference. If the PDU isn't listed for 30A then it's the essentially the same thing, safety-wise. Unless there is overcurrent protection at the source of the feed to the conductors of the flexible cord (240.21) that meets the ampacity of the conductors of said flexible cord, unless one of the exceptions of 240.5 apply, then it's a potentially unsafe condition (NEC doesn't directly apply to supply cords of appliances themselves; that's what the 'listing' is for from UL or similar; see http://ecmweb.com/code-basics/nec-rules-overcurrent-protection-equipment-and-conductors for more info, and see UL's FAQ entry for modifications to listed equipment at www.ul.com/global/eng/pages/offerings/perspectives/regulator/faq/). Just replacing an L6-20P with an L6-30P on a 20A-listed PDU would be unsafe and (IMO) unwise, since the breaker in the input of the PDU does not protect the flexible cord's conductors from internal overcurrent faults. A 20A listed PDU should have 20A overcurrent protection to the connected receptacle, in addition to any overcurrent protection internal to the PDU. A cord with a 20A ampacity may overheat significantly if it faults internally in such a way as to cause more than 20A, but less than 30A (or whatever overcurrent protection is in the branch circuit), to flow; there are numerous ways cords can fault in this manner. You could easily get a situation where the cord is partially faulted internally but the PDU's breaker doesn't detect it because the fault shunts current ahead of that breaker; again, not a dead short but still an overcurrent fault. I've seen this type of fault before, where the cord itself was shunting a few amps prior to the PDU input breaker (in this particular case the cord was damaged by lightning, even though the equipment to which it was connected still had power). But the other condition, where a 20A breaker is feeding a 30A PDU, could result in dropping power to the PDU but is not unsafe. I know that I wouldn't approve (in the NEC-speak sense of that word) of the use of any of these adapters or similar kludges in my data centers, as the insurance liability issues are potentially much more costly than just buying the right PDU or running a branch circuit with the correct overcurrent protection in the first place. It also depends a bit on exactly how the PDU is listed. You can look up the listing's details in the UL White Book (download link: http://www.ul.com/global/documents/offerings/perspectives/regulators/2013_WB_LINKED_FINAL.pdf ). But the final say rests with the authority having jurisdiction, AHJ in NEC-speak. From lowen at pari.edu Wed Mar 19 15:32:20 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 19 Mar 2014 11:32:20 -0400 Subject: Fusion Splicer In-Reply-To: <656AAF5E8566DF47835F38F66FA8213A15EA681C@ZF-EXC1.Pre2Post.local> References: <5328083D.8040900@edylie.net> Message-ID: <5329B884.6090303@pari.edu> On 03/19/2014 09:20 AM, Eric Dugas wrote: > We have the 70S, it's pretty awesome. We paid around $15K CAD new. You might want to look for the 12S or 19S if the price is an issue. I believe you can also find them refurbished. > > We have a 17S, and are very happy with it. We paid a little more than $8K for ours new, and used units should be available for quite a bit less these days. From bill at herrin.us Wed Mar 19 16:24:38 2014 From: bill at herrin.us (William Herrin) Date: Wed, 19 Mar 2014 12:24:38 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <5329B636.70107@pari.edu> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <5329968B.6070608@pari.edu> <5329B636.70107@pari.edu> Message-ID: On Wed, Mar 19, 2014 at 11:22 AM, Lamar Owen wrote: > Just replacing an L6-20P with an L6-30P on a 20A-listed PDU would be unsafe > and (IMO) unwise, since the breaker in the input of the PDU does not protect > the flexible cord's conductors from internal overcurrent faults. Yet an 18 awg PC power cable is perfectly safe when plugged in to a 5-20R on a circuit with a 20 amp breaker. Get real man. You got two things right: The NEC (and related fire codes) don't apply to supply cords of appliances in circumstances such as OP's PDU. The modification cancels the UL certification. If you have an external requirement to use only UL certified components then you can't make any modifications no matter how obviously safe they are. By the way, you either don't have that requirement or you're breaking it. Your custom network cables are not UL certified. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mstaudinger at corp.earthlink.com Wed Mar 19 16:48:12 2014 From: mstaudinger at corp.earthlink.com (Staudinger, Malcolm) Date: Wed, 19 Mar 2014 16:48:12 +0000 Subject: L6-20P -> L6-30R In-Reply-To: <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> Message-ID: <29a2b95e939a4e12b27c567264980938@EDGMBXV06.marvel.elnk.net> I recently bought a UPS with a 30R plug on it, and sat and tried for about 20 minutes to plug it into what I thought was a 30 socket. It was, in fact, a 20. They're similar enough that if you're looking at the ends you might be convinced that someone has bent a one of the ends of the plug funny, but no amount of trying will make them fit. Malcolm -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Tuesday, March 18, 2014 4:12 PM To: NANOG Subject: Re: L6-20P -> L6-30R ----- Original Message ----- > From: "Randy" > I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked > to a 208v/30A circuit (L6-30R). Before I order the correct PDU's and > whip cords...sanity check...are connectors 'similar' enough that this > is possible (with force) or am I going to find we've actually got > L6-20R's on the provider side? As it happens, the chart at http://www.stayonline.com/reference-nema-locking.aspx suggests that the L6-20 and L6-30 are less different than you'd expect. I *think* those are on different diameters, and a datacenter employee ought to friggin' know better... but I don't think it's 100% impossible that this has happened. If it did, you're gonna replace the plug anyway... As long as there's a 20A breaker on the PDU, you're safe, if not within code. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From cra at WPI.EDU Wed Mar 19 17:06:51 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 19 Mar 2014 13:06:51 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <5329968B.6070608@pari.edu> <5329B636.70107@pari.edu> Message-ID: <20140319170650.GB7867@angus.ind.WPI.EDU> On Wed, Mar 19, 2014 at 12:24:38PM -0400, William Herrin wrote: > On Wed, Mar 19, 2014 at 11:22 AM, Lamar Owen wrote: > > Just replacing an L6-20P with an L6-30P on a 20A-listed PDU would be unsafe > > and (IMO) unwise, since the breaker in the input of the PDU does not protect > > the flexible cord's conductors from internal overcurrent faults. > > Yet an 18 awg PC power cable is perfectly safe when plugged in to a > 5-20R on a circuit with a 20 amp breaker. Get real man. Not really, that is just a compromise in safety standards for convenience. It was deemed to be safe enough given the comparatively low current 20A circuit and the open-to-air power cord. For higher current circuits 30A and up, the safety standards are more stringent. > The NEC (and related fire codes) don't apply to supply cords of > appliances in circumstances such as OP's PDU. > > The modification cancels the UL certification. If you have an external > requirement to use only UL certified components then you can't make > any modifications no matter how obviously safe they are. > > By the way, you either don't have that requirement or you're breaking > it. Your custom network cables are not UL certified. There is more to safety than just being "certified". Acting in ways that /actually/ improves safety (if you are allowed to) is important. This isn't just black and white. Safety, like security, isn't absolute. Both benefit from defense-in-depth, and both require compromise to balance safety vs. convenience. From jmaslak at antelope.net Wed Mar 19 17:09:34 2014 From: jmaslak at antelope.net (Joel Maslak) Date: Wed, 19 Mar 2014 11:09:34 -0600 Subject: L6-20P -> L6-30R In-Reply-To: <29a2b95e939a4e12b27c567264980938@EDGMBXV06.marvel.elnk.net> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <6818639.12069.1395184316156.JavaMail.root@benjamin.baylink.com> <29a2b95e939a4e12b27c567264980938@EDGMBXV06.marvel.elnk.net> Message-ID: You probably should ask your facility operator or electrician what the requirements are (who, unlike most network engineers, is qualified to decide what to do), but it sounds like replacing the PDU is simple and easy, and unquestionably not a bad thing to do. Alternatively, you can replace the 30A circuit with a 20A one. I'm not an electrician, but I'll bet it's not much more complex or expensive than replacing a breaker and a receptacle, and I'd be shocked if it took more than an hour of a qualified person's time, and I suspect it would cost about the same for parts as building some sort of adaptor cord (and less if you the electrician has spare parts - he gets a 30A breaker and 30A socket in exchange for a 20A breaker and 20A socket). The added benefit of 20A, assuming your equipment power usage is low enough to use 20A, is that it's usually cheaper (sometimes significantly) if you're paying someone else for the power circuit each month. From jra at baylink.com Wed Mar 19 17:18:19 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Mar 2014 13:18:19 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: Message-ID: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "William Herrin" > On Wed, Mar 19, 2014 at 11:22 AM, Lamar Owen wrote: > > Just replacing an L6-20P with an L6-30P on a 20A-listed PDU would be unsafe > > and (IMO) unwise, since the breaker in the input of the PDU does not protect > > the flexible cord's conductors from internal overcurrent faults. > > Yet an 18 awg PC power cable is perfectly safe when plugged in to a > 5-20R on a circuit with a 20 amp breaker. Get real man. A PC isn't a power distribution device. > You got two things right: > > The NEC (and related fire codes) don't apply to supply cords of > appliances in circumstances such as OP's PDU. A PDU is *not* an appliance. > The modification cancels the UL certification. If you have an external > requirement to use only UL certified components then you can't make > any modifications no matter how obviously safe they are. UL doesn't "certify" items. It "lists" them. It does so *specifically on behalf of* fire insurors. > By the way, you either don't have that requirement or you're breaking > it. Your custom network cables are not UL certified. Network cables don't carry power. Generally, Bill, you're one of the Smart People here. But what Lamar says accords with my (limited) formal electrical training, and what you say does not. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Wed Mar 19 17:21:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Mar 2014 13:21:05 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: Message-ID: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joel Maslak" > Alternatively, you can replace the 30A circuit with a 20A one. I'm not an > electrician, but I'll bet it's not much more complex or expensive than > replacing a breaker and a receptacle, It is exactly that: no one says you *can't* wire a 20A branch circuit with #10. It is even *possible*, though unlikely, that if you did so, you wouldn't have to derate it to 80%. I would have to reread the Code to be sure. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bill at herrin.us Wed Mar 19 17:21:01 2014 From: bill at herrin.us (William Herrin) Date: Wed, 19 Mar 2014 13:21:01 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <20140319170650.GB7867@angus.ind.WPI.EDU> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <5329968B.6070608@pari.edu> <5329B636.70107@pari.edu> <20140319170650.GB7867@angus.ind.WPI.EDU> Message-ID: On Wed, Mar 19, 2014 at 1:06 PM, Chuck Anderson wrote: >> Yet an 18 awg PC power cable is perfectly safe when plugged in to a >> 5-20R on a circuit with a 20 amp breaker. Get real man. > > Not really, that is just a compromise in safety standards for > convenience. It was deemed to be safe enough Safe. Enough. > There is more to safety than just being "certified". Acting in ways > that /actually/ improves safety (if you are allowed to) is important. > > This isn't just black and white. Safety, like security, isn't > absolute. Both benefit from defense-in-depth, and both require > compromise to balance safety vs. convenience. Good advice. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From aaron at wholesaleinternet.net Wed Mar 19 17:25:35 2014 From: aaron at wholesaleinternet.net (Aaron) Date: Wed, 19 Mar 2014 12:25:35 -0500 Subject: L6-20P -> L6-30R In-Reply-To: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> Message-ID: <5329D30F.5040906@wholesaleinternet.net> To end the debate, my staff master electrician says just replace the breaker. You can leave the outlet if you want or replace it too. Doesn't matter. The 30A circuit should be 10 gauge which is fine for 20amp. And to Jay: Network cables most certainly do carry power. On 3/19/2014 12:18 PM, Jay Ashworth wrote: > Network cables don't carry power. From bill at herrin.us Wed Mar 19 17:26:54 2014 From: bill at herrin.us (William Herrin) Date: Wed, 19 Mar 2014 13:26:54 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Mar 19, 2014 at 1:18 PM, Jay Ashworth wrote: >> From: "William Herrin" >> Yet an 18 awg PC power cable is perfectly safe when plugged in to a >> 5-20R on a circuit with a 20 amp breaker. Get real man. > > A PC isn't a power distribution device. There are no power cords coming from the power supply that the PC power cable plugs in to? >> The modification cancels the UL certification. If you have an external >> requirement to use only UL certified components then you can't make >> any modifications no matter how obviously safe they are. > > UL doesn't "certify" items. It "lists" them. http://www.ul.com/global/eng/pages/solutions/services/certification/ >> By the way, you either don't have that requirement or you're breaking >> it. Your custom network cables are not UL certified. > > Network cables don't carry power. The 802.3af voip phone on my desk must be powered by magic. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alex at corp.nac.net Wed Mar 19 17:38:09 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 19 Mar 2014 13:38:09 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <5329D30F.5040906@wholesaleinternet.net> References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> <5329D30F.5040906@wholesaleinternet.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094DB40@EXCHMBX.hq.nac.net> Just because you say the debate should be ended doesn't mean it's true, or that you are even correct. > To end the debate, my staff master electrician says just replace the breaker. Your staff electrician missed half the answer, which would be to replace the breaker AND the receptacle. But you make sound as if the OP has that option readily available to him, and it's doesn't answer is original question. > You can leave the outlet if you want or replace it too. Really, a mismatched outlet on a breaker size not intended for it? That seems like a good idea. > Doesn't matter. The 30A circuit should be 10 gauge which is fine for 20amp. That part is correct. > And to Jay: Network cables most certainly do carry power. No, they carry signal, which is considerably different - unless of course it is 802.1af. From jra at baylink.com Wed Mar 19 17:55:12 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Mar 2014 13:55:12 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> Message-ID: <47645109-ed24-4c93-b2cb-8570278530f2@email.android.com> Fair point. PoE is 48V and current limited, though, precisely to keep it what the Code calls Low Voltage. On March 19, 2014 1:26:54 PM EDT, William Herrin wrote: >On Wed, Mar 19, 2014 at 1:18 PM, Jay Ashworth wrote: >>> From: "William Herrin" >>> Yet an 18 awg PC power cable is perfectly safe when plugged in to a >>> 5-20R on a circuit with a 20 amp breaker. Get real man. >> >> A PC isn't a power distribution device. > >There are no power cords coming from the power supply that the PC >power cable plugs in to? > > > >>> The modification cancels the UL certification. If you have an >external >>> requirement to use only UL certified components then you can't make >>> any modifications no matter how obviously safe they are. >> >> UL doesn't "certify" items. It "lists" them. > >http://www.ul.com/global/eng/pages/solutions/services/certification/ > > > >>> By the way, you either don't have that requirement or you're >breaking >>> it. Your custom network cables are not UL certified. >> >> Network cables don't carry power. > >The 802.3af voip phone on my desk must be powered by magic. > > >Regards, >Bill Herrin > > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From bill at herrin.us Wed Mar 19 18:05:42 2014 From: bill at herrin.us (William Herrin) Date: Wed, 19 Mar 2014 14:05:42 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <47645109-ed24-4c93-b2cb-8570278530f2@email.android.com> References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> <47645109-ed24-4c93-b2cb-8570278530f2@email.android.com> Message-ID: On Wed, Mar 19, 2014 at 1:55 PM, Jay Ashworth wrote: > PoE is 48V and current limited, though, precisely to keep it what the Code > calls Low Voltage. Hi Jay, 50 watts DC. It won't electrocute you (that's AC) but it's the same power that makes a 40 watt bulb burning hot. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lowen at pari.edu Wed Mar 19 18:12:36 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 19 Mar 2014 14:12:36 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <5329DE14.9040305@pari.edu> [Whee. This discussion is good for me, as I need to refresh my memory on the relevant code sections for some new data center clients.....thanks, Bill, you're a great help!] On 03/19/2014 12:24 PM, William Herrin wrote: > Yet an 18 awg PC power cable is perfectly safe when plugged in to a > 5-20R on a circuit with a 20 amp breaker. Get real man. The NFPA thinks so. They also allow interoperability between a 20A T-slot receptacle and a 15A plug (so that a 2-15P can work in a T-slot 2-20R, or a 5-15P can work in a 5-20R, etc). Things are different above 20A, at least in the NFPA's view. NFPA 75 is interesting reading, especially in those sections where its committee and the NFPA 70 committee seem to see things differently. However, my SOP is to use no smaller than 16AWG for a 5-15P or 6-15P (with a 14AWG preference), and no smaller than 12AWG for 20A use, etc, unless protected by suitable overcurrent devices (for 18AWG, that's 7A, and for 16AWG that's 10A, so a power strip with a 10A breaker or a PDU with a individual 10A breakers is fine for use with 16AWG power cords). I do have an EE background and degree, and so I do tend to be very conservative in those things. I have seen the results of pinched 18AWG zipcord in a 5-15R, and it's not pretty. The 22AWG Christmas lights get away with it by having overcurrent protection in the plugs. > You got two things right: The NEC (and related fire codes) don't apply > to supply cords of appliances in circumstances such as OP's PDU. The > modification cancels the UL certification. If you have an external > requirement to use only UL certified components then you can't make > any modifications no matter how obviously safe they are.By the way, > you either don't have that requirement or you're breaking it. Your > custom network cables are not UL certified. Here's the bottom line, at least in my data centers: if it could be considered questionable by the insurers (that's where UL got its start) then it's not likely to happen. Modifying a piece of utilization equipment with a UL QPQY listing is likely to be considered questionable. Now, network cable installation is covered by the NEC in article 800, which got some revisions in 2011, and the class 2 and class 3 cables used are also covered, in articles 725 (fiber is covered by article 770, and ITE rooms by article 645). The major theme there is reduction in spread of products of combustion, and the UL DUZX listing reflects that purpose. Yes, listed cables are required by code when part of the premises wiring, but putting a listed connector on listed cable is within the listing. Further, 802.3af and even 802.3at are considered Class 2 power limited sources under article 725 of the NEC (that is, there's not enough available power to initiate combustion). So, sure, I can still use custom network cabling and stay within using only listed items. From cra at WPI.EDU Wed Mar 19 18:19:10 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 19 Mar 2014 14:19:10 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> <47645109-ed24-4c93-b2cb-8570278530f2@email.android.com> Message-ID: <20140319181909.GE7867@angus.ind.WPI.EDU> On Wed, Mar 19, 2014 at 02:05:42PM -0400, William Herrin wrote: > On Wed, Mar 19, 2014 at 1:55 PM, Jay Ashworth wrote: > > PoE is 48V and current limited, though, precisely to keep it what the Code > > calls Low Voltage. > > Hi Jay, > > 50 watts DC. It won't electrocute you (that's AC) but it's the same > power that makes a 40 watt bulb burning hot. I don't know where you are getting your facts, but 802.3af maxes out at 15.4W and 802.3at at 34.2W, and DC can electrocute you just as well as AC. http://en.wikipedia.org/wiki/Power_over_Ethernet#Standard_implementation From lowen at pari.edu Wed Mar 19 18:27:38 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 19 Mar 2014 14:27:38 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: Message-ID: <5329E19A.5080201@pari.edu> On 03/19/2014 02:05 PM, William Herrin wrote: > 50 watts DC. It won't electrocute you (that's AC) but it's the same > power that makes a 40 watt bulb burning hot. 802.3af is limited to 15.4W, and 802.3at to 25.5W. The limits for Class 2 and 3 circuits are found in Chapter 9, Table 11 (A and B), of the NEC (Table 11(B) for DC circuits, and for a power source of 30 to 60 volts a Class 2 circuit can have, for a 44VDC supply power, up to 3.4A available (a max nameplate rating of 100VA). For AC, Table 11(A) tells me that a 120VAC circuit, to meet Class 2, must be current-limited to 5mA. BICSI has a good set of slides on the NEC at http://www.bicsi.org/uploadedfiles/Conference_Websites/Winter_Conference/2012/presentations/Interpreting%20the%20National%20Electrical%20Code.pdf From bill at herrin.us Wed Mar 19 18:30:22 2014 From: bill at herrin.us (William Herrin) Date: Wed, 19 Mar 2014 14:30:22 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <20140319181909.GE7867@angus.ind.WPI.EDU> References: <5116905.12125.1395249499718.JavaMail.root@benjamin.baylink.com> <47645109-ed24-4c93-b2cb-8570278530f2@email.android.com> <20140319181909.GE7867@angus.ind.WPI.EDU> Message-ID: On Wed, Mar 19, 2014 at 2:19 PM, Chuck Anderson wrote: > On Wed, Mar 19, 2014 at 02:05:42PM -0400, William Herrin wrote: >> 50 watts DC. It won't electrocute you (that's AC) but it's the same >> power that makes a 40 watt bulb burning hot. > > I don't know where you are getting your facts, but 802.3af maxes out > at 15.4W and 802.3at at 34.2W, and DC can electrocute you just as well > as AC. > > http://en.wikipedia.org/wiki/Power_over_Ethernet#Standard_implementation Hi Chuck, Same article where you got your facts: "Up to a theoretical 51 watts is available for a device." Though technically it's newer PoE standards than AF which hit 51 watts. Electrocution is a heart attack induced when alternating current disrupts the heart's normal sinus rhythm. DC can burn you but it won't disrupt your heart rhythm, hence it won't electrocute you. That was the basis Edison's theater with the electric chair when he argued against the safety of Tesla's AC current. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Wed Mar 19 19:00:23 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Mar 2014 15:00:23 -0400 Subject: =?UTF-8?Q?Level_3_blames_Internet_slowdowns_on_ISPs=E2=80=99?= =?UTF-8?Q?_refusal_to_upgrade_networks_=7C_Ars_Technica?= Message-ID: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> L3 escalates on Peering/CDN/Neutrality. http://arstechnica.com/information-technology/2014/03/level-3-blames-internet-slowdowns-on-isps-refusal-to-upgrade-networks/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From patrick at ianai.net Wed Mar 19 19:06:47 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 19 Mar 2014 15:06:47 -0400 Subject: =?utf-8?Q?Re:_Level_3_blames_Internet_slowdowns_on_ISPs=E2=80=99?= =?utf-8?Q?_refusal_to_upgrade_networks_|_Ars_Technica?= In-Reply-To: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> Message-ID: <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> On Mar 19, 2014, at 15:00, Jay Ashworth wrote: > > L3 escalates on Peering/CDN/Neutrality. > > http://arstechnica.com/information-technology/2014/03/level-3-blames-internet-slowdowns-on-isps-refusal-to-upgrade-networks/ The devil on my left shoulder wants to laugh at L3 for their hypocrisy. The angle on my right shoulder wants to congratulate a "tier one" (whatever the F that means) provider for finally admitting, in writing, in public, from a lawyer, what the rest of us have known for decades. In the middle is me being afraid of the gov't actually regulating something that _is_ a problem, but because they are the gov't, doing it in a way that will cause more issues than it solves. :-( -- TTFN, patrick From nick at wiredmedium.com Wed Mar 19 15:03:37 2014 From: nick at wiredmedium.com (Nick) Date: Wed, 19 Mar 2014 10:03:37 -0500 Subject: Customer Support Ticketing In-Reply-To: References: Message-ID: <5329B1C9.4070202@wiredmedium.com> Paul, My past two job, I used Kayako. I like it so much I bought a copy for my side project. I feel work flow with kayako is will thought out for tech minded people. Having easy access to staff notes while still able to see the ticket is a big deal for me. Its someway easy to customize allowing you to pull extra info about the customer into the ticket. At my current day job. We use OTRS and are working to replace it. I think its worthless support system with a painful work flow. with poorly labeled options call Zoom and other stuff. For our replacement, we are looking at Kana, Parature, eGain and Oracle. Oracle is over price($300K). eGain was cut for some reason. Right now Kana and Parature are the two front runners but im not sold. When looking at a support system. Get you front end support team involved from the start. In some cases manager dont know the true work flow of there support staff. Anyway, Go with Kayako. You will love it. Nick Poulakos wiredmedium On 3/19/2014 9:01 AM, Paul Stewart wrote: > Hey folks?. > > We need a new customer ticketing system and I?m looking for input. I am > still working on a scope document on everything we want to do with the new > system. > > The most common problem I run across is that a system is either built for > enterprise internal IT helpdesk or it is built like a CRM sales tracking > system. We are an ISP among other things and are looking for a powerful and > yet reasonable cost system to answer email inquiries, allow customers to > open tickets via portal, mobile support, escalation/SLA support, and several > other things. Solarwinds NPM integration would be a huge bonus but not a > deal breaker. If anyone has a system that they have integrated with Ivue > from NISC (our billing platform) I would be really interested in hearing > more as well. > > So my question is meant high level. For those folks that are ISP?s > supporting business customers (including managed customers) along with > residential eyeball traffic what system(s) do you use and what do you > like/dislike? > > I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, > ZenDesk, HappyFox, Kayako and several others. All of them so far would > require a fair amount of configuration or modifications based on our still > developing wish list. Also worth noting is that we have no full time > development staff so hoping to find something that has a lot of promise and > then work with the vendor to evolve it into what we feel we need. > > **This is not an invitation for sales folks to call on me** > > Thanks, > > Paul > > > > From clane1875 at gmail.com Wed Mar 19 15:03:01 2014 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 19 Mar 2014 11:03:01 -0400 Subject: Customer Support Ticketing In-Reply-To: References: Message-ID: Hey paul We use Netsuite with OpenNms ~ as an ISP i think you will always be stuck with alot of customization ~ unless you build your own Good luck Chris On Wed, Mar 19, 2014 at 10:01 AM, Paul Stewart wrote: > Hey folks.... > > We need a new customer ticketing system and I'm looking for input. I am > still working on a scope document on everything we want to do with the new > system. > > The most common problem I run across is that a system is either built for > enterprise internal IT helpdesk or it is built like a CRM sales tracking > system. We are an ISP among other things and are looking for a powerful > and > yet reasonable cost system to answer email inquiries, allow customers to > open tickets via portal, mobile support, escalation/SLA support, and > several > other things. Solarwinds NPM integration would be a huge bonus but not a > deal breaker. If anyone has a system that they have integrated with Ivue > from NISC (our billing platform) I would be really interested in hearing > more as well. > > So my question is meant high level. For those folks that are ISP's > supporting business customers (including managed customers) along with > residential eyeball traffic what system(s) do you use and what do you > like/dislike? > > I've looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, > ZenDesk, HappyFox, Kayako and several others. All of them so far would > require a fair amount of configuration or modifications based on our still > developing wish list. Also worth noting is that we have no full time > development staff so hoping to find something that has a lot of promise and > then work with the vendor to evolve it into what we feel we need. > > **This is not an invitation for sales folks to call on me** > > Thanks, > > Paul > > > > > -- //CL Quis custodiet ipsos custodes From sethm at rollernet.us Wed Mar 19 21:51:54 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 19 Mar 2014 14:51:54 -0700 Subject: L6-20P -> L6-30R In-Reply-To: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> Message-ID: <532A117A.3050001@rollernet.us> On 3/19/14, 10:21, Jay Ashworth wrote: > It is exactly that: no one says you*can't* wire a 20A branch circuit with > #10. > > It is even*possible*, though unlikely, that if you did so, you wouldn't > have to derate it to 80%. I would have to reread the Code to be sure. Well, I'd say it's pretty likely. However highly unlikely to be code-worthy of slapping on a 30A breaker in place of a 20. 10-20 CCCs in a raceway or cable is a 50% derating, so if those conductors were for 20A branch circuits it would have to be 10AWG, not 12 since with 10AWG you're derating from 40A. But the max protective device on 10AWG is 30A unless permitted by 240.4. Even 7-9 CCCs in a raceway or cable derates 10AWG to 28A (70%), so while still suitable for a 20A breaker it's not for 30A. Max would be 6 CCCs to stay at 80% derating (4-6 CCCs). ~Seth From nrollo at kw-corp.com Wed Mar 19 22:14:15 2014 From: nrollo at kw-corp.com (Nolan Rollo) Date: Wed, 19 Mar 2014 22:14:15 +0000 Subject: Customer Support Ticketing In-Reply-To: References: Message-ID: <37184583d9f847ce8d22bc9e0f60ab8e@KWMAIL.local.kw-corp.com> For what it's worth, I've actually heard the Intuit guys that sell Quickbase will build and customize your ticketing system for you. I haven't looked that heavily into other options since I've run a few RT instances I'm most comfortable there but I'm sure you know it doesn't integrate with other applications well unless you're a perl dev -----Original Message----- From: Paul Stewart [mailto:paul at paulstewart.org] Sent: Wednesday, March 19, 2014 10:01 AM To: nanog at nanog.org Subject: Customer Support Ticketing Hey folks?. We need a new customer ticketing system and I?m looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP?s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul From Ray.Sanders at sheknows.com Wed Mar 19 22:27:21 2014 From: Ray.Sanders at sheknows.com (Ray Sanders) Date: Wed, 19 Mar 2014 22:27:21 +0000 Subject: Customer Support Ticketing In-Reply-To: <37184583d9f847ce8d22bc9e0f60ab8e@KWMAIL.local.kw-corp.com> References: , <37184583d9f847ce8d22bc9e0f60ab8e@KWMAIL.local.kw-corp.com> Message-ID: <4b51c512933d4731b755e1bd160e9fa9@BN1PR05MB233.namprd05.prod.outlook.com> Another +1/like/upvote for Kayako. RAY SANDERS Senior Systems Engineer ray.sanders at sheknows.com ________________________________________ From: Nolan Rollo Sent: Wednesday, March 19, 2014 3:14 PM To: Paul Stewart; nanog at nanog.org Subject: RE: Customer Support Ticketing For what it's worth, I've actually heard the Intuit guys that sell Quickbase will build and customize your ticketing system for you. I haven't looked that heavily into other options since I've run a few RT instances I'm most comfortable there but I'm sure you know it doesn't integrate with other applications well unless you're a perl dev -----Original Message----- From: Paul Stewart [mailto:paul at paulstewart.org] Sent: Wednesday, March 19, 2014 10:01 AM To: nanog at nanog.org Subject: Customer Support Ticketing Hey folks?. We need a new customer ticketing system and I?m looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP?s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul From rs at seastrom.com Wed Mar 19 22:33:18 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 19 Mar 2014 18:33:18 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Wed, 19 Mar 2014 13:21:05 -0400 (EDT)") References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> Message-ID: <86vbv97r9t.fsf@valhalla.seastrom.com> Jay Ashworth writes: > It is exactly that: no one says you *can't* wire a 20A branch circuit with > #10. > > It is even *possible*, though unlikely, that if you did so, you wouldn't > have to derate it to 80%. I would have to reread the Code to be sure. It's not the conductor that you're derating; it's the breaker. Per NEC Table 310.16, ampacity of #12 copper THHN/THWN2 (which is almost certainly what you're pulling) with 3 conductors in a conduit is 30 amps. Refer to Table 310.15(B)(2)(a) for derating of more than 3 current-carrying conductors in a conduit. 4-6 is 80%, 7-9 is 70%. Plenty good for 20 amps for any conceivable number of conductors in a datacenter whip. Thermal breakers are typically deployed in an 80% application for continuous loads, per NEC 384-16(c). See the references to 125% of continuous load, which of course is the reciprocal of 80%. http://cliffordpower.com/wp/wp-content/uploads/2010/08/CPS_info_sheet_37_CB_80_versus_100.pdf -r From jlk at thrashyour.com Wed Mar 19 22:39:10 2014 From: jlk at thrashyour.com (John Kinsella) Date: Wed, 19 Mar 2014 15:39:10 -0700 Subject: Customer Support Ticketing In-Reply-To: <37184583d9f847ce8d22bc9e0f60ab8e@KWMAIL.local.kw-corp.com> References: <37184583d9f847ce8d22bc9e0f60ab8e@KWMAIL.local.kw-corp.com> Message-ID: I saw mention of Quckbase and wanted to chime in?I spent some time consulting inside Intuit a few years ago, and my oh my they sure eat their dog food on QuickBase. It?s crazy flexible - easy learning curve for basic use, and the scripting language allows for some crazy creative tricks to accomplish things you wouldn?t expect. If you wanted to do something really customized, it might do the trick. Otherwise, I suspect you?re rebuilding the wheel. We (Stratosec) are happily using Zendesk, but I do eye Kayako from time to time... John On Mar 19, 2014, at 3:14 PM, Nolan Rollo wrote: > For what it's worth, I've actually heard the Intuit guys that sell Quickbase will build and customize your ticketing system for you. I haven't looked that heavily into other options since I've run a few RT instances I'm most comfortable there but I'm sure you know it doesn't integrate with other applications well unless you're a perl dev > > -----Original Message----- > From: Paul Stewart [mailto:paul at paulstewart.org] > Sent: Wednesday, March 19, 2014 10:01 AM > To: nanog at nanog.org > Subject: Customer Support Ticketing > > Hey folks?. > > We need a new customer ticketing system and I?m looking for input. I am still working on a scope document on everything we want to do with the new system. > > The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. > > So my question is meant high level. For those folks that are ISP?s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? > > I?ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. > > **This is not an invitation for sales folks to call on me** > > Thanks, > > Paul > > > > From LarrySheldon at cox.net Wed Mar 19 22:58:14 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 19 Mar 2014 17:58:14 -0500 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <20140318225247.GA83805@wakko.typo.org> <20140318225422.GA36211@burnout.tpb.net> <2D0AF14BA6FB334988BC1F5D4FC38CB843A094D968@EXCHMBX.hq.nac.net> <86mwgm1kyq.fsf@valhalla.seastrom.com> Message-ID: <532A2106.6070605@cox.net> On 3/19/2014 7:00 AM, Alex Rubenstein wrote: >>> Go look at any standard household lamp. It has a 5-15P on the end of >>> it, which could be plugged into an outlet rated for 20 amps (5-20R), >>> with 16 gauge lamp cord rated for 10 amps or less. >> >> Mine all seem to be NEMA 1-15P, some (most?) with 18 AWG wire. >> >> Have I been shortchanged? :) > > I wrote that too fast, you are absolutely right. > > But my point remains. Appliance/load wire size is often, and many times smaller than the ampacity of the circuit. > > Heck, how many times have you plugged in a 14 gauge extension cord to a 5-20R? I believe the thinking behind the standards is that the breaker is sized to protect the wiring to the receptacle or fixture. After that you are on your own. It is always safe to demand less current than the circuit is designed to provide. It is never save to deform connectors. Changing a receptacle to one of a lower capacity is safe, if confusing to those who follow you. If I operated a facility I would offer short adapters cords rather that changing the receptacle. > > > > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jra at baylink.com Thu Mar 20 02:54:07 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Mar 2014 22:54:07 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB843A094DB40@EXCHMBX.hq.nac.net> Message-ID: <16525372.12151.1395284047643.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Alex Rubenstein" > > And to Jay: Network cables most certainly do carry power. > > No, they carry signal, which is considerably different - unless of > course it is 802.1af. That's what he meant, yes, and a couple other people made the point as well. 1af is 48VDC *precisely* to make it remain Low Voltage, which takes it outside the realm of NEC[1], and hence, UL. Cheers, -- jra [1] Yes, yes, except section 800. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Thu Mar 20 03:00:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Mar 2014 23:00:05 -0400 (EDT) Subject: L6-20P -> L6-30R In-Reply-To: <532A117A.3050001@rollernet.us> Message-ID: <9529656.12153.1395284405359.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Seth Mattinen" > On 3/19/14, 10:21, Jay Ashworth wrote: > > It is exactly that: no one says you*can't* wire a 20A branch circuit > > with #10. > > > > It is even*possible*, though unlikely, that if you did so, you wouldn't > > have to derate it to 80%. I would have to reread the Code to be sure. > > Well, I'd say it's pretty likely. However highly unlikely to be > code-worthy of slapping on a 30A breaker in place of a 20. Well, the situation were were discussing was replacing 30A CB <--> 10 AWG <--> L6-30 with 20A CB <--> 10 AWG <--> L6-20 and as I was reminded, you'd still have to derate that unless the CB was magnetic. And you can't leave the breaker at 30, cause then the attached 20A single device isn't protected properly by it. So I was worng on the derating. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From tom at ninjabadger.net Thu Mar 20 12:22:58 2014 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 20 Mar 2014 12:22:58 +0000 Subject: open source with flowspec =?UTF-8?Q?=3F?= In-Reply-To: <53223B86.3070703@bogus.com> References: <5322345C.6030708@interia.pl> <53223B86.3070703@bogus.com> Message-ID: <915f76fd2f79629b53d6ca9f36c8945e@ninjabadger.net> On 2014-03-13 23:13, joel jaeggli wrote: > exabgp from ripe labs can inject flowspec routes. You mean from Exa Networks[1], not RIPE: https://github.com/Exa-Networks/exabgp Tom [1] http://www.exa.net.uk/ From mark.tinka at seacom.mu Thu Mar 20 12:39:59 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Mar 2014 14:39:59 +0200 Subject: Level 3 blames Internet slowdowns on =?utf-8?q?ISPs=E2=80=99_refusal_to_upgrade_networks_=7C_Ars?= Technica In-Reply-To: <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> Message-ID: <201403201439.59967.mark.tinka@seacom.mu> On Wednesday, March 19, 2014 09:06:47 PM Patrick W. Gilmore wrote: > The angle on my right shoulder wants to congratulate a > "tier one" (whatever the F that means) provider for > finally admitting, in writing, in public, from a lawyer, > what the rest of us have known for decades. Every time the market has troubled the status quo, networks have failed to find ways that adapt to that market. The market ends up working around the network. Napster and all the goodness that followed it, is one such example; until iTunes adapted. And yes, iTunes is NOT the network. Now the OTT's are driving the network hard, and the network des not want to adapt (perhaps calling in the FCC is adapting... not). So expect the market to work around this as well. The network keeps getting left behind... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From blake at ispn.net Thu Mar 20 14:16:26 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 20 Mar 2014 09:16:26 -0500 Subject: Level 3 blames Internet slowdowns on =?UTF-8?B?SVNQc+KAmSByZQ==?= =?UTF-8?B?ZnVzYWwgdG8gdXBncmFkZSBuZXR3b3JrcyB8IEFycyBUZWNobmljYQ==?= In-Reply-To: <201403201439.59967.mark.tinka@seacom.mu> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> <201403201439.59967.mark.tinka@seacom.mu> Message-ID: <532AF83A.8010805@ispn.net> Mark Tinka wrote the following on 3/20/2014 7:39 AM: > On Wednesday, March 19, 2014 09:06:47 PM Patrick W. Gilmore > wrote: > >> The angle on my right shoulder wants to congratulate a >> "tier one" (whatever the F that means) provider for >> finally admitting, in writing, in public, from a lawyer, >> what the rest of us have known for decades. > Every time the market has troubled the status quo, networks > have failed to find ways that adapt to that market. The > market ends up working around the network. > > Napster and all the goodness that followed it, is one such > example; until iTunes adapted. And yes, iTunes is NOT the > network. > > Now the OTT's are driving the network hard, and the network > des not want to adapt (perhaps calling in the FCC is > adapting... not). > > So expect the market to work around this as well. The > network keeps getting left behind... > > Mark. I don't see this as a technical problem, but one of business and ethics. ISP X advertises/sells customers "up to 8Mbps" (as an example), but when it comes to delivering that product, they've only guaranteed 512Kbps (if any) because the ISP hasn't put in the infrastructure to support 8Mbps per customer. Customer believes he/she has 8Mbps, Content provider says we provide 8Mbps content, but ISP can (theoretically and in practice) only deliver a fraction of that. That feels like false advertising to me. One can reasonably make the argument that not all of ISP X's customers are using the service simultaneously, so the infrastructure to support 8Mbps per customer is unnecessary and unjustified. However, if past experience proves that 25% of business X's customers are consistently using the service simultaneously and business X has NOT put in the infrastructure to support this common level of usage, then this appears to be a simple financial decision to advertise/sell something that the business knows it cannot deliver. Would the same business practices fly in other fields? Perhaps. Airlines overbook, knowing that some customers won't show up. However, they don't sell 200 tickets (knowing that 90% if customers will show) but have only 100 seats to serve the 180 customers they expect. Fast food restaurants don't sell you a fry and drink when they know they're out of fries. I can speculate that customers would not patronize companies in the travel or food industry if they operated the same way that some ISP's operate. The difference, to me, seems to be that ISPs often enjoy a monopoly while there are usually several food and travel options in most places. --Blake From patrick at ianai.net Thu Mar 20 14:18:59 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 20 Mar 2014 10:18:59 -0400 Subject: =?windows-1252?Q?Re=3A_Level_3_blames_Internet_slowdowns_on__ISP?= =?windows-1252?Q?s=92_refusal_to_upgrade_networks_=7C_Ars_Techni?= =?windows-1252?Q?ca?= In-Reply-To: <201403201439.59967.mark.tinka@seacom.mu> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> <201403201439.59967.mark.tinka@seacom.mu> Message-ID: On Mar 20, 2014, at 08:39 , Mark Tinka wrote: > On Wednesday, March 19, 2014 09:06:47 PM Patrick W. Gilmore wrote: >> The angle on my right shoulder wants to congratulate a >> "tier one" (whatever the F that means) provider for >> finally admitting, in writing, in public, from a lawyer, >> what the rest of us have known for decades. > > Every time the market has troubled the status quo, networks > have failed to find ways that adapt to that market. The > market ends up working around the network. > > Napster and all the goodness that followed it, is one such > example; until iTunes adapted. And yes, iTunes is NOT the > network. > > Now the OTT's are driving the network hard, and the network > des not want to adapt (perhaps calling in the FCC is > adapting... not). > > So expect the market to work around this as well. The > network keeps getting left behind... "The market" can only "work around" things if there is a functioning market. Monopolies are not a functioning market. There will be a solution - in fact, there is today. Doesn't mean it is optimal. In fact, in the presence of a monopoly, it is pretty much guaranteed to be sub-optimal. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lowen at pari.edu Thu Mar 20 15:05:35 2014 From: lowen at pari.edu (Lamar Owen) Date: Thu, 20 Mar 2014 11:05:35 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <86vbv97r9t.fsf@valhalla.seastrom.com> References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> Message-ID: <532B03BF.9070906@pari.edu> On 03/19/2014 06:33 PM, Rob Seastrom wrote: > It's not the conductor that you're derating; it's the breaker. Per NEC > Table 310.16, ampacity of #12 copper THHN/THWN2 (which is almost > certainly what you're pulling) with 3 conductors in a conduit is 30 > amps. Refer to Table 310.15(B)(2)(a) for derating of more than 3 > current-carrying conductors in a conduit. 4-6 is 80%, 7-9 is 70%. > Plenty good for 20 amps for any conceivable number of conductors in a > datacenter whip. Thermal breakers are typically deployed in an 80% > application for continuous loads, per NEC 384-16(c). See the > references to 125% of continuous load, which of course is the > reciprocal of 80%. Actually, there is no NEC 384.16 any more, at least in the 2011 code. The current relevent, perhaps even replacement, article seems to be the exception listed to article 210.20(A). Now, 210.21(B)(2) indicates that, for each individual receptacle on a multi-receptacle, the total cord and plug connected load cannot be above certain values (which are 80% of the branch circuit rating for 15, 20, and 30A circuits) regardless of overcurrent protection device rating. If you have a 100% rated overcurrent device you could connect a total load on multiple receptacles beyond 80%, it appears. While 210.21(B)(1) requires receptacles on single-receptacle branch circuits to be rated for the full load, any one piece of utilization equipment on a 20A or 30A branch circuit cannot be rated to draw more than 80% of the branch circuit's rating (210.23(A)(1) for 20A, 210.23(B) for 30A). So even if you have a single receptacle on the branch circuit you can't have any single piece of equipment use 100% continuously. The idea is to give the branch circuit some 'headroom;' in the ideal world, we don't load networking links past a certain percentage, depending on link technology, for similar reasons. Tracking code changes fuels an entire industry, and several websites..... :-) Not to mention continuing education and license renewals for electricians..... and headaches for those who think they understand the code but then get a surprise at inspection time (been there, done that, go the t-shirt and the NEC Handbook so I'll halfway know what I'm talking about when dealing with these things.....) A new NEC Handbook is in my budget every three years due to the substantial changes that are made by the committees. The physics of electricity don't change, but our understanding of those physics and our ideas about how to deal safely with electricity do. And what is allowable and available can change in a moment; I'm still a bit puzzled how the L6-30P to L6-20R adapters can actually be on the market in the first place, given that they can easily create an unsafe condition. Well, I'm puzzled from a technical viewpoint, but not from a marketing viewpoint.....if it makes money, it is marketable, until pulled or recalled..... From rs at seastrom.com Thu Mar 20 16:00:28 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 20 Mar 2014 12:00:28 -0400 Subject: L6-20P -> L6-30R In-Reply-To: <532B03BF.9070906@pari.edu> (Lamar Owen's message of "Thu, 20 Mar 2014 11:05:35 -0400") References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> <86vbv97r9t.fsf@valhalla.seastrom.com> <532B03BF.9070906@pari.edu> Message-ID: <86ob10x3kz.fsf@valhalla.seastrom.com> Lamar Owen writes: > Actually, there is no NEC 384.16 any more, at least in the 2011 code. Guilty. I reflexively reached for my 2008 copy since that's the code of record here where I live. Glad we're not on 2011, wish we were still on 2005; a lot of stupidity has crept in since then. Tamper-resistant receptacles required in the unfinished basement shop? *really*? -r From mark.tinka at seacom.mu Thu Mar 20 16:03:41 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Mar 2014 18:03:41 +0200 Subject: Level 3 blames Internet slowdowns on =?utf-8?q?ISPs=E2=80=99_refusal_to_upgrade_networks_=7C_Ars?= Technica In-Reply-To: <532AF83A.8010805@ispn.net> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <532AF83A.8010805@ispn.net> Message-ID: <201403201803.44249.mark.tinka@seacom.mu> On Thursday, March 20, 2014 04:16:26 PM Blake Hudson wrote: > I don't see this as a technical problem, but one of > business and ethics. ISP X advertises/sells customers > "up to 8Mbps" (as an example), but when it comes to > delivering that product, they've only guaranteed 512Kbps > (if any) because the ISP hasn't put in the > infrastructure to support 8Mbps per customer. Customer > believes he/she has 8Mbps, Content provider says we > provide 8Mbps content, but ISP can (theoretically and in > practice) only deliver a fraction of that. That feels > like false advertising to me. > > One can reasonably make the argument that not all of ISP > X's customers are using the service simultaneously, so > the infrastructure to support 8Mbps per customer is > unnecessary and unjustified. However, if past experience > proves that 25% of business X's customers are > consistently using the service simultaneously and > business X has NOT put in the infrastructure to support > this common level of usage, then this appears to be a > simple financial decision to advertise/sell something > that the business knows it cannot deliver. Would the > same business practices fly in other fields? Perhaps. > Airlines overbook, knowing that some customers won't > show up. However, they don't sell 200 tickets (knowing > that 90% if customers will show) but have only 100 seats > to serve the 180 customers they expect. Fast food > restaurants don't sell you a fry and drink when they > know they're out of fries. I can speculate that > customers would not patronize companies in the travel or > food industry if they operated the same way that some > ISP's operate. The difference, to me, seems to be that > ISPs often enjoy a monopoly while there are usually > several food and travel options in most places. Completely agree. What I'm saying is the market is now suggesting that the idea that I won't be using my 8Mbps all the time does not hold as true now as it did ten years ago. A lot of the content is being driven from the homes (symmetric bandwidth being driven by FTTH). And while customers are not online 100% of the time, they are more online now than they were ten years ago. So building the network just enough for what you over-advertise isn't a workable strategy. Will it stop? Unlikely... Now the market is saying, "I want Netflix and all its cousins" on a consistent basis, or at least, during prime viewing. And the network is failing to deliver this because the network is set in its ways. I'm not yet sure what the solution will be (looking at a global scale, not just North America), but I hazard that it might not involve the network, in the way it does today, unless the network can figure out how to make this work with happiness all around. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Mar 20 16:05:22 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Mar 2014 18:05:22 +0200 Subject: Level 3 blames Internet slowdowns on =?utf-8?q?ISPs=E2=80=99_refusal_to_upgrade_networks_=7C_Ars?= Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> Message-ID: <201403201805.22911.mark.tinka@seacom.mu> On Thursday, March 20, 2014 04:18:59 PM Patrick W. Gilmore wrote: > "The market" can only "work around" things if there is a > functioning market. Monopolies are not a functioning > market. When did we ever have a "functioning market", even in markets that are considered "liberalized" :-)? It is what it is - it's just less bad in some places than others. > There will be a solution - in fact, there is today. > Doesn't mean it is optimal. In fact, in the presence of > a monopoly, it is pretty much guaranteed to be > sub-optimal. Aye. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From gary.buhrmaster at gmail.com Thu Mar 20 16:27:30 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 20 Mar 2014 16:27:30 +0000 Subject: L6-20P -> L6-30R In-Reply-To: <86ob10x3kz.fsf@valhalla.seastrom.com> References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> <86vbv97r9t.fsf@valhalla.seastrom.com> <532B03BF.9070906@pari.edu> <86ob10x3kz.fsf@valhalla.seastrom.com> Message-ID: On Thu, Mar 20, 2014 at 4:00 PM, Rob Seastrom wrote: > > Lamar Owen writes: > >> Actually, there is no NEC 384.16 any more, at least in the 2011 code. > > Guilty. I reflexively reached for my 2008 copy since that's the code > of record here where I live. Glad we're not on 2011, wish we were > still on 2005; a lot of stupidity has crept in since then. Tamper-resistant > receptacles required in the unfinished basement shop? *really*? "Think of the children!" I hear the 2017 edition of NFPA 70 (aka NEC) may require one to turn off the power to the entire household in order to plug in a coffee maker to minimize potential arc flash hazard.... (just kidding). Gary From blake at ispn.net Thu Mar 20 16:34:06 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 20 Mar 2014 11:34:06 -0500 Subject: Level 3 blames Internet slowdowns on =?UTF-8?B?SVNQc+KAmSByZQ==?= =?UTF-8?B?ZnVzYWwgdG8gdXBncmFkZSBuZXR3b3JrcyB8IEFycyBUZWNobmljYQ==?= In-Reply-To: <201403201805.22911.mark.tinka@seacom.mu> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: <532B187E.7090009@ispn.net> Mark Tinka wrote the following on 3/20/2014 11:05 AM: > On Thursday, March 20, 2014 04:18:59 PM Patrick W. Gilmore > wrote: > >> "The market" can only "work around" things if there is a >> functioning market. Monopolies are not a functioning >> market. > When did we ever have a "functioning market", even in > markets that are considered "liberalized" :-)? > > It is what it is - it's just less bad in some places than > others. > >> There will be a solution - in fact, there is today. >> Doesn't mean it is optimal. In fact, in the presence of >> a monopoly, it is pretty much guaranteed to be >> sub-optimal. > Aye. > > Mark. It sounds like we're all in agreement that the underlying issue is that some businesses enjoying a monopoly are allowed to design networks for the use case of yesteryear and do not have the market pressure forcing them to provide the use case of today's (or the future's) subscribers. The solution seems to be competition or regulation. The current administration supplied over $7 billion in loans and grants (http://www.wired.com/business/2011/07/rural-fiber-internet/) for internet providers to provide high speed last mile services as part of a Federal stimulus package. This type of encouragement in infrastructure and competition seem much better, to me, than regulation formed to to nanny and punish folks that run their business unfairly. I understand that Comcast, as an example, has a fiduciary duty to its stock holders to make the best return possible. But I would think its recent actions would likely fall foul to basic consumer protection regulation (failing to provide the goods or services it sold). All of Comcast's customers could file a complaint with the BBB, but it probably wouldn't be productive because many of them have no other choice for high speed internet service. As consumers, we may also have to accept that cheap internet access prices were based on the usage case of yesteryear. If we use internet services twice as often today, we may need to pay twice as much as we did yesterday. If we, as consumers, have options, but are choosing to pay for the the bare minimum option, we may as well expect the bare minimum service (which apparently is not very much). As long as we have options, which today is not always true, I think the market will function. This why events like the Comcast/TWC merger are troubling to me. Because it means we are going in the wrong direction, back towards monopoly. Our efforts, at present, are probably best spent encouraging competition and fairness. As a consumer and professional, I sincerely hope that the FCC continues on its trend to support net neutrality because I believe it encourages both competition and fairness. --Blake From bryan at digitalocean.com Thu Mar 20 16:34:32 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 20 Mar 2014 12:34:32 -0400 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <201403201805.22911.mark.tinka@seacom.mu> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: I don't know where everyones traffic goes but level3 and us, nothing. We've dropped all but 1 line which will be gone in 60 days. I don't care what their excuse is, they have been horrible this last 14 months and I'd rather get bw from cogent who isn't great but doesn't blame everyone else for their inability to peer better... A premium cost provider should have premium service and level3 is no longer that. Bryan Socha Network Engineer DigitalOcean 646-450-0472 On Thu, Mar 20, 2014 at 12:05 PM, Mark Tinka wrote: > On Thursday, March 20, 2014 04:18:59 PM Patrick W. Gilmore > wrote: > > > "The market" can only "work around" things if there is a > > functioning market. Monopolies are not a functioning > > market. > > When did we ever have a "functioning market", even in > markets that are considered "liberalized" :-)? > > It is what it is - it's just less bad in some places than > others. > > > There will be a solution - in fact, there is today. > > Doesn't mean it is optimal. In fact, in the presence of > > a monopoly, it is pretty much guaranteed to be > > sub-optimal. > > Aye. > > Mark. > From gary.buhrmaster at gmail.com Thu Mar 20 17:12:02 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 20 Mar 2014 17:12:02 +0000 Subject: L6-20P -> L6-30R In-Reply-To: <532B03BF.9070906@pari.edu> References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> <86vbv97r9t.fsf@valhalla.seastrom.com> <532B03BF.9070906@pari.edu> Message-ID: On Thu, Mar 20, 2014 at 3:05 PM, Lamar Owen wrote: ..... > Tracking code changes fuels an entire industry, and several websites..... > :-) The redline PDF at least makes it (more easily) possible to notice the changes for your evening reading pleasure. From brandon.galbraith at gmail.com Thu Mar 20 17:25:20 2014 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 20 Mar 2014 12:25:20 -0500 Subject: L6-20P -> L6-30R In-Reply-To: References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> <86vbv97r9t.fsf@valhalla.seastrom.com> <532B03BF.9070906@pari.edu> Message-ID: Is it too late to demand code be in open Github repos with changes tracked at no cost? On Thu, Mar 20, 2014 at 12:12 PM, Gary Buhrmaster wrote: > On Thu, Mar 20, 2014 at 3:05 PM, Lamar Owen wrote: > ..... >> Tracking code changes fuels an entire industry, and several websites..... >> :-) > > The redline PDF at least makes it (more easily) possible to notice > the changes for your evening reading pleasure. > From lowen at pari.edu Thu Mar 20 19:40:07 2014 From: lowen at pari.edu (Lamar Owen) Date: Thu, 20 Mar 2014 15:40:07 -0400 Subject: L6-20P -> L6-30R In-Reply-To: References: <21771767.12127.1395249665075.JavaMail.root@benjamin.baylink.com> Message-ID: <532B4417.5060204@pari.edu> On 03/20/2014 12:27 PM, Gary Buhrmaster wrote: > "Think of the children!" I hear the 2017 edition of NFPA 70 (aka NEC) > may require one to turn off the power to the entire household in order > to plug in a coffee maker to minimize potential arc flash hazard.... > (just kidding). Gary ROTFL..... No, I'll just don my >$700 arc-flash suit (8 cal per sq cm rated) before making coffee in the morning..... While I say that somewhat tongue-in-check, arc flash really is serious business, see the youtube video called 'Donnie's Accident' to see how serious; I had to have a suit because I am in charge of the power monitoring for our data centers, and hooking up our Fluke 435 on the input to our Mitsubish 9900B UPS requires full arc flash protection at the 8 cal level. I'm glad it's not on our main switchgear, though, as the 6,000A busses there require 40 cal suits, and those are really expensive. The smaller feeders don't require the full suit, but I have made a habit of wearing it any time I make a measurement with the 435, even on the small 30KVA PDU's, mainly just to make it a habit, since one wrong move can be very painful. All to get our actual PUE to do the adjustments on our receptacle costs for our data centers. (our PUE, depending upon the time of year, runs between 1.1 and 1.4, by the way). But that's drifting even farther off-topic..... From Bryan at bryanfields.net Thu Mar 20 20:17:44 2014 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 20 Mar 2014 16:17:44 -0400 Subject: Level 3 blames Internet slowdowns on =?UTF-8?B?SVNQc+KAmSByZQ==?= =?UTF-8?B?ZnVzYWwgdG8gdXBncmFkZSBuZXR3b3JrcyB8IEFycyBUZWNobmljYQ==?= In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B187E.7090009@ispn.net> Message-ID: <532B4CE8.3020406@bryanfields.net> On 3/20/14, 12:34 PM, Blake Hudson wrote: > The solution seems to be competition or regulation. I'd prefer competition to regulation. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From Petter.Bruland at allegiantair.com Thu Mar 20 21:21:49 2014 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Thu, 20 Mar 2014 21:21:49 +0000 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: +1 Is this what happens when a vendor gets too big? -Petter -----Original Message----- From: Bryan Socha [mailto:bryan at digitalocean.com] Sent: Thursday, March 20, 2014 9:35 AM To: mark.tinka at seacom.mu Cc: nanog list Subject: Re: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica I don't know where everyones traffic goes but level3 and us, nothing. We've dropped all but 1 line which will be gone in 60 days. I don't care what their excuse is, they have been horrible this last 14 months and I'd rather get bw from cogent who isn't great but doesn't blame everyone else for their inability to peer better... A premium cost provider should have premium service and level3 is no longer that. Bryan Socha Network Engineer DigitalOcean 646-450-0472 On Thu, Mar 20, 2014 at 12:05 PM, Mark Tinka wrote: > On Thursday, March 20, 2014 04:18:59 PM Patrick W. Gilmore > wrote: > > > "The market" can only "work around" things if there is a functioning > > market. Monopolies are not a functioning market. > > When did we ever have a "functioning market", even in markets that are > considered "liberalized" :-)? > > It is what it is - it's just less bad in some places than others. > > > There will be a solution - in fact, there is today. > > Doesn't mean it is optimal. In fact, in the presence of a monopoly, > > it is pretty much guaranteed to be sub-optimal. > > Aye. > > Mark. > From wbailey at satelliteintelligencegroup.com Thu Mar 20 21:38:37 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 20 Mar 2014 21:38:37 +0000 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: This email is the reason I spend money with digital ocean. :) You should too. On 3/20/14, 9:34 AM, "Bryan Socha" wrote: >I don't know where everyones traffic goes but level3 and us, nothing. >We've dropped all but 1 line which will be gone in 60 days. I don't >care >what their excuse is, they have been horrible this last 14 months and I'd >rather get bw from cogent who isn't great but doesn't blame everyone else >for their inability to peer better... > >A premium cost provider should have premium service and level3 is no >longer >that. > > >Bryan Socha >Network Engineer >DigitalOcean >646-450-0472 > > >On Thu, Mar 20, 2014 at 12:05 PM, Mark Tinka wrote: > >> On Thursday, March 20, 2014 04:18:59 PM Patrick W. Gilmore >> wrote: >> >> > "The market" can only "work around" things if there is a >> > functioning market. Monopolies are not a functioning >> > market. >> >> When did we ever have a "functioning market", even in >> markets that are considered "liberalized" :-)? >> >> It is what it is - it's just less bad in some places than >> others. >> >> > There will be a solution - in fact, there is today. >> > Doesn't mean it is optimal. In fact, in the presence of >> > a monopoly, it is pretty much guaranteed to be >> > sub-optimal. >> >> Aye. >> >> Mark. >> From jimpop at gmail.com Thu Mar 20 21:52:56 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 20 Mar 2014 17:52:56 -0400 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: On Thu, Mar 20, 2014 at 5:38 PM, Warren Bailey wrote: > This email is the reason I spend money with digital ocean. :) > > You should too. uhh, no. It's the 21st century. I prefer to spend my money with those that, at a bare minimum, provide IPv6. -Jim P. From kemp at network-services.uoregon.edu Thu Mar 20 21:57:18 2014 From: kemp at network-services.uoregon.edu (John Kemp) Date: Thu, 20 Mar 2014 14:57:18 -0700 Subject: new RouteViews collector at NWAX: route-views.nwax.routeviews.org Message-ID: <532B643E.7070602@network-services.uoregon.edu> Just brought online Details at: http://www.routeviews.org/nwax.html We would welcome a few more NWAX peers at this point. Thanks to NWAX and IOVATION, -- John Kemp RouteViews Engineer NOC: noc at routeviews.org MAIL: help at routeviews.org WWW: http://www.routeviews.org From wbailey at satelliteintelligencegroup.com Thu Mar 20 21:58:55 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 20 Mar 2014 21:58:55 +0000 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: Meh.. Some providers need to/should comply with the majority of the requirements. I?d support ipv6 if I could and it wasn?t a big deal, but my traffic originates from (usually) the ipv4 sphere. So unless all of these carriers start magically migrating to v6, I don?t know that a lot of ?hosting? providers need to support it. It?s a cool feature, but it?s not something where I head for the door when they say I can?t receive v6 traffic. My .02. On 3/20/14, 2:52 PM, "Jim Popovitch" wrote: >On Thu, Mar 20, 2014 at 5:38 PM, Warren Bailey > wrote: >> This email is the reason I spend money with digital ocean. :) >> >> You should too. > >uhh, no. It's the 21st century. I prefer to spend my money with those >that, at a bare minimum, provide IPv6. > >-Jim P. From fergdawgster at mykolab.com Thu Mar 20 22:04:25 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 20 Mar 2014 15:04:25 -0700 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> Message-ID: <532B65E9.8070102@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Are carriers prepared to tunnel IPv4 traffic? Carriers offering v6 is a novel idea, but the edge networks, enterprises, etc. are moving very fast. - - ferg On 3/20/2014 2:58 PM, Warren Bailey wrote: > Meh.. Some providers need to/should comply with the majority of > the requirements. I?d support ipv6 if I could and it wasn?t a big > deal, but my traffic originates from (usually) the ipv4 sphere. So > unless all of these carriers start magically migrating to v6, I > don?t know that a lot of ?hosting? providers need to support it. > It?s a cool feature, but it?s not something where I head for the > door when they say I can?t receive v6 traffic. > > My .02. > > On 3/20/14, 2:52 PM, "Jim Popovitch" wrote: > >> On Thu, Mar 20, 2014 at 5:38 PM, Warren Bailey >> wrote: >>> This email is the reason I spend money with digital ocean. :) >>> >>> You should too. >> >> uhh, no. It's the 21st century. I prefer to spend my money with >> those that, at a bare minimum, provide IPv6. >> >> -Jim P. > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMrZekACgkQKJasdVTchbIXxwD+NLe6LUPJCbpKXGfevbPzAGWy BJu93FYH2Lfl9lMjTToA/2uGkqbI/ibO1eHH412gw4A6yLT7LLUoVK8yXwJiGRm1 =mbB3 -----END PGP SIGNATURE----- From wbailey at satelliteintelligencegroup.com Thu Mar 20 22:07:40 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 20 Mar 2014 22:07:40 +0000 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <532B65E9.8070102@mykolab.com> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B65E9.8070102@mykolab.com> Message-ID: Sounds like a lot of 6 to 4 links to me.. ;) On 3/20/14, 3:04 PM, "Paul Ferguson" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Are carriers prepared to tunnel IPv4 traffic? > >Carriers offering v6 is a novel idea, but the edge networks, >enterprises, etc. are moving very fast. > >- - ferg > > > >On 3/20/2014 2:58 PM, Warren Bailey wrote: > >> Meh.. Some providers need to/should comply with the majority of >> the requirements. I?d support ipv6 if I could and it wasn?t a big >> deal, but my traffic originates from (usually) the ipv4 sphere. So >> unless all of these carriers start magically migrating to v6, I >> don?t know that a lot of ?hosting? providers need to support it. >> It?s a cool feature, but it?s not something where I head for the >> door when they say I can?t receive v6 traffic. >> >> My .02. >> >> On 3/20/14, 2:52 PM, "Jim Popovitch" wrote: >> >>> On Thu, Mar 20, 2014 at 5:38 PM, Warren Bailey >>> wrote: >>>> This email is the reason I spend money with digital ocean. :) >>>> >>>> You should too. >>> >>> uhh, no. It's the 21st century. I prefer to spend my money with >>> those that, at a bare minimum, provide IPv6. >>> >>> -Jim P. >> >> >> >> > > >- -- >Paul Ferguson >VP Threat Intelligence, IID >PGP Public Key ID: 0x54DC85B2 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.22 (MingW32) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iF4EAREIAAYFAlMrZekACgkQKJasdVTchbIXxwD+NLe6LUPJCbpKXGfevbPzAGWy >BJu93FYH2Lfl9lMjTToA/2uGkqbI/ibO1eHH412gw4A6yLT7LLUoVK8yXwJiGRm1 >=mbB3 >-----END PGP SIGNATURE----- From mysidia at gmail.com Thu Mar 20 23:32:00 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Mar 2014 18:32:00 -0500 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <532AF83A.8010805@ispn.net> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> <201403201439.59967.mark.tinka@seacom.mu> <532AF83A.8010805@ispn.net> Message-ID: On Thu, Mar 20, 2014 at 9:16 AM, Blake Hudson wrote: > > I don't see this as a technical problem, but one of business and ethics. > ISP X advertises/sells customers "up to 8Mbps" (as an example), but when it > comes to delivering that product, they've only guaranteed 512Kbps (if any) > because the ISP hasn't put in the infrastructure to support 8Mbps per > customer. Customer believes Hey, what part of "up to 8Mbps" is an assurance, that the system supports 8Mbps from all customers 24x7 simultaneously? Only the former can be delivered inexpensively; the latter from large service providers is a business service that doesn't seem to be in the compass of ordinary mortals. Because this is the well-known industry standard; it can't accurately be described as one of deception. Then there is this whole matter of end-to-end connectivity. Just because your WAN device links up at 8 Megabits, does not mean you have been guaranteed 8 Mbits end-to-end. Intentionally failing to upgrade selected links and establish peerings to carry traffic to high-demand destinations when necessary, is just constructive rate-limiting. It's just a very clumsy imprecise alternative to rate-limiting a destination, that can be claimed to have been done without specific intent. As far as network neutrality regulation is concerned... that should be regarded with (essentially) no difference, from other traffic management practices, such as using shaping or policing rules to limit connectivity to the destination IP addresses. > he/she has 8Mbps, Content provider says we provide 8Mbps content, but ISP > can (theoretically and in practice) only deliver a fraction of that. That > feels like false advertising to me. > -- -JH From jay at west.net Thu Mar 20 23:52:28 2014 From: jay at west.net (Jay Hennigan) Date: Thu, 20 Mar 2014 16:52:28 -0700 Subject: L6-20P -> L6-30R In-Reply-To: References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> Message-ID: <532B7F3C.7090207@west.net> On 3/18/14 3:54 PM, George Herbert wrote: > This sort of thing is usually an adapter, a little cylinder with a L6-20R > on one end and a L6-30P on the other, since the loads are safe. Either > that, or a short jumper cable wired the same way. The loads aren't safe. You will have a 30-amp circuit breaker feeding the L6-30R socket. The load and its wiring are only rated for 20 amps so if there's an overload you will exceed the ampacity of the wiring downstream of the L6-20P and the L6-20P itself. Option 1: Change the breaker to 20A and change the receptacle to L6-20R. Option 2: Buy a 30-amp rated PDU equipped with L6-30P plug. -- 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 jeff-kell at utc.edu Fri Mar 21 00:00:16 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 20 Mar 2014 20:00:16 -0400 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <4C8DC512-2666-4DC3-81C5-1CA4106CFD2F@ianai.net> <201403201439.59967.mark.tinka@seacom.mu> <532AF83A.8010805@ispn.net> Message-ID: <532B8110.9050506@utc.edu> On 3/20/2014 7:32 PM, Jimmy Hess wrote: > Then there is this whole matter of end-to-end connectivity. Just > because your WAN device links up at 8 Megabits, does not mean you have > been guaranteed 8 Mbits end-to-end. Have run into this one more times that I care to count. We're running very marginally loaded links all around, and have setup "speedtest" site locally to prove the issue is not local. Our upstream Commodity provider also has "speedtest" peer, and we can also point people there. You can point people to them to prove it's not between us and the next hop. Of course some folks just don't get it :) You chase down the squeaky wheel complainers, and find them running IE with a dozen toolbars, a few P2P clients, adware out the wazoo, and other things I can barely bring myself to think about, let alone admit in a public forum :) And doing it over wireless, while they're microwaving their dinner, and ignoring their wireless printer they never bothered to disable since they plugged it in wired. While playing XBox with their wireless controllers, listening to Pandora over their BlueTooth headset, while their roommate is watching Netflix (wirelessly) on their smart TV, with the wireless subwoofer and back speakers. Yeah, end-to-end guarantee? It's difficult enough to prove you have the first hop covered. Plug the damned thing in the wall, download Malwarebytes / Spybot / something, and deal with the real problem here, dude :) "Your internet sucks!". Or as a recent Tweet from a student mentioned, "Fix the Mother Effing wireless in the dorms". (The dorm with the 802.11n / gig ports on the APs / etherchannels back to the data center, nonetheless). Jeff From owen at delong.com Fri Mar 21 00:52:42 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Mar 2014 17:52:42 -0700 Subject: L6-20P -> L6-30R In-Reply-To: <532B7F3C.7090207@west.net> References: <0f92765932769270d2c0a14f3a2d2ccd@mailbox.fastserv.com> <532B7F3C.7090207@west.net> Message-ID: <7320BAF5-541B-4BAF-AC78-6E8473292CC4@delong.com> On Mar 20, 2014, at 4:52 PM, Jay Hennigan wrote: > On 3/18/14 3:54 PM, George Herbert wrote: > >> This sort of thing is usually an adapter, a little cylinder with a L6-20R >> on one end and a L6-30P on the other, since the loads are safe. Either >> that, or a short jumper cable wired the same way. > > The loads aren't safe. You will have a 30-amp circuit breaker feeding > the L6-30R socket. The load and its wiring are only rated for 20 amps > so if there's an overload you will exceed the ampacity of the wiring > downstream of the L6-20P and the L6-20P itself. > > Option 1: Change the breaker to 20A and change the receptacle to L6-20R. > > Option 2: Buy a 30-amp rated PDU equipped with L6-30P plug. Option 3: Put a 20A breaker or fuses inline in the Adapter. Owen From the.lists at mgm51.com Fri Mar 21 01:56:19 2014 From: the.lists at mgm51.com (Mike.) Date: Thu, 20 Mar 2014 21:56:19 -0400 Subject: Level 3 blames Internet slowdowns on =?us-ascii?B?SVNQc+KAmSByZSBmdXNhbCB0byB1cGdyYWRlIG5ldHdvcmtzIHwgQXJzIA==?= Technica In-Reply-To: <532B4CE8.3020406@bryanfields.net> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B187E.7090009@ispn.net> <532B4CE8.3020406@bryanfields.net> Message-ID: <201403202156190289.02EB189D@smtp.24cl.home> On 3/20/2014 at 4:17 PM Bryan Fields wrote: |On 3/20/14, 12:34 PM, Blake Hudson wrote: |> The solution seems to be competition or regulation. |I'd prefer competition to regulation. ============= If real and true competition exists, yes. From stealth702 at gmail.com Fri Mar 21 02:44:25 2014 From: stealth702 at gmail.com (Jeremy) Date: Thu, 20 Mar 2014 20:44:25 -0600 Subject: =?ISO-8859-1?Q?Re=3A_Level_3_blames_Internet_slowdowns_on_ISPs=E2_EURO?= =?ISO-8859-1?Q?=28tm=29_re_fusal_to_upgrade_networks_=7C_Ars_Technica?= In-Reply-To: <201403202156190289.02EB189D@smtp.24cl.home> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B187E.7090009@ispn.net> <532B4CE8.3020406@bryanfields.net> <201403202156190289.02EB189D@smtp.24cl.home> Message-ID: And of course that only last until someone else decides to buy the competition, I mean "invest in other companies". On Mar 20, 2014 7:58 PM, "Mike." wrote: > On 3/20/2014 at 4:17 PM Bryan Fields wrote: > > |On 3/20/14, 12:34 PM, Blake Hudson wrote: > |> The solution seems to be competition or regulation. > |I'd prefer competition to regulation. > ============= > > If real and true competition exists, yes. > > > > > From owen at delong.com Fri Mar 21 02:51:07 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Mar 2014 19:51:07 -0700 Subject: =?iso-8859-1?Q?Re=3A_Level_3_blames_Internet_slowdowns_on_ISPs?= =?iso-8859-1?Q?=E2_EURO=28tm=29_re_fusal_to_upgrade_networks_=7C?= =?iso-8859-1?Q?_Ars_Technica?= In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B187E.7090009@ispn.net> <532B4CE8.3020406@bryanfields.net> <201403202156190289.02EB189D@smtp.24cl.home> Message-ID: <3A4324BB-975E-48CE-B826-B8F04174C274@delong.com> The only way we will ever see real and true competition is if we prohibit Layer 2+ providers from playing in the Layer 1 space. At some point, we will need to recognize that for the population densities in the vast majority of the united States (including most urban areas), Layer 1 is effectively a natural monopoly and you will rarely get more than one provider installing any given media type. An independent layer 1 provider required to provide equal access to all competing layer 2+ providers in each are would drive increased competition in L2+ services. Owen On Mar 20, 2014, at 7:44 PM, Jeremy wrote: > And of course that only last until someone else decides to buy the > competition, I mean "invest in other companies". > On Mar 20, 2014 7:58 PM, "Mike." wrote: > >> On 3/20/2014 at 4:17 PM Bryan Fields wrote: >> >> |On 3/20/14, 12:34 PM, Blake Hudson wrote: >> |> The solution seems to be competition or regulation. >> |I'd prefer competition to regulation. >> ============= >> >> If real and true competition exists, yes. >> >> >> >> >> From LarrySheldon at cox.net Fri Mar 21 02:58:46 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 20 Mar 2014 21:58:46 -0500 Subject: Level 3 blames Internet slowdowns on =?ISO-8859-1?Q?ISPs=E2_?= =?ISO-8859-1?Q?EURO=28tm=29_re_fusal_to_upgrade_networks_=7C?= =?ISO-8859-1?Q?_Ars_Technica?= In-Reply-To: References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B187E.7090009@ispn.net> <532B4CE8.3020406@bryanfields.net> <201403202156190289.02EB189D@smtp.24cl.home> Message-ID: <532BAAE6.1000401@cox.net> On 3/20/2014 9:51 PM, Owen DeLong wrote: > The only way we will ever see real and true competition is if we > prohibit Layer 2+ providers from playing in the Layer 1 space. As long as you have artificial impediments and restrictions, you will have what you have today. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From dmiller at tiggee.com Fri Mar 21 03:47:36 2014 From: dmiller at tiggee.com (David Miller) Date: Thu, 20 Mar 2014 23:47:36 -0400 Subject: =?US-ASCII?Q?Re:_Level_3_blames_Interne?= =?US-ASCII?Q?t_slowdowns_on_=0D__=0D__Technica?= Message-ID: Unless I am reading the tea leaves wrong "competition" will require "regulation". -------- Original message -------- From: "Mike." Date: 03/20/2014 21:56 (GMT-05:00) To: nanog at nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica On 3/20/2014 at 4:17 PM Bryan Fields wrote: |On 3/20/14, 12:34 PM, Blake Hudson wrote: |> The solution seems to be competition or regulation. |I'd prefer competition to regulation.? ============= If real and true competition exists, yes. From mark.tinka at seacom.mu Fri Mar 21 03:53:09 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Mar 2014 05:53:09 +0200 Subject: Level 3 blames Internet slowdowns on =?iso-8859-1?q?ISPs=E2?= EURO(tm) re fusal to upgrade networks | Ars Technica In-Reply-To: <3A4324BB-975E-48CE-B826-B8F04174C274@delong.com> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <3A4324BB-975E-48CE-B826-B8F04174C274@delong.com> Message-ID: <201403210553.20434.mark.tinka@seacom.mu> On Friday, March 21, 2014 04:51:07 AM Owen DeLong wrote: > At some point, we will need to recognize that for the > population densities in the vast majority of the united > States (including most urban areas), Layer 1 is > effectively a natural monopoly and you will rarely get > more than one provider installing any given media type. > An independent layer 1 provider required to provide > equal access to all competing layer 2+ providers in each > are would drive increased competition in L2+ services. What some governments are doing in Asia-Pac and Africa is funding national optical backbones that can be shared by all. The biggest mistake they make, however, is either contract the incumbent to run these national backbone, or get the incumbents and vendors to sub-contract someone of their choosing to run these networks. The general idea, however, is a likely solution to neutralizing the physical layer. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bill at herrin.us Fri Mar 21 03:58:18 2014 From: bill at herrin.us (William Herrin) Date: Thu, 20 Mar 2014 23:58:18 -0400 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <532B4CE8.3020406@bryanfields.net> References: <4e44d35f-a071-4924-a142-097076cbb5b6@email.android.com> <201403201439.59967.mark.tinka@seacom.mu> <201403201805.22911.mark.tinka@seacom.mu> <532B187E.7090009@ispn.net> <532B4CE8.3020406@bryanfields.net> Message-ID: On Thu, Mar 20, 2014 at 4:17 PM, Bryan Fields wrote: > On 3/20/14, 12:34 PM, Blake Hudson wrote: >> The solution seems to be competition or regulation. > I'd prefer competition to regulation. When regulation is done well, competition is the result. Consider the following hypothetical regulation: 1. Any company which deploys communication cable in a public right-of-way is forbidden to sell data storage, data content or services delivering specific data content of any kind including: web sites or web hosting services, email services, audio and visual recordings, television channels. 2. Any company which employs communication cable in a public right-of-way is required to sell its services on a reasonable and non-discriminatory (RAND) basis to all who wish to buy. What would be the result? Incidentally, this isn't a fresh idea. The FCC first got the notion over 50 years ago and more or less regulated telecommunications that way for a quarter of a century. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From LarrySheldon at cox.net Fri Mar 21 04:28:26 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 20 Mar 2014 23:28:26 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: Message-ID: <532BBFEA.70509@cox.net> On 3/20/2014 10:47 PM, David Miller wrote: > Unless I am reading the tea leaves wrong "competition" will require > "regulation". "regulation" prevents "competition". That is why people want regulation. Look at this thread at the people who do not want to be competed-with at L1, for example. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From Joshua_Sholes at cable.comcast.com Fri Mar 21 14:13:34 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Fri, 21 Mar 2014 14:13:34 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <532BBFEA.70509@cox.net> References: <532BBFEA.70509@cox.net> Message-ID: How do you get around the problem of natural monopolies, then? Or should we be moving to a world where, say, a dozen or more separate companies are all running fiber or coax on the poles on my street in an effort to get to my house? IMHO, the only way to get real competition on the last mile is to have the actual fiber/wire infrastructure being owned by a neutral party that's required to pass anyone's traffic. -- Josh Sholes On 3/21/14, 12:28 AM, "Larry Sheldon" wrote: >On 3/20/2014 10:47 PM, David Miller wrote: >> Unless I am reading the tea leaves wrong "competition" will require >> "regulation". > >"regulation" prevents "competition". That is why people want regulation. > >Look at this thread at the people who do not want to be competed-with at >L1, for example. > >-- >Requiescas in pace o email Two identifying characteristics > of System Administrators: >Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From SNaslund at medline.com Fri Mar 21 14:25:09 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Mar 2014 14:25:09 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <532BBFEA.70509@cox.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> >>How do you get around the problem of natural monopolies, then? Or should >>we be moving to a world where, say, a dozen or more separate companies are all running fiber or coax on the poles on my street in an effort to get to my >>house? We already did it. The Telecommunications Act allows competitive service providers to buy access circuits on the incumbents infrastructure. There are some limitations in that you can't always get competitive access to new networks like FIOS (this to allow the incumbent to recoup their costs by exclusive access for some period of time). The access rates are low only when the infrastructure is already in the ground. That is why the new stuff is not factored in. >>IMHO, the only way to get real competition on the last mile is to have the actual fiber/wire infrastructure being owned by a neutral party that's required to >>pass anyone's traffic. Nice idea, too bad no one can make any money on building infrastructure but not selling the services on top of it. Remember Global Crossing? You are asking one company to put up all the capital expense and then try to recover it by allowing access to their infrastructure to anyone at low rates. Not gonna work. Just on a piece of paper, figure out what it costs to get fiber to your neighborhood from the nearest central office and then how much you have to charge to pay for that. If you can get a reasonable price that returns your investment within 20 years, I will be impressed. The other way that is often suggested is that the municipality own the backbone. That might work except they want to tax you and then also nail the service providers so they do exclusive deals like you see in cable franchises that screw the consumer. Steven Naslund On 3/21/14, 12:28 AM, "Larry Sheldon" wrote: >On 3/20/2014 10:47 PM, David Miller wrote: >> Unless I am reading the tea leaves wrong "competition" will require >> "regulation". > >"regulation" prevents "competition". That is why people want regulation. > >Look at this thread at the people who do not want to be competed-with at >L1, for example. > >-- >Requiescas in pace o email Two identifying characteristics > of System Administrators: >Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From jgreco at ns.sol.net Fri Mar 21 10:24:19 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 21 Mar 2014 05:24:19 -0500 (CDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: Message-ID: <201403211024.s2LAOJRn001780@aurora.sol.net> > How do you get around the problem of natural monopolies, then? Or should > we be moving to a world where, say, a dozen or more separate companies are > all running fiber or coax on the poles on my street in an effort to get to > my house? > > IMHO, the only way to get real competition on the last mile is to have the > actual fiber/wire infrastructure being owned by a neutral party that's > required to pass anyone's traffic. Which closely resembles what the original goal of "the National Infrastructure Initiative" was, back in the early 1990's. Fiber to the homes. 86 million of them by 2006. The Bells volunteered to do it in exchange for incentives, which they got, and kept, and then never delivered what was promised. The best short summary of what happened is probably here: http://www.newnetworks.com/ShortSCANDALSummary.htm This boooklet is now maybe ~5-10 years old so it doesn't reflect more recent developments. We *let* the monopolies (er, duopolies in some cases) get away with the regulatory and legislative manipulation that led to the current outcome, and the irony that the message I'm responding to was authored by someone who appears to work for one of those companies would write such a message is not lost upon me. ... 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 Joshua_Sholes at cable.comcast.com Fri Mar 21 14:30:45 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Fri, 21 Mar 2014 14:30:45 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403211024.s2LAOJRn001780@aurora.sol.net> References: <201403211024.s2LAOJRn001780@aurora.sol.net> Message-ID: >http://www.newnetworks.com/ShortSCANDALSummary.htm > >This boooklet is now maybe ~5-10 years old so it doesn't reflect more >recent developments. > >We *let* the monopolies (er, duopolies in some cases) get away with the >regulatory and legislative manipulation that led to the current outcome, That's definitely its own set of problems completely outside of where one stands on any idea in the space or on the regulation vs. competition debate in general. Regulation does no good unless it's enforced, and competition can't exist meaningfully in an environment where unfair business practices are allowed to exist. >and the irony that the message I'm responding to was authored by someone >who appears to work for one of those companies would write such a message >is not lost upon me. I'm not wearing that hat right now, and I'm a Linux engineer anyway. =P -- Josh Sholes From mark.tinka at seacom.mu Fri Mar 21 14:35:01 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Mar 2014 16:35:01 +0200 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> Message-ID: <201403211635.04659.mark.tinka@seacom.mu> On Friday, March 21, 2014 04:25:09 PM Naslund, Steve wrote: > Nice idea, too bad no one can make any money on building > infrastructure but not selling the services on top of > it. Remember Global Crossing? You are asking one > company to put up all the capital expense and then try > to recover it by allowing access to their infrastructure > to anyone at low rates. Not gonna work. Just on a > piece of paper, figure out what it costs to get fiber to > your neighborhood from the nearest central office and > then how much you have to charge to pay for that. If > you can get a reasonable price that returns your > investment within 20 years, I will be impressed. Like I mentioned, some countries Asia-Pac and Africa have seen some of their governments deploying this infrastructure for the citizens. Things go belly-up when the governments sub-contract the actual operations of the network. Either they use the same old incumbents to run it, or they employ private contractors (who are, sometimes, equipment vendors that build the network - which means even more sub-contracting). I've seen such builds focusing on access to the homes, as well as core national backbones. I haven't yet seen both initiatives at the same time in one country. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kin-wei.lee at hp.com Fri Mar 21 14:54:44 2014 From: kin-wei.lee at hp.com (Lee, Steven (Network Consulting Malaysia)) Date: Fri, 21 Mar 2014 14:54:44 +0000 Subject: 100GBASE-SR10 interwork with 10GBASE-SR Message-ID: <392A074AA4FF0A459B45BFE734977F6933A84117@G1W3650.americas.hpqcorp.net> Hi all, is there anyone who has experience the interworking 100GBASE-SR10 with 10GBASE-SR over 24-fiber ribbon cables terminated with MPO/MTP-24 connectors? If yes, any implementation consideration I should be aware? Regards, Steven Lee From jimpop at gmail.com Fri Mar 21 15:15:29 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 21 Mar 2014 11:15:29 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Mar 21, 2014 at 10:25 AM, Naslund, Steve wrote: > Nice idea, too bad no one can make any money on building infrastructure but not selling the services on top of it. Remember Global Crossing? You are asking one company to put up all the capital expense and then try to recover it by allowing access to their infrastructure to anyone at low rates. Not gonna work. Just on a piece of paper, figure out what it costs to get fiber to your neighborhood from the nearest central office and then how much you have to charge to pay for that. If you can get a reasonable price that returns your investment within 20 years, I will be impressed. IIRC, GLBX didn't receive taxpayer funded subsidies, nor municipal bonds, in order to roll out their infrastructure. I would gather that a fiber plant, on whole, costs less than the number of subscribers, multiplied by average monthly bill, and again by average length of service.... not to mention 20 years. -Jim P. From bob at FiberInternetCenter.com Fri Mar 21 15:28:51 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 21 Mar 2014 08:28:51 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> Message-ID: <3b7925b6836a99dda6b01c02a18b0401.squirrel@66.201.44.180> Well, don't forget the labor, taxes, business licenses fees, county taxes on chairs, Obama care, accountants and time required. Bob Evans CTO Bob Evans CTO Do you need IPv4 space to lease, space you can use until IPv6 is the standard? > On Fri, Mar 21, 2014 at 10:25 AM, Naslund, Steve > wrote: >> Nice idea, too bad no one can make any money on building infrastructure >> but not selling the services on top of it. Remember Global Crossing? >> You are asking one company to put up all the capital expense and then >> try to recover it by allowing access to their infrastructure to anyone >> at low rates. Not gonna work. Just on a piece of paper, figure out >> what it costs to get fiber to your neighborhood from the nearest central >> office and then how much you have to charge to pay for that. If you can >> get a reasonable price that returns your investment within 20 years, I >> will be impressed. > > IIRC, GLBX didn't receive taxpayer funded subsidies, nor municipal > bonds, in order to roll out their infrastructure. > > I would gather that a fiber plant, on whole, costs less than the > number of subscribers, multiplied by average monthly bill, and again > by average length of service.... not to mention 20 years. > > -Jim P. > > From web at typo.org Fri Mar 21 15:36:34 2014 From: web at typo.org (Wayne E Bouchard) Date: Fri, 21 Mar 2014 08:36:34 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <201403211024.s2LAOJRn001780@aurora.sol.net> Message-ID: <20140321153634.GA95135@wakko.typo.org> On Fri, Mar 21, 2014 at 02:30:45PM +0000, Sholes, Joshua wrote: > >http://www.newnetworks.com/ShortSCANDALSummary.htm > > > >This boooklet is now maybe ~5-10 years old so it doesn't reflect more > >recent developments. > > > >We *let* the monopolies (er, duopolies in some cases) get away with the > >regulatory and legislative manipulation that led to the current outcome, > > That's definitely its own set of problems completely outside of where one > stands on any idea in the space or on the regulation vs. competition > debate in general. Regulation does no good unless it's enforced, and > competition can't exist meaningfully in an environment where unfair > business practices are allowed to exist. Which are both permitted and perpetuated in large part by the regulatory environment we are made to operate under. Monopolies usually require some sort of government support in order to survive. Don't forget that it is the old companies (regardless of their current name) making life difficult for the content carriers. They don't want to adapt so they are lobbying to enact policies which make it easier for them to sit there and be stagnant dinosaurs while the rest of the world moves on. It's the same thing the record companies are doing on with a different flavor. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From SNaslund at medline.com Fri Mar 21 15:48:40 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Mar 2014 15:48:40 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> What do you mean by average monthly bill? That is the issue here. The average monthly bill includes the services you are getting. In the Chicago area a fiber optic access circuit unbundled from the imcumbent carrier to a competitive carrier is something like $10 a month or so. How could you possibly think you can fund a build out in a new area for that price? It may be possible to pay for that over 20 years. The problem is that no one goes into business to break even over 20 years. Would you fund my business model if I told you I needed hundreds of millions of dollars in capital expense and I might show you a profit in 20 years? How much are you willing to have added to your cable and Internet service bills for the access component of the service? Now think of this. I am the guy who owns all of the layer 1 in your area. What if I go out of business? What if I overcharge you? What if I charge $100 a month to access the infrastructure? Who fixes that. The government regulations. I think this business model existed before. It was called the Bell System and the only way they could pay for it was to charge you high rates for services. Steven Naslund -----Original Message----- From: Jim Popovitch [mailto:jimpop at gmail.com] Sent: Friday, March 21, 2014 10:15 AM To: Naslund, Steve Cc: Sholes, Joshua; Larry Sheldon; nanog at nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica On Fri, Mar 21, 2014 at 10:25 AM, Naslund, Steve wrote: > Nice idea, too bad no one can make any money on building infrastructure but not selling the services on top of it. Remember Global Crossing? You are asking one company to put up all the capital expense and then try to recover it by allowing access to their infrastructure to anyone at low rates. Not gonna work. Just on a piece of paper, figure out what it costs to get fiber to your neighborhood from the nearest central office and then how much you have to charge to pay for that. If you can get a reasonable price that returns your investment within 20 years, I will be impressed. IIRC, GLBX didn't receive taxpayer funded subsidies, nor municipal bonds, in order to roll out their infrastructure. I would gather that a fiber plant, on whole, costs less than the number of subscribers, multiplied by average monthly bill, and again by average length of service.... not to mention 20 years. -Jim P. From SNaslund at medline.com Fri Mar 21 15:59:54 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Mar 2014 15:59:54 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403211700.42920.mark.tinka@seacom.mu> References: <201403211635.04659.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B541F788@MUNPRDMBXA1.medline.com> <201403211700.42920.mark.tinka@seacom.mu> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5420C20@MUNPRDMBXA1.medline.com> Well, we were originally talking about regulation in the US as discussed by Level 3 in the subject article, but we can get into the international space if you like. So, as far as the government or Wall Street funding the build out of the commercial Internet, that is not what happened. I was there in the beginning selling dial-up service, dedicated data circuits, and finally DSL. Wall Street got into the game very late. We built our company into a $30 million operation before they cared to notice. The government, while they did the initial research that created the Internet, did not help us and was in fact a huge hinderance to progress until the Telecommunications Act where they attempted to deal with us upstarts trying to upset the status quo. Why people think the government was instrumental in the commercial Internet is beyond me. I think some politicians might want you to think so. I see no reason why the US model would not work in any market economy. It is a simple matter of supply and demand. If your economy cannot afford the infrastructure or the people have no money to pay for services, you are going to have a problem. There is a huge problem in that people think GOVERNMENT FUNDED=FREE, it does not and in most cases is more expensive than the commercial alternatives since there is no motivation to be efficient. In that case a hybrid approach like I used in helping schools in the Philippines will work better. We used government funding and private grants to provide high speed internet to rural schools and we did it by buying commercial available wireless and cable services. This helps the people and also helps grow the communications industry there. The government does nothing but pay the bills (and they rarely even do that right). Steven Naslund -----Original Message----- From: Mark Tinka [mailto:mark.tinka at seacom.mu] Sent: Friday, March 21, 2014 10:01 AM To: Naslund, Steve Subject: Re: Level 3 blames Internet slowdowns on Technica On Friday, March 21, 2014 04:46:13 PM Naslund, Steve wrote: > First question to ask yourself is who is paying for it. > The "governments" don't do things out of the kindness of their hearts. > They will want to be paid for it. > Control means power and people in power want to get paid. No one is denying that. If I have the opportunity for my taxes to do real work like build a national optical backbone, instead of lining some guy's pockets, I'm fine with that. > Who else would run the network? Do we think the government can or > should be operating communications networks? Do you want the > government controlling what content you get or producing that content? > I think not. > Look at the wonderful job they are doing maintaining our > transportation infrastructure. My point was the governments do not know how to seek information on how best to sub-contract running of the network. I certainly don't want the government running my network. Heck, they barely know how to use the lift in their building. But what we need is a more transparent process on choosing the right person (and model) to operate the network. In most deployments, this has been the weakest link. > That is because we don't need a government initiative to do that. > Most people in the US have access to broadband networks today because > they wanted it and they were willing to pay someone for it. That is > called a business initiative and it is much more efficient than any > government initiative. Right, but that is the U.S. (which is why I specifically mentioned Asia-Pac and Africa). Other countries with smaller economies have realized that the quickest way to close the "digital gap" is, perhaps for better or worse, have the government fund the projects (in part or whole). Malaysia and Singapore have been relatively successful in this. Australia is still wanting, and Tanzania is not something I'd say was done well but works for the most part. But the use-cases are there, at the very least, for learning. > As far as "core national backbones" the government has built several > over the years including the ARPANET, Defense Data Network, NSFnet, > etc. None of those really helped the consumer except as models for > the public networks. Our service providers have built global > backbones that are more resilient and outrun all of those networks > because market forces had them do it. I needed an MPLS circuit from > my backbone to Shanghai China recently and I could get that from > several service providers at reasonable rates. > > We did get two initiatives to build out access to the home as well as > the national backbone. It is called the Internet. Backbone speeds > increased at the same time access to the home went from dial up to DSL > to cable to FTTH. What's the problem here. Again, you're looking at it from "where the U.S. came from", which, for all intents and purposes, is where the Internet started. Great! But that does not help other economies today. And if you consider the ARPANET, NSFnet, e.t.c., while those were not terribly successful from the consumer perspective, in the end, they led to what the commercial Internet looks like today. Priorities (either at the government or corporate level) have changed a great deal from the early days of the Internet. The amount of investment required to build out nationally in a short span of time is not available in the ways Wall Street (or government research grants) funded "The Boom" in North America. In developing countries, it leaves very little choice on who is willing to make that investment. That, I can tell you for free :-). Mark. From jimpop at gmail.com Fri Mar 21 16:07:10 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 21 Mar 2014 12:07:10 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Mar 21, 2014 at 11:48 AM, Naslund, Steve wrote: > What do you mean by average monthly bill? What is the average monthly (non-subsidized) access cost that your friends and family pay each month? -Jim P. From SNaslund at medline.com Fri Mar 21 16:13:28 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Mar 2014 16:13:28 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> We don't know because the service provider rolls that cost up along with the services they sell. That is my point. They are able to spread the costs out based on the profitable services they sell. If they were not able to sell us services I am not sure they could afford to provide that infrastructure. In fact, having been a service provider I can tell you that I paid the LEC about $4 a month for a copper pair to your house to sell DSL service at around ten times that cost. I am sure the LEC was not making money at the $4 a month and I know I could not fund a build out for that price. Steven Naslund -----Original Message----- From: Jim Popovitch [mailto:jimpop at gmail.com] Sent: Friday, March 21, 2014 11:07 AM To: Naslund, Steve Cc: Sholes, Joshua; Larry Sheldon; nanog at nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica On Fri, Mar 21, 2014 at 11:48 AM, Naslund, Steve wrote: > What do you mean by average monthly bill? What is the average monthly (non-subsidized) access cost that your friends and family pay each month? -Jim P. From mark.tinka at seacom.mu Fri Mar 21 16:21:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Mar 2014 18:21:20 +0200 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420C20@MUNPRDMBXA1.medline.com> References: <201403211700.42920.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B5420C20@MUNPRDMBXA1.medline.com> Message-ID: <201403211821.24004.mark.tinka@seacom.mu> On Friday, March 21, 2014 05:59:54 PM Naslund, Steve wrote: > So, as far as the government or Wall Street funding the > build out of the commercial Internet, that is not what > happened. Lots of terrestrial and submarine optical fibre was built in the late 90's, and much of it has either gone unused until now, or saw lots of M&A's as a result of the bust that left hundreds-of-millions of dollars in investment with just a few cents on the dollar, over night. Many of those cable systems go by other names you may know today. The Internet isn't one thing. > I see no reason why the US model would not work in any > market economy. It is a simple matter of supply and > demand. If your economy cannot afford the > infrastructure or the people have no money to pay for > services, you are going to have a problem. There is a > huge problem in that people think GOVERNMENT > FUNDED=FREE, it does not and in most cases is more > expensive than the commercial alternatives since there > is no motivation to be efficient. No one said they wanted anything free. Everyone knows free Internet only exists at Starbucks and your next Internet communit conference - and even that is not always reliable. In Africa and parts of Asia, supply and demand is equally rife. In fact, in some cases, supply outstrips demand. We could get into a lot of reasons why supply won't reach out to demand, but I'd be digressing. Suffice it to say, while over-supply may be present, it's in the hands of the few who all concert (mostly unknowingly) to keep prices high. As you know, no one will invest in something for a 20-year return. But by the same token, fibre lives for a long while; trying to recoup your investment in six months is not going to help anyone (except open up competition against you, the one who probably went in first). The need for "neutral" infrastructure which is reasonably and well commercially run is likely a solution to better pricing with professional quality, or the knife that butters the price decline wheat. > In that case a hybrid approach like I used in helping > schools in the Philippines will work better. We used > government funding and private grants to provide high > speed internet to rural schools and we did it by buying > commercial available wireless and cable services. This > helps the people and also helps grow the communications > industry there. The government does nothing but pay the > bills (and they rarely even do that right). And I do agree that a hybrid approach with a neutral fibre backbone is what is lacking with these national projects. The governments building these backbones know little about how the Internet really works (which includes DNS, ICANN, and that free things don't work :-). What is needed is clue going into these projects that help turn the national project into a well-run, commercial businesses that looks after itself, but also fufills the goal of ubiquitous connectivity. The hurdle isn't running the network. The hurdle is getting the fibre into the ground - and that is a monumentous hurdle. Running the network is where it all falls apart if unchecked. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From no.spam at comcast.net Fri Mar 21 18:06:07 2014 From: no.spam at comcast.net (Keegan Holley) Date: Fri, 21 Mar 2014 14:06:07 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B541F721@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> Message-ID: <62219BC3-A891-4847-8DD7-3BF4B4BE89B2@comcast.net> On Mar 21, 2014, at 12:13 PM, Naslund, Steve wrote: > We don't know because the service provider rolls that cost up along with the services they sell. That is my point. They are able to spread the costs out based on the profitable services they sell. If they were not able to sell us services I am not sure they could afford to provide that infrastructure. Monthly fees do much more than finance the cost of infrastructure. Most large providers take a significant margin. It?s all about how these services are perceived. The preservation of this margin is the number one reason why internet access isn?t considered a utility or a basic right today. It also allows prices to increase unchecked, based on nothing other than the goals of specific companies. There are many places where infrastructure is subsidized and controlled by the government. To them some things are more important than the need to make markets. They just trust that the overall benefit to society is worth modifying the market. > In fact, having been a service provider I can tell you that I paid the LEC about $4 a month for a copper pair to your house to sell DSL service at around ten times that cost. I am sure the LEC was not making money at the $4 a month and I know I could not fund a build out for that price. Being a LEC is more profitable than anything else because they control the prices. If you found an iLEC that charged $4 for something worth $40 that doesn?t mean being a LEC isn?t profitable. After the long-distance carriers were forced to divest from local the LEC?s grew and quickly bought them. It?s more profitable to be a LEC than to resell their services. The only large carriers left are former LEC?s AKA baby bells. > > -----Original Message----- > From: Jim Popovitch [mailto:jimpop at gmail.com] > Sent: Friday, March 21, 2014 11:07 AM > To: Naslund, Steve > Cc: Sholes, Joshua; Larry Sheldon; nanog at nanog.org > Subject: Re: Level 3 blames Internet slowdowns on Technica > > On Fri, Mar 21, 2014 at 11:48 AM, Naslund, Steve wrote: >> What do you mean by average monthly bill? > > What is the average monthly (non-subsidized) access cost that your friends and family pay each month? > > -Jim P. > From no.spam at comcast.net Fri Mar 21 18:08:29 2014 From: no.spam at comcast.net (Keegan Holley) Date: Fri, 21 Mar 2014 14:08:29 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: Message-ID: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> How come no one ever asks if competition is required? On Mar 20, 2014, at 11:47 PM, David Miller wrote: > Unless I am reading the tea leaves wrong "competition" will require "regulation". > > > > -------- Original message -------- > From: "Mike." > Date: 03/20/2014 21:56 (GMT-05:00) > To: nanog at nanog.org > Subject: Re: Level 3 blames Internet slowdowns on > > Technica > > On 3/20/2014 at 4:17 PM Bryan Fields wrote: > > |On 3/20/14, 12:34 PM, Blake Hudson wrote: > |> The solution seems to be competition or regulation. > |I'd prefer competition to regulation. > ============= > > If real and true competition exists, yes. > > > > From cscora at apnic.net Fri Mar 21 18:13:35 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Mar 2014 04:13:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201403211813.s2LIDZB5009050@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Mar, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 488304 Prefixes after maximum aggregation: 192289 Deaggregation factor: 2.54 Unique aggregates announced to Internet: 240828 Total ASes present in the Internet Routing Table: 46406 Prefixes per ASN: 10.52 Origin-only ASes present in the Internet Routing Table: 35677 Origin ASes announcing only one prefix: 16383 Transit ASes present in the Internet Routing Table: 6041 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1866 Unregistered ASNs in the Routing Table: 475 Number of 32-bit ASNs allocated by the RIRs: 6186 Number of 32-bit ASNs visible in the Routing Table: 4688 Prefixes from 32-bit ASNs in the Routing Table: 15130 Number of bogon 32-bit ASNs visible in the Routing Table: 32 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 442 Number of addresses announced to Internet: 2659727108 Equivalent to 158 /8s, 136 /16s and 55 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.9 Total number of prefixes smaller than registry allocations: 170366 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 115939 Total APNIC prefixes after maximum aggregation: 34611 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 118564 Unique aggregates announced from the APNIC address blocks: 49644 APNIC Region origin ASes present in the Internet Routing Table: 4895 APNIC Prefixes per ASN: 24.22 APNIC Region origin ASes announcing only one prefix: 1225 APNIC Region transit ASes present in the Internet Routing Table: 858 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 869 Number of APNIC addresses announced to Internet: 729638528 Equivalent to 43 /8s, 125 /16s and 102 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 166691 Total ARIN prefixes after maximum aggregation: 82932 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 168175 Unique aggregates announced from the ARIN address blocks: 78137 ARIN Region origin ASes present in the Internet Routing Table: 16196 ARIN Prefixes per ASN: 10.38 ARIN Region origin ASes announcing only one prefix: 6119 ARIN Region transit ASes present in the Internet Routing Table: 1660 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 76 Number of ARIN addresses announced to Internet: 1067388032 Equivalent to 63 /8s, 159 /16s and 12 /24s Percentage of available ARIN address space announced: 56.5 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, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 122945 Total RIPE prefixes after maximum aggregation: 62062 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 126909 Unique aggregates announced from the RIPE address blocks: 80365 RIPE Region origin ASes present in the Internet Routing Table: 17647 RIPE Prefixes per ASN: 7.19 RIPE Region origin ASes announcing only one prefix: 8290 RIPE Region transit ASes present in the Internet Routing Table: 2862 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2672 Number of RIPE addresses announced to Internet: 657136260 Equivalent to 39 /8s, 43 /16s and 26 /24s Percentage of available RIPE address space announced: 95.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 55145 Total LACNIC prefixes after maximum aggregation: 9992 LACNIC Deaggregation factor: 5.52 Prefixes being announced from the LACNIC address blocks: 61211 Unique aggregates announced from the LACNIC address blocks: 28016 LACNIC Region origin ASes present in the Internet Routing Table: 2078 LACNIC Prefixes per ASN: 29.46 LACNIC Region origin ASes announcing only one prefix: 544 LACNIC Region transit ASes present in the Internet Routing Table: 427 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1057 Number of LACNIC addresses announced to Internet: 153329024 Equivalent to 9 /8s, 35 /16s and 157 /24s Percentage of available LACNIC address space announced: 91.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12339 Total AfriNIC prefixes after maximum aggregation: 2655 AfriNIC Deaggregation factor: 4.65 Prefixes being announced from the AfriNIC address blocks: 13003 Unique aggregates announced from the AfriNIC address blocks: 4293 AfriNIC Region origin ASes present in the Internet Routing Table: 708 AfriNIC Prefixes per ASN: 18.37 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 153 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 14 Number of AfriNIC addresses announced to Internet: 51886592 Equivalent to 3 /8s, 23 /16s and 186 /24s Percentage of available AfriNIC address space announced: 51.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2980 11582 897 Korea Telecom 17974 2765 903 78 PT Telekomunikasi Indonesia 7545 2225 320 116 TPG Telecom Limited 4755 1840 396 197 TATA Communications formerly 9829 1604 1288 35 National Internet Backbone 4808 1350 2225 386 CNCGROUP IP network China169 9583 1307 102 533 Sify Limited 9498 1246 312 78 BHARTI Airtel Ltd. 7552 1228 1082 13 Viettel Corporation 24560 1124 384 177 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3013 3688 53 BellSouth.net Inc. 22773 2417 2938 140 Cox Communications Inc. 1785 2185 694 128 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1694 1674 575 Charter Communications 4323 1624 1089 412 tw telecom holdings, inc. 701 1492 11174 763 MCI Communications Services, 30036 1391 301 556 Mediacom Communications Corp 6983 1328 800 308 ITC^Deltacom 22561 1304 402 232 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1751 544 16 OJSC "Vimpelcom" 34984 1519 264 248 TELLCOM ILETISIM HIZMETLERI A 20940 1300 508 970 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 951 370 41 Bezeq International-Ltd 6849 861 361 34 JSC "Ukrtelecom" 6830 762 2329 425 Liberty Global Operations B.V 12479 714 797 56 France Telecom Espana SA 35228 555 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3624 1943 94 NET Servi?os de Comunica??o S 10620 2789 446 199 Telmex Colombia S.A. 18881 1917 972 21 Global Village Telecom 7303 1746 1172 218 Telecom Argentina S.A. 8151 1394 2916 410 Uninet S.A. de C.V. 6503 1157 434 61 Axtel, S.A.B. de C.V. 7738 912 1754 40 Telemar Norte Leste S.A. 11830 866 364 15 Instituto Costarricense de El 27947 856 113 48 Telconet S.A 6147 787 373 27 Telefonica del Peru S.A.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1637 240 6 Sudanese Mobile Telephone (ZA 24863 931 280 26 Link Egypt (Link.NET) 6713 603 701 28 Office National des Postes et 8452 520 958 13 TE-AS 24835 298 144 9 Vodafone Data 36992 282 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 37054 215 19 6 Data Telecom Service 29571 211 22 18 Cote d'Ivoire Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3624 1943 94 NET Servi?os de Comunica??o S 6389 3013 3688 53 BellSouth.net Inc. 4766 2980 11582 897 Korea Telecom 10620 2789 446 199 Telmex Colombia S.A. 17974 2765 903 78 PT Telekomunikasi Indonesia 22773 2417 2938 140 Cox Communications Inc. 7545 2225 320 116 TPG Telecom Limited 1785 2185 694 128 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1917 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3013 2960 BellSouth.net Inc. 17974 2765 2687 PT Telekomunikasi Indonesia 10620 2789 2590 Telmex Colombia S.A. 22773 2417 2277 Cox Communications Inc. 7545 2225 2109 TPG Telecom Limited 4766 2980 2083 Korea Telecom 1785 2185 2057 PaeTec Communications, Inc. 18881 1917 1896 Global Village Telecom 18566 2048 1870 MegaPath Corporation 8402 1751 1735 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 65456 PRIVATE 5.245.224.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:16 /9:12 /10:30 /11:90 /12:254 /13:477 /14:951 /15:1653 /16:12881 /17:6771 /18:11528 /19:23967 /20:33847 /21:36515 /22:52055 /23:45570 /24:259380 /25:816 /26:1000 /27:414 /28:12 /29:18 /30:8 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 6389 1696 3013 BellSouth.net Inc. 22773 1654 2417 Cox Communications Inc. 36998 1599 1637 Sudanese Mobile Telephone (ZA 8402 1430 1751 OJSC "Vimpelcom" 30036 1229 1391 Mediacom Communications Corp 11492 1175 1222 CABLE ONE, INC. 1785 1169 2185 PaeTec Communications, Inc. 6983 1044 1328 ITC^Deltacom 34984 1004 1519 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:994 2:727 3:3 4:16 5:908 6:19 8:715 12:1863 13:4 14:977 15:13 16:3 17:31 18:21 20:35 23:745 24:1725 27:1763 31:1513 32:44 33:2 34:5 36:122 37:1828 38:942 39:4 40:195 41:3133 42:245 44:18 46:2144 47:18 49:671 50:915 52:12 54:47 55:7 57:26 58:1161 59:596 60:381 61:1525 62:1246 63:1985 64:4357 65:2259 66:4226 67:2044 68:1033 69:3288 70:850 71:461 72:1971 74:2662 75:314 76:406 77:1219 78:1041 79:699 80:1322 81:1134 82:681 83:755 84:754 85:1308 86:436 87:1198 88:521 89:1759 90:151 91:5801 92:668 93:1710 94:2055 95:1507 96:541 97:350 98:1077 99:46 100:50 101:819 103:4460 105:553 106:166 107:575 108:554 109:2016 110:979 111:1300 112:655 113:832 114:873 115:1107 116:1040 117:881 118:1358 119:1328 120:374 121:793 122:1920 123:1279 124:1453 125:1480 128:653 129:245 130:343 131:656 132:358 133:159 134:318 135:74 136:248 137:319 138:349 139:159 140:212 141:358 142:560 143:428 144:508 145:103 146:599 147:430 148:798 149:344 150:156 151:588 152:424 153:206 154:234 155:467 156:336 157:344 158:219 159:876 160:350 161:478 162:1258 163:222 164:680 165:619 166:280 167:602 168:1027 169:124 170:1287 171:192 172:23 173:1599 174:681 175:605 176:1465 177:2829 178:1945 179:606 180:1666 181:1022 182:1518 183:508 184:719 185:1421 186:2846 187:1479 188:1871 189:1430 190:7462 191:121 192:7167 193:5457 194:4015 195:3386 196:1367 197:1110 198:4983 199:5608 200:6051 201:2660 202:8969 203:8912 204:4668 205:2691 206:2933 207:2949 208:3953 209:3732 210:3084 211:1694 212:2225 213:2053 214:887 215:84 216:5532 217:1692 218:562 219:317 220:1284 221:594 222:350 223:609 End of report From choprboy at dakotacom.net Fri Mar 21 18:19:40 2014 From: choprboy at dakotacom.net (Adrian) Date: Fri, 21 Mar 2014 11:19:40 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> Message-ID: <201403211119.40822.choprboy@dakotacom.net> On Friday 21 March 2014 09:13:28 Naslund, Steve wrote: > ... In fact, having been a service provider I can tell you > that I paid the LEC about $4 a month for a copper pair to your house to > sell DSL service at around ten times that cost. I am sure the LEC was not making money at the $4 a month and I know I could not fund a build out for that price. I take it you have not been a service provider for a while? Thanks to its removal from the tariff list, that $4 DSL pair from the ILEC for a third party ISP now costs $34... That doesn't include ISP cost. Adrian From jared at puck.nether.net Fri Mar 21 18:21:09 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Mar 2014 14:21:09 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> References: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> Message-ID: <211073AE-9395-4025-9423-A78DA762CD39@puck.nether.net> On Mar 21, 2014, at 2:08 PM, Keegan Holley wrote: > How come no one ever asks if competition is required? I think the issue here is there is competition, but those you are seen as competing with are in a different strata providing the same service. eg: Cellular data competes with DSL/DOCSIS/FTT* Now, due to speed, caps, etc.. it may not be a "fair" comparison, but this isn't about fair, it's about "is there competition in the market". I know many folks that live outside the wired high-speed boundaries and things are not getting any better there. Most use some hotspot or similar for their home connectivity. Is there a market for high speed there? certainly, but it's being filled by other technology. There are many folks that work around these issues with other solutions, including satellite, fixed wireless and/or microwave or even localized fiber build-outs. Look at the RUS/NTIA/BTOP focus, it was on getting the anchor institutions well connected to provide a sense of community. The challenge is not everyone is equally equipped. Merit (in my area) has fiber close to me, but they don't offer services to anyone but existing members and have no consumer offerings. Market segmentation happens for a variety of reasons, sometimes economic, sometimes complete differences in ROI models. Nobody can afford to run universal fiber everywhere as a greenfield build, but there are localized markets where it can make sense. Certainly it can make sense to connect some islands to each other via some other technology. Taking list prices from providers webpages, what cogent used to list $4/meg, so that means (assuming everything is perfect) offering 10Mb/s service at a home could possibly cost $40/mo for a provider, not counting capital costs and other elements (support, customer acquisition costs, bad debt, etc). I'm sure folks can build networks for low cost, you can get a 1G active-ethernet NID for sub-$150 with optics, but you still need to aggregate and account for it somewhere. - Jared From fergdawgster at mykolab.com Fri Mar 21 18:41:23 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 21 Mar 2014 11:41:23 -0700 Subject: US to relinquish control of Internet In-Reply-To: <53294C8B.3040606@cisco.com> References: <53294C8B.3040606@cisco.com> Message-ID: <532C87D3.2000501@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On a related note, another great way to keep track of new ICANN registry agreements is the gTLD Tech mailing list: https://mm.icann.org/mailman/listinfo/gtld-tech ...and the gTLD Notification list: https://mm.icann.org/mailman/listinfo/gtldnotification I have found both to be quite informative. $.02, - - ferg On 3/19/2014 12:51 AM, Eliot Lear wrote: > Patrick: > > On 3/15/14, 12:42 AM, Patrick W. Gilmore wrote: >> (As if the US has "control" anyway....) >> >> It's all over the "popular press", strange I haven't seen it >> here. >> >> >> >> >> >> >> >> >> >> >> Etc., etc. >> >> It's nice of the DoC to "relinquish" control, but I really don't >> see it changing much other than quieting down some hype from >> countries that were saying they were pissed at the US for >> "controlling" the Internet. And I couldn't really see those >> countries doing anything about it unless the US did something >> actually bad, which they wouldn't do IMHO. >> >> Was I being a pollyanna? >> > > How things change is up to every person in the community. > Operators are an incredibly important part of the Internet > ecosystem. Some questions you might want to ask yourself: > > 1. What is the current legal framework for the IANA functions > contract? If you don't know it, it's a good time to learn, if you > are interested. 2. How does it impact operators? 3. What do > operators want out of the evolution that is likely to take place? > > Discussions are taking place now in a few fora, including on the > IAB's internetgovtech mailing list[1], where the focus has largely > been on protocol parameters, one of the IANA pillars. Olaf Kolkman > has written a very interesting draft draft-iab-iana-framework[2] > that gives you at least one view on how to think about the > problem. The IETF has some draft principles that are being knocked > around.[3] There is a separate 1net mailing list[4] in which > mostly the ICANN component is being discussed. Also, there will be > meetings, the ICANN one starting on Friday in Singapore, as but one > example where this topic will be discussed in person. I'm going to > hazard a guess that the RIRs will also be discussing this, both on > lists and in person. Assuredly other governments are paying > attention. > > While I speak only for myself in this email, I will also point out > that Cisco did make a statement about the NTIA announcement.[5] So > have others. > > Eliot > > [1] https://www.iab.org/mailman/listinfo/internetgovtech [2] > http://tools.ietf.org/html/draft-iab-iana-framework-01 [3] > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12562.html > > [4] http://1net-mail.1net.org/mailman/listinfo/discuss > [5] > http://blogs.cisco.com/gov/cisco-supports-u-s-department-of-commerce-decision-to-transition-internet-management-functions/ > > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMsh9MACgkQKJasdVTchbK6lAD/Y490eHIfDUE8uBGCvyzYsc7x zH8VDmDqfGHeZHJ3mTIA/iI1Sw5CX1MFnJHXoiRfSCm+vEz04lNbUoM9gtHpYawE =Li5v -----END PGP SIGNATURE----- From jgreco at ns.sol.net Fri Mar 21 15:01:07 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 21 Mar 2014 10:01:07 -0500 (CDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> Message-ID: <201403211501.s2LF171x005077@aurora.sol.net> > We don't know because the service provider rolls that cost up along with th= > e services they sell. That is my point. They are able to spread the costs= > out based on the profitable services they sell. Okay. > If they were not able to = > sell us services I am not sure they could afford to provide that infrastruc= > ture. That's a crock. You can always provide infrastructure without selling services on top of it. It's wire. Or fiber. Or whatever. If you're not able to subsidize the infrastructure with services, then what you actually get is a less distorted reality where you can actually identify the component costs (circuit, services, etc). > In fact, having been a service provider I can tell you that I paid t= > he LEC about $4 a month for a copper pair to your house to sell DSL service= > at around ten times that cost. I am sure the LEC was not making money at = > the $4 a month and I know I could not fund a build out for that price. Why would you try to fund a build out on that? Why wouldn't you instead charge for the build out as a NRC and then charge for maintenance as a MRC? What you're suggesting reeks of the deliberate cost distortion games that go on so often. My personal favorite is cell phone contracts where the cost of the phone is *cough* "subsidized" by the carrier. But what's really happening is that the customer is paying for the phone over the term of the contract, and if the customer doesn't get a different phone at the end of the contract, then the carrier ... lowers their monthly rate accordingly? No, of course not... they keep it as profit. ... 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 jared at puck.nether.net Fri Mar 21 19:13:19 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Mar 2014 15:13:19 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403211501.s2LF171x005077@aurora.sol.net> References: <201403211501.s2LF171x005077@aurora.sol.net> Message-ID: <1B74B2F6-FCB1-41BC-8D65-5F32AD3B5F41@puck.nether.net> On Mar 21, 2014, at 11:01 AM, Joe Greco wrote: > Why wouldn't you instead charge for the build out as a NRC and then charge > for maintenance as a MRC? I for one would be willing to bear a high NRC start-up cost for someone building fiber to my home. Not everyone would make that tradeoff. I know people who trade between the two local DSL/DOCSIS incumbents every year because it's $5 cheaper/mo to get the next 12-month deal as a switcher. While their time may not be worth ($5*12)/hour to account for this minimal switching cost, it's certainly a real economic cost if you're waiting for a 4 hour window for a tech to show-up and do an install. aside: I recently got natural gas at my home, the install cost was something like $2k, the utility had an option, pay an extra $27/mo for however many months, or pay the $2k up-front. Some folks can't absorb a cost like that, others can. I've heard from FTTH providers their install cost is in that same ballpark. Really wish they would have been able to pull fiber at the same time as the HDPE. The fact that it was a contractor as well certainly means they could run a side-business building their own fiber using the other utility as the main seed-money and have a wholesale fiber network for "cheap". - Jared From no.spam at comcast.net Fri Mar 21 19:21:17 2014 From: no.spam at comcast.net (Keegan Holley) Date: Fri, 21 Mar 2014 15:21:17 -0400 Subject: competition (was: Level 3 blames Internet slowdowns on Technica) In-Reply-To: <211073AE-9395-4025-9423-A78DA762CD39@puck.nether.net> References: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> <211073AE-9395-4025-9423-A78DA762CD39@puck.nether.net> Message-ID: On Mar 21, 2014, at 2:21 PM, Jared Mauch wrote: > > On Mar 21, 2014, at 2:08 PM, Keegan Holley wrote: > >> How come no one ever asks if competition is required? > > I think the issue here is there is competition, but those you are seen as competing with are in a different strata providing the same service. My question is competition and the market the goal at all? > > eg: Cellular data competes with DSL/DOCSIS/FTT* > > Now, due to speed, caps, etc.. it may not be a "fair" comparison, but this isn't about fair, it's about "is there competition in the market". I know many folks that live outside the wired high-speed boundaries and things are not getting any better there. Most use some hotspot or similar for their home connectivity. > > Is there a market for high speed there? certainly, but it's being filled by other technology. Again why is the market so important? The inhabitants of this list operate (some help develop) the most complex system created by our species to date. It is one of the few truly global systems and brought with it a new era in human development. We now have more information at our fingertips than at any point in history. What do we argue about? How to profit from it? I?m not saying that profit is bad. I?m arrogant but not arrogant enough to think I can answer such a question. It just fascinates me that no one questions it. If an area isn?t considered not to be profitable it?s just fine that the internet doesn?t stretch there. We don?t even have a definition of what profitable means. It?s completely up to the ISP?s. Still, businesses in that area are limited, children don?t do as well in school and in turn don?t have as much opportunity. All of this happens, unquestioned in the name of profits. > > There are many folks that work around these issues with other solutions, including satellite, fixed wireless and/or microwave or even localized fiber build-outs. Look at the RUS/NTIA/BTOP focus, it was on getting the anchor institutions well connected to provide a sense of community. The challenge is not everyone is equally equipped. Merit (in my area) has fiber close to me, but they don't offer services to anyone but existing members and have no consumer offerings. > > Market segmentation happens for a variety of reasons, sometimes economic, sometimes complete differences in ROI models. Market segmentation doesn?t happen as much as market consolidation. There are now three (with a 4th that is close) major carriers in the US with enough market share to compete with each other. There isn?t much segmentation because segmentation isn?t as profitable. > > Nobody can afford to run universal fiber everywhere as a greenfield build, but there are localized markets where it can make sense. That?s totally untrue. What is affordable to a multi-billion dollar ISP anyway? Are you saying they?d go bankrupt if they ran fiber everywhere? No, it?s just that the infrastructure isn?t profitable in the short term. There?s a reason why energy companies can?t make the same decision. > Certainly it can make sense to connect some islands to each other via some other technology. Taking list prices from providers webpages, what cogent used to list $4/meg, so that means (assuming everything is perfect) offering 10Mb/s service at a home could possibly cost $40/mo for a provider, not counting capital costs and other elements (support, customer acquisition costs, bad debt, etc). > > I'm sure folks can build networks for low cost, you can get a 1G active-ethernet NID for sub-$150 with optics, but you still need to aggregate and account for it somewhere. Again why does everything have to move at the speed of profit? At least here in the US anything that could remotely benefit society is always first shot through the prism of profit and the so-called free market. Is a market with three major players and a 9-figure entry cost really free though? > > - Jared From owen at delong.com Fri Mar 21 19:24:42 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Mar 2014 12:24:42 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <1B74B2F6-FCB1-41BC-8D65-5F32AD3B5F41@puck.nether.net> References: <201403211501.s2LF171x005077@aurora.sol.net> <1B74B2F6-FCB1-41BC-8D65-5F32AD3B5F41@puck.nether.net> Message-ID: On Mar 21, 2014, at 12:13 , Jared Mauch wrote: > > On Mar 21, 2014, at 11:01 AM, Joe Greco wrote: > >> Why wouldn't you instead charge for the build out as a NRC and then charge >> for maintenance as a MRC? > > I for one would be willing to bear a high NRC start-up cost for someone building fiber to my home. Not everyone would make that tradeoff. I know people who trade between the two local DSL/DOCSIS incumbents every year because it's $5 cheaper/mo to get the next 12-month deal as a switcher. While their time may not be worth ($5*12)/hour to account for this minimal switching cost, it's certainly a real economic cost if you're waiting for a 4 hour window for a tech to show-up and do an install. > > aside: > > I recently got natural gas at my home, the install cost was something like $2k, the utility had an option, pay an extra $27/mo for however many months, or pay the $2k up-front. Some folks can't absorb a cost like that, others can. I've heard from FTTH providers their install cost is in that same ballpark. Really wish they would have been able to pull fiber at the same time as the HDPE. The fact that it was a contractor as well certainly means they could run a side-business building their own fiber using the other utility as the main seed-money and have a wholesale fiber network for "cheap". > > - Jared Which is why, in many cases, the most plausible solution is something like muni fiber where the infrastructure is rolled out as many initial public utility builds with tax dollars and/or government bonds, then operated on a cost-recovery basis where the costs considered include both operating and bond-repayment. All L2+ service providers are given equal pricing and access to any subscribers that choose to sign up. Nothing wrong with $27/month for 'however many months' so long as 'however many months' doesn't exceed about 9 years (108 months = 2,916, which I believe approximates reasonable interest for the period in question). If it's $27/month in perpetuity, however, then that's as disingenuous as cellular rates that include phones and is the kind of pricing distortion that people are complaining about. Owen From bill at herrin.us Fri Mar 21 20:12:07 2014 From: bill at herrin.us (William Herrin) Date: Fri, 21 Mar 2014 16:12:07 -0400 Subject: competition (was: Level 3 blames Internet slowdowns on Technica) In-Reply-To: References: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> <211073AE-9395-4025-9423-A78DA762CD39@puck.nether.net> Message-ID: On Fri, Mar 21, 2014 at 3:21 PM, Keegan Holley wrote: > Again why is the market so important? It just fascinates me > that no one questions it. Howdy, The impact of competition was extensively questioned and researched with respect to U.S. Government contracting rules in the early '80s. This led to the Competition in Contracting Act of 1984. Since then there's been the routine grumble about the lowest quality bidder and the periodic scandal involving a no-bid contract but no serious question about whether competition reduces cost and improves options. Unless the data starts to suggest otherwise, it's basically a settled matter. No one questions that the sky is blue either and few bother to learn why. Regards. Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Fri Mar 21 16:22:05 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 21 Mar 2014 11:22:05 -0500 (CDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <1B74B2F6-FCB1-41BC-8D65-5F32AD3B5F41@puck.nether.net> Message-ID: <201403211622.s2LGM57F005961@aurora.sol.net> > On Mar 21, 2014, at 11:01 AM, Joe Greco wrote: > > Why wouldn't you instead charge for the build out as a NRC and then = > charge=20 > > for maintenance as a MRC? > > I for one would be willing to bear a high NRC start-up cost for someone = > building fiber to my home. Not everyone would make that tradeoff. I was discussing the cost that the service provider had to pay in the context of a "$4/mo copper pair" for rental of a copper pair that the ILEC almost certainly did not need to install. I do not see why the cost for build out needs to be included in the actual monthly cost an ILEC needs to charge. I think that utilities have a long history of proving that the cost for build out can be successfully charged to the property owner in several ways as you note. I don't see it as being an insurmountable problem to find some way for an intermediate service provider to deal with this if needed. ... 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 jared at puck.nether.net Fri Mar 21 20:40:53 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Mar 2014 16:40:53 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403211622.s2LGM57F005961@aurora.sol.net> References: <201403211622.s2LGM57F005961@aurora.sol.net> Message-ID: On Mar 21, 2014, at 12:22 PM, Joe Greco wrote: >> On Mar 21, 2014, at 11:01 AM, Joe Greco wrote: >>> Why wouldn't you instead charge for the build out as a NRC and then = >> charge=20 >>> for maintenance as a MRC? >> >> I for one would be willing to bear a high NRC start-up cost for someone = >> building fiber to my home. Not everyone would make that tradeoff. > > I was discussing the cost that the service provider had to pay in the > context of a "$4/mo copper pair" for rental of a copper pair that the > ILEC almost certainly did not need to install. I do not see why the > cost for build out needs to be included in the actual monthly cost an > ILEC needs to charge. > > I think that utilities have a long history of proving that the cost > for build out can be successfully charged to the property owner in > several ways as you note. I don't see it as being an insurmountable > problem to find some way for an intermediate service provider to > deal with this if needed. Sure, but for POTS this installation NRC was regulated for residential (at least last time I ordered a POTS line for a home, which was ....) The cost of the O&M on the switch and OSP is likely less than what I pay them. The history was they were allowed to show costs and add on a margin and rate increases would be approved. I don't want to know what their costs are after ice storms... Here in Michigan there was a recent law passed to allow ending of service in areas starting January 2017. http://www.legislature.mi.gov/%28S%28la3cxz45kfy2bs55wvsiqy55%29%29/mileg.aspx?page=GetObject&objectname=2013-SB-0636 - Jared From web at typo.org Fri Mar 21 20:45:34 2014 From: web at typo.org (Wayne E Bouchard) Date: Fri, 21 Mar 2014 13:45:34 -0700 Subject: competition (was: Level 3 blames Internet slowdowns on Technica) In-Reply-To: References: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> <211073AE-9395-4025-9423-A78DA762CD39@puck.nether.net> Message-ID: <20140321204534.GA96093@wakko.typo.org> > The impact of competition was extensively questioned and researched > with respect to U.S. Government contracting rules in the early '80s. > This led to the Competition in Contracting Act of 1984. Since then > there's been the routine grumble about the lowest quality bidder and > the periodic scandal involving a no-bid contract but no serious > question about whether competition reduces cost and improves options. > Unless the data starts to suggest otherwise, it's basically a settled > matter. And that, of course, is that the government doesn't have to care about profit and loss nor quality of workmanship. If they don't like it, they just throw more money at it. A private entity, on the other hand, may cease to be a going concern if they don't weigh carefully who does work for them and how it is done. They also learn very quickly that lowest cost is not necessarily lowest cost because of the problem of compensating for shoddy work. Government doesn't have to learn this lesson, especially when palms are getting greased and spoils are being distributed. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From cidr-report at potaroo.net Fri Mar 21 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Mar 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201403212200.s2LM0031027240@wattle.apnic.net> This report has been generated at Fri Mar 21 21:13:54 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-03-14 493502 278241 15-03-14 493771 278155 16-03-14 493399 278396 17-03-14 493717 278296 18-03-14 493460 278694 19-03-14 493870 278807 20-03-14 494068 278914 21-03-14 494294 279204 AS Summary 46585 Number of ASes in routing system 19046 Number of ASes announcing only one prefix 3631 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A. 119786496 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'). --- 21Mar14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 495213 279252 215961 43.6% All ASes AS28573 3631 595 3036 83.6% NET Servi?os de Comunica??o S.A. AS6389 3012 56 2956 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2765 225 2540 91.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2981 907 2074 69.6% KIXS-AS-KR Korea Telecom AS18881 1917 25 1892 98.7% Global Village Telecom AS1785 2185 361 1824 83.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS36998 1637 66 1571 96.0% SDN-MOBITEL AS18566 2048 565 1483 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2936 1520 1416 48.2% TWTC - tw telecom holdings, inc. AS10620 2795 1430 1365 48.8% Telmex Colombia S.A. AS7303 1746 447 1299 74.4% Telecom Argentina S.A. AS4755 1840 625 1215 66.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 2229 1088 1141 51.2% TPG-INTERNET-AP TPG Telecom Limited AS7552 1229 122 1107 90.1% VIETEL-AS-AP Viettel Corporation AS22561 1304 241 1063 81.5% AS22561 - CenturyTel Internet Holdings, Inc. AS6983 1328 315 1013 76.3% ITCDELTA - ITC^Deltacom AS22773 2421 1426 995 41.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4808 1350 406 944 69.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9829 1604 677 927 57.8% BSNL-NIB National Internet Backbone AS24560 1124 297 827 73.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS18101 918 163 755 82.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7738 912 160 752 82.5% Telemar Norte Leste S.A. AS8151 1404 672 732 52.1% Uninet S.A. de C.V. AS701 1492 763 729 48.9% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS855 764 57 707 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6147 787 113 674 85.6% Telefonica del Peru S.A.A. AS4780 1031 366 665 64.5% SEEDNET Digital United Inc. AS9808 952 308 644 67.6% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS4788 1000 360 640 64.0% TMNET-AS-AP TM Net, Internet Service Provider AS8551 952 316 636 66.8% BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone Total 52294 14672 37622 71.9% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc. 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 103.244.236.0/22 AS58794 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 151.216.128.0/17 AS50304 BLIX Blix Solutions AS 162.245.20.0/22 AS32329 MONKEYBRAINS - Monkey Brains 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics 163.227.2.0/23 AS10741 WAMNET - Wam Net Enterprises Inc. 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc. 172.85.0.0/24 AS29571 CITelecom-AS 172.85.1.0/24 AS29571 CITelecom-AS 172.85.2.0/24 AS29571 CITelecom-AS 172.85.3.0/24 AS29571 CITelecom-AS 172.86.0.0/24 AS29571 CITelecom-AS 172.86.1.0/24 AS29571 CITelecom-AS 172.86.2.0/24 AS29571 CITelecom-AS 172.87.0.0/24 AS29571 CITelecom-AS 172.88.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company 192.75.23.0/24 AS2579 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc. 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.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc. 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V. 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 192.241.20.0/24 AS7381 SASUSA SunGard Availability Services USA 192.241.21.0/24 AS7381 SASUSA SunGard Availability Services USA 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd 193.28.14.0/24 AS34309 LINK11 Link11 GmbH 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.33.106.0/23 AS42444 193.33.252.0/23 AS3356 LEVEL3 Level 3 Communications 193.36.229.0/24 AS15404 COLT Technology Services Group Limited 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd 193.84.187.0/24 AS16276 OVH OVH SAS 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS 193.111.229.0/24 AS3356 LEVEL3 Level 3 Communications 193.142.249.0/24 AS12389 ROSTELECOM-AS OJSC Rostelecom 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A. 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd. 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd. 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB 194.9.8.0/23 AS2863 SPRITELINK Centor AB 194.9.8.0/24 AS2863 SPRITELINK Centor AB 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd. 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.59.46.0/24 AS9145 EWETEL EWE TEL GmbH 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB 194.156.179.0/24 AS3209 VODANET Vodafone GmbH 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL 195.39.252.0/23 AS29004 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A 195.69.100.0/24 AS29174 195.69.101.0/24 AS29174 195.69.102.0/24 AS29174 195.69.103.0/24 AS29174 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.85.201.0/24 AS3356 LEVEL3 Level 3 Communications 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd 195.110.0.0/23 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.178.120.0/23 AS39385 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 196.2.224.0/22 AS24863 LINKdotNET-AS 196.3.182.0/24 AS37004 196.3.183.0/24 AS37004 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.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS SES WORLD SKIES ARIN AS, for routing RIPE space. 196.45.0.0/21 AS26625 196.45.10.0/24 AS26625 196.216.129.0/24 AS36886 196.216.130.0/24 AS36886 196.216.131.0/24 AS36886 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.72.78.0/23 AS3967 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc. 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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc. 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 199.30.138.0/24 AS23319 199.30.139.0/24 AS23319 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC 199.68.72.0/24 AS174 COGENT Cogent/PSI 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc. 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC 199.91.240.0/21 AS174 COGENT Cogent/PSI 199.116.200.0/21 AS22830 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.188.28.0/22 AS46802 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.0.0.0/16 AS7545 TPG-INTERNET-AP TPG Telecom Limited 203.83.16.0/21 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.16.96.0/24 AS19972 204.16.97.0/24 AS19972 204.16.98.0/24 AS19972 204.16.99.0/24 AS19972 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.164.0/22 AS46099 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.203.80.0/20 AS27021 216.203.80.0/21 AS27021 216.203.87.0/24 AS27021 216.203.88.0/21 AS27021 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 21 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Mar 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201403212200.s2LM01X6027254@wattle.apnic.net> BGP Update Report Interval: 13-Mar-14 -to- 20-Mar-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS27947 46087 1.8% 71.3 -- Telconet S.A 2 - AS8402 41741 1.6% 21.8 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS8895 34715 1.4% 445.1 -- ISU-RUH King Abdul Aziz City for Science and Technology 4 - AS29571 31864 1.2% 247.0 -- CITelecom-AS 5 - AS9829 28471 1.1% 37.2 -- BSNL-NIB National Internet Backbone 6 - AS4538 26142 1.0% 4.6 -- ERX-CERNET-BKB China Education and Research Network Center 7 - AS39382 24816 1.0% 12408.0 -- TRANCETELECOM-AS Trance Telecom Inc 8 - AS25184 24640 1.0% 191.0 -- AFRANET AFRANET Co. Tehran, Iran 9 - AS13118 22274 0.9% 655.1 -- ASN-YARTELECOM OJSC Rostelecom 10 - AS35819 22241 0.9% 46.6 -- MOBILY-AS Etihad Etisalat Company (Mobily) 11 - AS10620 21914 0.8% 11.7 -- Telmex Colombia S.A. 12 - AS41691 20880 0.8% 870.0 -- SUMTEL-AS-RIPE Summa Telecom LLC 13 - AS28573 20296 0.8% 11.6 -- NET Servi?os de Comunica??o S.A. 14 - AS3816 19672 0.8% 51.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 15 - AS7552 18536 0.7% 15.0 -- VIETEL-AS-AP Viettel Corporation 16 - AS4775 16099 0.6% 240.3 -- GLOBE-TELECOM-AS Globe Telecoms 17 - AS45169 15708 0.6% 1047.2 -- GLOBAL-DESCON-AS-AP Descon Limited 18 - AS17557 15362 0.6% 365.8 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 19 - AS24757 14874 0.6% 212.5 -- EthioNet-AS 20 - AS20450 14442 0.6% 7221.0 -- THL16-ASN - Trojan Hosting, LLC. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS39382 24816 1.0% 12408.0 -- TRANCETELECOM-AS Trance Telecom Inc 2 - AS18135 9894 0.4% 9894.0 -- BTV BTV Cable television 3 - AS6459 7809 0.3% 7809.0 -- TRANSBEAM - I-2000, Inc. 4 - AS20450 14442 0.6% 7221.0 -- THL16-ASN - Trojan Hosting, LLC. 5 - AS60270 7605 0.3% 3802.5 -- ASN-JUSTIS Justis- og beredskapsdepartementet 6 - AS16561 3418 0.1% 3418.0 -- ARIBANETWORK Ariba Inc. Autonomous System 7 - AS54465 8749 0.3% 2916.3 -- QPM-AS-1 - QuickPlay Media Inc. 8 - AS59217 2344 0.1% 2344.0 -- AZONNELIMITED-AS-AP Azonne Limited 9 - AS11976 13571 0.5% 1938.7 -- FIDN - Fidelity Communication International Inc. 10 - AS35463 3517 0.1% 1758.5 -- PSM-AS Pulawska Spoldzielnia Mieszkaniowa 11 - AS34 4089 0.2% 1363.0 -- UDELNET - University of Delaware 12 - AS50869 1281 0.1% 1281.0 -- AKVARIUSNET Akvarius Ltd. 13 - AS52482 1163 0.1% 1163.0 -- Aeprovi 14 - AS24733 1096 0.0% 1096.0 -- IPRI-AS Institute of Information Recording Problems of the National Academy of Science of Ukraine 15 - AS37367 1056 0.0% 1056.0 -- CALLKEY 16 - AS34232 1052 0.0% 1052.0 -- PULNET Pulnet Ltd 17 - AS45169 15708 0.6% 1047.2 -- GLOBAL-DESCON-AS-AP Descon Limited 18 - AS34912 11359 0.4% 946.6 -- IFN-AS INTERFUSION INET AS 19 - AS57143 920 0.0% 920.0 -- ABUDHABIUNIVERSITY Abu Dhabi University LLC 20 - AS41691 20880 0.8% 870.0 -- SUMTEL-AS-RIPE Summa Telecom LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22196 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 89.221.206.0/24 20780 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 3 - 121.52.144.0/24 15095 0.6% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 4 - 195.178.104.0/24 12409 0.5% AS39382 -- TRANCETELECOM-AS Trance Telecom Inc 5 - 195.178.105.0/24 12407 0.5% AS39382 -- TRANCETELECOM-AS Trance Telecom Inc 6 - 5.150.145.0/24 11266 0.4% AS34912 -- IFN-AS INTERFUSION INET AS 7 - 192.58.232.0/24 10347 0.4% AS6629 -- NOAA-AS - NOAA 8 - 42.83.48.0/20 9894 0.4% AS18135 -- BTV BTV Cable television 9 - 206.152.15.0/24 8731 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 10 - 78.109.192.0/20 8644 0.3% AS25184 -- AFRANET AFRANET Co. Tehran, Iran 11 - 66.210.60.0/24 8307 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC. 12 - 120.28.62.0/24 7812 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 13 - 205.247.12.0/24 7809 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 14 - 67.210.190.0/23 7680 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 15 - 222.127.0.0/24 7659 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 16 - 200.23.126.0/24 7396 0.3% AS8151 -- Uninet S.A. de C.V. 17 - 216.109.107.0/24 6834 0.2% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 18 - 74.231.237.0/24 6135 0.2% AS20450 -- THL16-ASN - Trojan Hosting, LLC. 19 - 67.210.188.0/23 5874 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 20 - 199.187.118.0/24 5709 0.2% AS11054 -- LIVEPERSON LivePerson, Inc Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From chad at xkl.com Fri Mar 21 23:13:13 2014 From: chad at xkl.com (Chad Lamb) Date: Fri, 21 Mar 2014 16:13:13 -0700 Subject: 100GBASE-SR10 interwork with 10GBASE-SR In-Reply-To: <392A074AA4FF0A459B45BFE734977F6933A84117@G1W3650.americas.hpqcorp.net> References: <392A074AA4FF0A459B45BFE734977F6933A84117@G1W3650.americas.hpqcorp.net> Message-ID: <532CC789.4060107@xkl.com> Steven, In general, there isn't much to worry about optically when interfacing 100GBASE-SR10 and 10GBASE-SR. If you are using CFP transceivers or CXP transceivers for the 100GBASE-SR10, your mileage may vary. For example, the Avago CXP AFBR-83PDZ has a transmit power range of -7.6dBm to 2.4dBm per lane. The Avago XFP AFBR-720XPDZ has an overload value of 1dBm on the receiver. We've observed errors when operating a device above the overload value. So attenuation is needed. There are "interoperable" devices from various vendors, making sure the optical interfaces do not need attenuation. I can provide more details offline, let me know what you are thinking about using. chad On 3/21/14, 7:54 AM, Lee, Steven (Network Consulting Malaysia) wrote: > Hi all, is there anyone who has experience the interworking 100GBASE-SR10 with 10GBASE-SR over 24-fiber ribbon cables terminated with MPO/MTP-24 connectors? > > If yes, any implementation consideration I should be aware? > > Regards, > Steven Lee The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From LarrySheldon at cox.net Sat Mar 22 01:54:27 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 21 Mar 2014 20:54:27 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <532BBFEA.70509@cox.net> Message-ID: <532CED53.6080709@cox.net> On 3/21/2014 9:13 AM, Sholes, Joshua wrote:> How do you get around the problem of natural monopolies, then? My strongly held belief is that if the "natural" monopoly* becomes oppressive somebody in their garage will find another way, and absent regulation and force of arms available to the "natural" monopoly, eliminate the monopoly situation and maybe the "natural" monopolist. Or should > we be moving to a world where, say, a dozen or more separate companies are > all running fiber or coax on the poles on my street in an effort to get to > my house? Could be--we have two energy companies at our house. And two communications companies have boxes on the back wall. Beyond the piped-in water service, we have several competing beverage sources (including for water) in service. The house across the street has, it appears, at least three companies providing TV service (and Internet service?). Three outfits provide waste disposal service in the neighborhood, although I am not bright enough to see a competitor for the sewage component. I wasn't bright enough to see the World Wide Web, either. Nobody uses poles. > IMHO, the only way to get real competition on the last mile is to have the > actual fiber/wire infrastructure being owned by a neutral party that's > required to pass anyone's traffic. As soon as "required" is in the discussion, we have a monopoly, and a monopoly has the power to abuse the situation. Wire and glass are not the only media available, as if that mattered. And we already have duplicates; what is the big deal? OH! And the reason why one set of wires is idle, is that provider got beat by the completion on the other set. (For this discussion, coaxial cable is a "set of wires".) *too old, failing memory and all, I'll have to go read up on "natural monopoly"--I can not think of one that does not require regulation and force of arms to exist. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From EWieling at nyigc.com Sat Mar 22 03:45:02 2014 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 21 Mar 2014 23:45:02 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <532CED53.6080709@cox.net> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> Message-ID: <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> Make the regulation and force of arms be as targeted as reasonable. In the case of telecommunications as targeted as reasonable means the "last mile" or, more correctly, the "local loop". I advocate stringent ongoing oversight and regulation of the local loop and very little regulation for the rest of the communications industry. If the incumbent telcos want to compete on equal footing in a free market then I invite them to give up their government granted right of ways to run their copper or fiber and compete on a level playing field. They will never do that and therefore the last mile can never be a free market. -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Friday, March 21, 2014 9:54 PM To: nanog at nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica *too old, failing memory and all, I'll have to go read up on "natural monopoly"--I can not think of one that does not require regulation and force of arms to exist. From bryan at digitalocean.com Sat Mar 22 06:03:08 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sat, 22 Mar 2014 02:03:08 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> Message-ID: There's no monopoly. Stop your lines with them and they are just fiber mpls. If they can't get people are changing and not peering with them, or refusing free ports its their bad. I'll take it up next week. Tell me what you all need. Bryan digitalocean. PS, were not ipv6 because we had to update for growth. 2 weeks you'll be happy. On Mar 21, 2014 11:46 PM, "Eric Wieling" wrote: > > Make the regulation and force of arms be as targeted as reasonable. In > the case of telecommunications as targeted as reasonable means the "last > mile" or, more correctly, the "local loop". I advocate stringent ongoing > oversight and regulation of the local loop and very little regulation for > the rest of the communications industry. > > If the incumbent telcos want to compete on equal footing in a free market > then I invite them to give up their government granted right of ways to run > their copper or fiber and compete on a level playing field. They will > never do that and therefore the last mile can never be a free market. > > > -----Original Message----- > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > Sent: Friday, March 21, 2014 9:54 PM > To: nanog at nanog.org > Subject: Re: Level 3 blames Internet slowdowns on Technica > > *too old, failing memory and all, I'll have to go read up on "natural > monopoly"--I can not think of one that does not require regulation and > force of arms to exist. > > > From bryan at digitalocean.com Sat Mar 22 07:07:27 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sat, 22 Mar 2014 03:07:27 -0400 Subject: Ipv4 end, its fake. Message-ID: As someone growing in the end of ipv4, its all fake. Sure, the rirs will run out, but that's boring. Don't believe the fake auction sites. Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no spam and $4 for legacy. Stop the inflation. Millions of IPS exist, there is no shortage and don't lie for rirs with IPS left. From trejrco at gmail.com Sat Mar 22 08:36:51 2014 From: trejrco at gmail.com (TJ) Date: Sat, 22 Mar 2014 04:36:51 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: Millions of IPs don't matter in the face of X billions of people, and XX-XXX billions of devices - and this is just the near term estimate. (And don't forget utilization efficiency - Millions of IPs is not millions of customers served.) Do IPv6. /TJ On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: > > As someone growing in the end of ipv4, its all fake. Sure, the rirs will > run out, but that's boring. Don't believe the fake auction sites. > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > there is no shortage and don't lie for rirs with IPS left. From bryan at digitalocean.com Sat Mar 22 09:25:58 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sat, 22 Mar 2014 05:25:58 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: Fair point. There are some situations that do need more than most, but aren't they the ones that should be on ipv6 already??????? I know a few are shouldn't I be on ipv6 and that's fair too. I'm plqnnning some speaking engagements to cover that. Its not blind and ignoring. On Mar 22, 2014 4:36 AM, "TJ" wrote: > Millions of IPs don't matter in the face of X billions of people, and > XX-XXX billions of devices - and this is just the near term estimate. > (And don't forget utilization efficiency - Millions of IPs is not > millions of customers served.) > > Do IPv6. > /TJ > > On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: > > > > As someone growing in the end of ipv4, its all fake. Sure, the rirs > will > > run out, but that's boring. Don't believe the fake auction sites. > > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for > no > > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > > there is no shortage and don't lie for rirs with IPS left. > From bryan at digitalocean.com Sat Mar 22 09:30:43 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sat, 22 Mar 2014 05:30:43 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: Oh btw, how many ipv4s are you hording with zero justification to keep them? I was unpopular during apricot for not liking the idea of no liability leasing of v4. I don't like this artificial v4 situation every eyeball network created. Why is v4 a commodity and asset? Where is the audits. I can justify my 6 /14s, can you still? On Mar 22, 2014 4:36 AM, "TJ" wrote: > Millions of IPs don't matter in the face of X billions of people, and > XX-XXX billions of devices - and this is just the near term estimate. > (And don't forget utilization efficiency - Millions of IPs is not > millions of customers served.) > > Do IPv6. > /TJ > > On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: > > > > As someone growing in the end of ipv4, its all fake. Sure, the rirs > will > > run out, but that's boring. Don't believe the fake auction sites. > > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for > no > > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > > there is no shortage and don't lie for rirs with IPS left. > From randy at psg.com Sat Mar 22 11:47:05 2014 From: randy at psg.com (Randy Bush) Date: Sat, 22 Mar 2014 20:47:05 +0900 Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: > As someone growing in the end of ipv4, its all fake. Sure, the rirs > will run out, but that's boring. yes, a lot of news at eleven. and there is and will continue to be a very active market as the large 'gas' in ipv4 space settles. but ... > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 > for no spam and $4 for legacy. is this supported by market data, or is it an assertion of what you think/wish the market should be. if the latter, do you have a track record in predicting markets? randy From cb.list6 at gmail.com Sat Mar 22 14:02:02 2014 From: cb.list6 at gmail.com (Cb B) Date: Sat, 22 Mar 2014 07:02:02 -0700 Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: On Mar 22, 2014 12:08 AM, "Bryan Socha" wrote: > > As someone growing in the end of ipv4, its all fake. Sure, the rirs will > run out, but that's boring. Don't believe the fake auction sites. > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > there is no shortage and don't lie for rirs with IPS left. That's cute that you think "millions" of ipv4 on the market solves anything for someone who "growing" end-points ... especially the VM business, you can only sell as many VMs as you have IPv4. Your business is tightly coupled to ipv4, so i understand you *want* to believe. You can pay $3 per ipv4, that is your business. But, it may be worth noting that AT&T, Verizon, Comcast, T-Mobile, TWT, Google Fiber all have have double digit ipv6 penetration today. Google, Yahoo, Wikipedia and Facebook all have v6 today, and Facebook is shifting to an ipv6-only data center https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf T-Mobile US is also close to 10% ipv6-only end-points a la rfc6877/464xlat today So, perhaps, what you are saying is, ipv4 address utility has peaked, the price is coming down due to supply/demand forces (less people need ipv4, so more are willing to sell, more sellers with less demand equals lower prices) That said, have a ball with that. I bet there is someone out there that is buying x.25 switches for pennies on the dollar by the pallet. But you may find that performance of ipv4-only service will struggle to get through transition mechansism that are rationing and ipv4 ports ...after all, google and facebook just work on v6, so your ipv4 quality issue may not bubble up so quick. CB From cb.list6 at gmail.com Sat Mar 22 14:11:16 2014 From: cb.list6 at gmail.com (Cb B) Date: Sat, 22 Mar 2014 07:11:16 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Mar 22, 2014 2:32 AM, "Bryan Socha" wrote: > > Oh btw, how many ipv4s are you hording with zero justification to keep > them? I was unpopular during apricot for not liking the idea of no > liability leasing of v4. I don't like this artificial v4 situation > every eyeball network created. Why is v4 a commodity and asset? Where > is the audits. I can justify my 6 /14s, can you still? You seem to be missing something, it is called Metcalfe's Law, google it. There is no long-term solution for you using ipv4 and me using ipv6. To derive value from the internet, we all need to be on one technology that supports end to end communication for us all. CB > On Mar 22, 2014 4:36 AM, "TJ" wrote: > > > Millions of IPs don't matter in the face of X billions of people, and > > XX-XXX billions of devices - and this is just the near term estimate. > > (And don't forget utilization efficiency - Millions of IPs is not > > millions of customers served.) > > > > Do IPv6. > > /TJ > > > > On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: > > > > > > As someone growing in the end of ipv4, its all fake. Sure, the rirs > > will > > > run out, but that's boring. Don't believe the fake auction sites. > > > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for > > no > > > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > > > there is no shortage and don't lie for rirs with IPS left. > > From tglassey at earthlink.net Sat Mar 22 14:18:45 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Sat, 22 Mar 2014 07:18:45 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <532CED53.6080709@cox.net> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> Message-ID: <532D9BC5.8020607@earthlink.net> I want to ask you folks something... How do you as the people operating the network think two exabytes of data gets pushed across your networks to each of the PRISM Collection Sites (daily) with no one noticing... Know what I mean>? Todd Glassey On 3/21/2014 6:54 PM, Larry Sheldon wrote: > On 3/21/2014 9:13 AM, Sholes, Joshua wrote:> How do you get around the > problem of natural monopolies, then? > > My strongly held belief is that if the "natural" monopoly* becomes > oppressive somebody in their garage will find another way, and absent > regulation and force of arms available to the "natural" monopoly, > eliminate the monopoly situation and maybe the "natural" monopolist. > > Or should > > we be moving to a world where, say, a dozen or more separate > companies are > > all running fiber or coax on the poles on my street in an effort to > get to > > my house? > > Could be--we have two energy companies at our house. And two > communications companies have boxes on the back wall. Beyond the > piped-in water service, we have several competing beverage sources > (including for water) in service. The house across the street has, it > appears, at least three companies providing TV service (and Internet > service?). Three outfits provide waste disposal service in the > neighborhood, although I am not bright enough to see a competitor for > the sewage component. I wasn't bright enough to see the World Wide > Web, either. > > > Nobody uses poles. > > > IMHO, the only way to get real competition on the last mile is to > have the > > actual fiber/wire infrastructure being owned by a neutral party that's > > required to pass anyone's traffic. > > As soon as "required" is in the discussion, we have a monopoly, and a > monopoly has the power to abuse the situation. > > Wire and glass are not the only media available, as if that mattered. > And we already have duplicates; what is the big deal? > > OH! And the reason why one set of wires is idle, is that provider got > beat by the completion on the other set. (For this discussion, > coaxial cable is a "set of wires".) > > *too old, failing memory and all, I'll have to go read up on "natural > monopoly"--I can not think of one that does not require regulation and > force of arms to exist. -- ------------- Personal Email - Disclaimers Apply From savage at savage.za.org Sat Mar 22 14:22:04 2014 From: savage at savage.za.org (Chris Knipe) Date: Sat, 22 Mar 2014 16:22:04 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Sat, Mar 22, 2014 at 11:30 AM, Bryan Socha wrote: > Oh btw, how many ipv4s are you hording with zero justification to keep > them? I was unpopular during apricot for not liking the idea of no > liability leasing of v4. I don't like this artificial v4 situation > every eyeball network created. Why is v4 a commodity and asset? Where > is the audits. I can justify my 6 /14s, can you still? Oh I so agree with this one. But alas yes, IPv4's days are counted and I doubt there's any turning back. As a NA myself, I see day on day where smaller ISPs are forced to dish out large network blocks (/16s) to be able to have access to large unefficiently planned broadband networks in order to service PPPoE terminations (at least, here in ZA). These ISPs are forced to 'hand out' /16 networks for the large telco's to distribute to their respective BRAS devices.... Meanwhile, the ISP does not even have 20K customers - nevermind the fact that more than likely 50% of that customer base is not even 'always' connected... It's due to waisting like this, that the shortage is there and that other players with legitimate requirements (such as going provider independant) cannot obtain address space. And it is continueing to this very day. I'm definately all for proper audits, stricter audits, and more importantly the releasing of unused address space back to the respective registries. -- Regards, Chris Knipe From rwebb at ropeguru.com Sat Mar 22 15:47:33 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Sat, 22 Mar 2014 11:47:33 -0400 Subject: misunderstanding scale In-Reply-To: References: Message-ID: <532DB095.9040801@ropeguru.com> So two things here, Bryan... First, there may be those that do not require IPv6 due to size. So what is YOUR big plan to connect all those on IPv4 to the rest of the IPv6 world that has dropped IPv4 addresses. Second, as a DO customer, I am now beginning to understand the culture and ideology over IPv6 at DO. IPv6 has been asked about since at least 2012 with initial promises of 'Q3 2012 the 'Q4, now no one even wants to respond. With everyone else bringing native IPv6 on board, I see people starting to leave unless you change. Additional support on my feeling of DO and IPv6, is DO's stance of directly not even allowing IPv6 tunnels to HE, SiXXs, or any of the other providers by specifically teliing them not to allow connections from your IPv4 address space. Good luck on your IPv4 ride when none of your customers have anyone else to talk to. Robert Apologies to all other list members for the somewhat off topic rant. On 03/22/2014 05:25 AM, Bryan Socha wrote: > Fair point. There are some situations that do need more than most, but > aren't they the ones that should be on ipv6 already??????? > > I know a few are shouldn't I be on ipv6 and that's fair too. I'm > plqnnning some speaking engagements to cover that. Its not blind and > ignoring. > On Mar 22, 2014 4:36 AM, "TJ" wrote: > >> Millions of IPs don't matter in the face of X billions of people, and >> XX-XXX billions of devices - and this is just the near term estimate. >> (And don't forget utilization efficiency - Millions of IPs is not >> millions of customers served.) >> >> Do IPv6. >> /TJ >> >> On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: >>> As someone growing in the end of ipv4, its all fake. Sure, the rirs >> will >>> run out, but that's boring. Don't believe the fake auction sites. >>> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for >> no >>> spam and $4 for legacy. Stop the inflation. Millions of IPS exist, >>> there is no shortage and don't lie for rirs with IPS left. From dougb at dougbarton.us Sat Mar 22 16:29:18 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 22 Mar 2014 09:29:18 -0700 Subject: misunderstanding scale In-Reply-To: <532DB095.9040801@ropeguru.com> References: <532DB095.9040801@ropeguru.com> Message-ID: <532DBA5E.9090800@dougbarton.us> On 03/22/2014 08:47 AM, Robert Webb wrote: > First, there may be those that do not require IPv6 due to size. It is a mistake to believe that the only reason to add IPv6 to your network is size. Adding IPv6 to your network _now_ is the right decision because at some point in the not-too-distant future it will be the dominant network technology, and you don't want to get left behind. Doug From mpetach at netflight.com Sat Mar 22 16:46:25 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 22 Mar 2014 09:46:25 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <532D9BC5.8020607@earthlink.net> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> <532D9BC5.8020607@earthlink.net> Message-ID: On Sat, Mar 22, 2014 at 7:18 AM, TGLASSEY wrote: > I want to ask you folks something... > > How do you as the people operating the network think two exabytes of data > gets pushed across your networks to each of the PRISM Collection Sites > (daily) with no one noticing... Know what I mean>? > > Todd Glassey > > > I'm sure you're aware there's no such thing as "the network". There are thousands of individual networks, with no high level correlation happening between them. It's trivially easy for an entity wanting to stay somewhat inconspicuous to buy a few dozen waves from provider A, another bunch from provider B, another bunch from provider C, etc. At the end of the day, they've amassed a significant chunk of bandwidth; but unless the providers all get together and start comparing customer lists, circuit locations, delivery dates, etc. nobody is going to realize that all the small individual orders add up to one very big monitoring and collection infrastructure. Thanks! Matt PS--unless my math is off the mark, 2 exabytes a day works out to less than 200Gbps sustained. Even allowing for uneven distribution across the day, a 1Tbps network is almost trivial to build these days without incurring undue notice from providers, especially if you split it across 3 or 4 providers. From nick at foobar.org Sat Mar 22 17:16:48 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 22 Mar 2014 17:16:48 +0000 Subject: misunderstanding scale In-Reply-To: <532DBA5E.9090800@dougbarton.us> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> Message-ID: <532DC580.8060901@foobar.org> On 22/03/2014 16:29, Doug Barton wrote: > It is a mistake to believe that the only reason to add IPv6 to your network > is size. Adding IPv6 to your network _now_ is the right decision because at > some point in the not-too-distant future it will be the dominant network > technology, and you don't want to get left behind. not wanting to rain on anyone's parade, but people have been claiming this since the days of IPng. Granted, we're a couple of years after IANA runout and two RIRs are also in post-runout phase, but the level of pain associated with continued deployment of ipv4-only services is still nowhere near the point that ipv6 can be considered a viable alternative. Nick From frnkblk at iname.com Sat Mar 22 17:24:15 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 22 Mar 2014 12:24:15 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> Message-ID: <002501cf45f3$8c7ac7e0$a57057a0$@iname.com> It's my understanding and experience that most gov't jurisdictions will give CLECs and other telecommunication providers access to the RoW -- generally speaking it's not exclusive to ILECs or MSOs. Now the challenge may be finding room in the existing RoW for another provider, but the challenges are not typically politically or "regulatorily" motivated. Frank -----Original Message----- From: Eric Wieling [mailto:EWieling at nyigc.com] Sent: Friday, March 21, 2014 10:45 PM To: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Make the regulation and force of arms be as targeted as reasonable. In the case of telecommunications as targeted as reasonable means the "last mile" or, more correctly, the "local loop". I advocate stringent ongoing oversight and regulation of the local loop and very little regulation for the rest of the communications industry. If the incumbent telcos want to compete on equal footing in a free market then I invite them to give up their government granted right of ways to run their copper or fiber and compete on a level playing field. They will never do that and therefore the last mile can never be a free market. -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Friday, March 21, 2014 9:54 PM To: nanog at nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica *too old, failing memory and all, I'll have to go read up on "natural monopoly"--I can not think of one that does not require regulation and force of arms to exist. From streiner at cluebyfour.org Sat Mar 22 14:33:51 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 22 Mar 2014 10:33:51 -0400 (EDT) Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Sat, 22 Mar 2014, Bryan Socha wrote: > Oh btw, how many ipv4s are you hording with zero justification to keep > them? I was unpopular during apricot for not liking the idea of no > liability leasing of v4. I don't like this artificial v4 situation > every eyeball network created. Why is v4 a commodity and asset? Where > is the audits. I can justify my 6 /14s, can you still? That ship sailed a long time time ago. Can some IPv4 space be recovered by 'auditing' consumers of IPv4? Possibly. Does the amount of space that would be recovered justify the effort (economic, administrative, legal, technical)? No. IPv6 is the way to go. All of these 'Hail Mary' options for 'saving' IPv4 really are pointless. Don't forget that IPv4, in the form we know it, was never intended to go into production. It's a lab experiment that grew legs and got out of its cage. jms > On Mar 22, 2014 4:36 AM, "TJ" wrote: > >> Millions of IPs don't matter in the face of X billions of people, and >> XX-XXX billions of devices - and this is just the near term estimate. >> (And don't forget utilization efficiency - Millions of IPs is not >> millions of customers served.) >> >> Do IPv6. >> /TJ >> >> On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: >>> >>> As someone growing in the end of ipv4, its all fake. Sure, the rirs >> will >>> run out, but that's boring. Don't believe the fake auction sites. >>> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for >> no >>> spam and $4 for legacy. Stop the inflation. Millions of IPS exist, >>> there is no shortage and don't lie for rirs with IPS left. >> > From streiner at cluebyfour.org Sat Mar 22 14:40:41 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 22 Mar 2014 10:40:41 -0400 (EDT) Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: On Sat, 22 Mar 2014, Cb B wrote: > You can pay $3 per ipv4, that is your business. But, it may be worth noting > that AT&T, Verizon, Comcast, T-Mobile, TWT, Google Fiber all have have > double digit ipv6 penetration today. To be fair: Verizon Wireless, if you're referring to 4G LTE? Agreed. I don't know what the plan is for the remaining 3G services. Verizon Enterprise (what used to be UUNET)? Agreed. Verizon Online (Fios, DSL)? I have to disagree. Lots of foot-dragging here. Most carriers appear to be making IPv6 capability a requirement for their LTE buildouts. The only major US carrier that I hears was resisting IPv6 was Sprint, and I don't know if their position has changed in the past 12 months. jms From bill at herrin.us Sat Mar 22 17:57:42 2014 From: bill at herrin.us (William Herrin) Date: Sat, 22 Mar 2014 13:57:42 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Sat, Mar 22, 2014 at 10:33 AM, Justin M. Streiner wrote: > All of these 'Hail Mary' options for 'saving' IPv4 really are pointless. Hi Justin, IPv4 is like the U.S. Penny. It'll be useless long before it goes away. And right now it's far from useless. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From george.herbert at gmail.com Sat Mar 22 17:58:57 2014 From: george.herbert at gmail.com (George William Herbert) Date: Sat, 22 Mar 2014 10:58:57 -0700 Subject: misunderstanding scale In-Reply-To: <532DC580.8060901@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> Message-ID: <7E234BF1-D150-40A5-A94A-52CFE57C2E15@gmail.com> On Mar 22, 2014, at 10:16 AM, Nick Hilliard wrote: > On 22/03/2014 16:29, Doug Barton wrote: >> It is a mistake to believe that the only reason to add IPv6 to your network >> is size. Adding IPv6 to your network _now_ is the right decision because at >> some point in the not-too-distant future it will be the dominant network >> technology, and you don't want to get left behind. > > not wanting to rain on anyone's parade, but people have been claiming this > since the days of IPng. Granted, we're a couple of years after IANA runout > and two RIRs are also in post-runout phase, but the level of pain > associated with continued deployment of ipv4-only services is still nowhere > near the point that ipv6 can be considered a viable alternative. > > Nick We've always told everyone the pain would be starting in the runout phase. Not immediately like a wall, but gradually. Some people I know are already experiencing scarcity itches. One or two, some uncomfortable burning sensations. This will ramp up over time. ISPs around you will get their last blocks from ARIN or other RIRs as the last RIRs exhaust soon; then the ISP blocks will be gone. Timescales for each of these phases will be months. There will be M&A or open market recovery of currently unused space for a while longer. With consumers seeing the inevitable slowly increasing markups in price for the new resources. Then the serious global pain starts... It is true that a head in the sand was effective for 15 years. But you'd better pull it out now. Each of these phases is well understood *and we're here now*... -george william herbert george.herbert at gmail.com Sent from Kangphone From tore at fud.no Sat Mar 22 18:50:33 2014 From: tore at fud.no (Tore Anderson) Date: Sat, 22 Mar 2014 19:50:33 +0100 Subject: misunderstanding scale In-Reply-To: <532DC580.8060901@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> Message-ID: <532DDB79.50808@fud.no> * Nick Hilliard > the level of pain > associated with continued deployment of ipv4-only services is still nowhere > near the point that ipv6 can be considered a viable alternative. This depends on who you're asking; as a blanket statement it's demonstrably false: For the likes of T-Mobile USA? and Facebook?, or even myself?, IPv6-only isn't just an ?alternative?. It's ?happening?. [1] http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 [2] https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf [3] http://www.ipspace.net/IPv6-Only_Data_Centers Tore From streiner at cluebyfour.org Sat Mar 22 15:54:06 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 22 Mar 2014 11:54:06 -0400 (EDT) Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Sat, 22 Mar 2014, William Herrin wrote: > On Sat, Mar 22, 2014 at 10:33 AM, Justin M. Streiner > wrote: >> All of these 'Hail Mary' options for 'saving' IPv4 really are pointless. > > IPv4 is like the U.S. Penny. It'll be useless long before it goes > away. And right now it's far from useless. Bill: Interesting analogy, but it misses the larger point. The larger point is that the ongoing effort to squeeze more mileage out of IPv4 will soon [1] outweigh the mileage we (collectively) get out of it. IMHO, that effort is better invested in preparing for and deplying IPv6. Things like LSN/CGN are stop-gaps that result in performance problems for people behind them, and aren't terribly useful for people who need to run inbound services. Shaking down entities (to the extent that they can be shaken down) that have chunks of IPv4 they're not currently using doesn't change the end-game for IPv4. I'm not saying that there aren't challenges to deploying IPv6. There are. Like many of the people on this list, I run a network, and I'm familiar with many of those challenges. If a network makes a conscious decision *not* to deploy IPv6, that is certainly their choice, and they will have to live with the consequences and will have to justify that decision to their customers. [1] - For varying values of "soon". jms From kmedcalf at dessus.com Sat Mar 22 19:16:06 2014 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 22 Mar 2014 13:16:06 -0600 Subject: =?utf-8?B?UkU6IExldmVsIDMgYmxhbWVzIEludGVybmV0IHNsb3dkb3ducyBvbiBJU1Bz?= =?utf-8?B?4oCZIHJlZnVzYWwgdG8gdXBncmFkZSBuZXR3b3JrcyB8IEFycyBUZWNobmlj?= =?utf-8?B?YQ==?= In-Reply-To: <532AF83A.8010805@ispn.net> Message-ID: <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> >I don't see this as a technical problem, but one of business and ethics. >ISP X advertises/sells customers "up to 8Mbps" (as an example), but when >it comes to delivering that product, they've only guaranteed 512Kbps (if >any) because the ISP hasn't put in the infrastructure to support 8Mbps >per customer. Customer believes he/she has 8Mbps, Content provider says >we provide 8Mbps content, but ISP can (theoretically and in practice) >only deliver a fraction of that. That feels like false advertising to me. The problem is that the consumer is too stupid to own a computer and use a network. The consumer purchased a product advertized as "up to 8Mbps" but really wanted "not less than 8Mbps". It is not false advertizing. What was delivered is exactly what was advertized and exactly what was purchased. From mark.tinka at seacom.mu Sat Mar 22 19:17:58 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 22 Mar 2014 21:17:58 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: <201403222118.01172.mark.tinka@seacom.mu> On Saturday, March 22, 2014 05:54:06 PM Justin M. Streiner wrote: > Interesting analogy, but it misses the larger point. The > larger point is that the ongoing effort to squeeze more > mileage out of IPv4 will soon [1] outweigh the mileage > we (collectively) get out of it. IMHO, that effort is > better invested in preparing for and deplying IPv6. > Things like LSN/CGN are stop-gaps that result in > performance problems for people behind them, and aren't > terribly useful for people who need to run inbound > services. Shaking down entities (to the extent that > they can be shaken down) that have chunks of IPv4 > they're not currently using doesn't change the end-game > for IPv4. And to keep into perspective, the fact that a good portion of the registry community have run out of IPv4 space to allocate. A number of existing and new ISP's are going to find that getting IPv6 going is probably a better solution than keeping IPv4 alive (many will learn this the hard way). Heck, it won't surprise me if some popular OTT and social networking providers "force" the IPv6 issue since democracy isn't often the best way to get something like this done. In such a case, where you are still pushing the case for IPv4, how do you envisage things will look on your side when everybody else you want to talk to is either on IPv6, or frantically getting it turned up? Do you reckon anyone will have time to help you troubleshoot patchy (for example) IPv4 connectivity when all the focus is on IPv6? AFRINIC still have lots of IPv4 space. I'm not sure that gives operators in that region any advantage over anyone else, if the rest of the world is active on IPv6, i.e., while it may be easier to justify a /8 of IPv4 and get it from a registry that still has space, you're likely doing yourself a disservice in taking this route (and spending all the time and energy numbering out of that /8), because that /8 won't be very helpful if the most of the rest of the Internet is letting IPv4 go. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bill at herrin.us Sat Mar 22 19:36:06 2014 From: bill at herrin.us (William Herrin) Date: Sat, 22 Mar 2014 15:36:06 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Sat, Mar 22, 2014 at 11:54 AM, Justin M. Streiner wrote: > On Sat, 22 Mar 2014, William Herrin wrote: >> On Sat, Mar 22, 2014 at 10:33 AM, Justin M. Streiner >> wrote: >>> >>> All of these 'Hail Mary' options for 'saving' IPv4 really are pointless. >> >> >> IPv4 is like the U.S. Penny. It'll be useless long before it goes >> away. And right now it's far from useless. > > Interesting analogy, but it misses the larger point. The larger point is > that the ongoing effort to squeeze more mileage out of IPv4 will soon [1] > outweigh the mileage we (collectively) get out of it. Hi Justin, That's what I hear. Interesting thing though: it hasn't happened yet. IANA ran out of /8's and it didn't happen. The RIRs dropped to high-conservation mode on their final allocations and it didn't happen. How could that be? In completely unrelated news, placard-bearing lunatics on the streets of New York City report that The End Is Nigh... for most of the last century. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From niels=nanog at bakker.net Sat Mar 22 19:52:01 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 22 Mar 2014 20:52:01 +0100 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420C20@MUNPRDMBXA1.medline.com> References: <201403211635.04659.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B541F788@MUNPRDMBXA1.medline.com> <201403211700.42920.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B5420C20@MUNPRDMBXA1.medline.com> Message-ID: <20140322195201.GB36211@burnout.tpb.net> * SNaslund at medline.com (Naslund, Steve) [Fri 21 Mar 2014, 17:00 CET]: >I see no reason why the US model would not work in any market economy. Why would market economies switch to the US model? Consumers there pay a lot more for much less performance. -- Niels. From johnl at iecc.com Sat Mar 22 19:57:04 2014 From: johnl at iecc.com (John Levine) Date: 22 Mar 2014 19:57:04 -0000 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <201403222118.01172.mark.tinka@seacom.mu> Message-ID: <20140322195704.15285.qmail@joyce.lan> >In such a case, where you are still pushing the case for >IPv4, how do you envisage things will look on your side when >everybody else you want to talk to is either on IPv6, or >frantically getting it turned up? Do you reckon anyone will >have time to help you troubleshoot patchy (for example) IPv4 >connectivity when all the focus is on IPv6? I've put that concern on my calendar for sometime around 2025. People have been saying switch to IPv6 now Now NOW for about a decade, and you can only cry wolf so many times. My servers do IPv6 through a tunnel from HE (thanks!) where the performance is only somewhat worse than the native v4, and my home cable has v6 that mostly works, but the key term there is mostly. (The ISP had a fairly bad internal routing bug which apparently nobody noticed until I tracked down why my v6 connectivity was flaky, and I happened to know some senior people at the ISP who could understand what I was telling them about their internal routers.) We've just barely started to move from the era of free IPv4 to the one where you have to buy it, and from everyhing I see, there is vast amounts of space that will be available once people realize they can get real money for it. The prices cited a couple of messages back seem to be in the ballpark. It will be a long time before the price of v4 rises high enough to make it worth the risk of going v6 only. R's, John From randy at psg.com Sat Mar 22 19:58:39 2014 From: randy at psg.com (Randy Bush) Date: Sun, 23 Mar 2014 04:58:39 +0900 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <20140322195201.GB36211@burnout.tpb.net> References: <201403211635.04659.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B541F788@MUNPRDMBXA1.medline.com> <201403211700.42920.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B5420C20@MUNPRDMBXA1.medline.com> <20140322195201.GB36211@burnout.tpb.net> Message-ID: > Why would market economies switch to the US model? Consumers there > pay a lot more for much less performance. stateside consumer internet is a third world country ruled by robber barons supported by a corrupt government. skip the politics and hyperbole and judge by the bottom line. at home in tokyo, i pay a bit over USD30/mo for real 100/100. randy From niels=nanog at bakker.net Sat Mar 22 19:58:51 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 22 Mar 2014 20:58:51 +0100 Subject: Level 3 blames Internet =?utf-8?Q?slow?= =?utf-8?Q?downs_on_ISPs?= =?utf-8?B?4oCZ?= refusal to upgrade networks | Ars Technica In-Reply-To: <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> Message-ID: <20140322195851.GC36211@burnout.tpb.net> * kmedcalf at dessus.com (Keith Medcalf) [Sat 22 Mar 2014, 20:16 CET]: > >The problem is that the consumer is too stupid to own a computer and use a network. That is a great attitude that will bring you far in life From ikiris at gmail.com Sat Mar 22 19:59:42 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 22 Mar 2014 14:59:42 -0500 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> Message-ID: I see this argument, and then I remember working for a company that happily sold 6 and 12 meg dsl from a dslam that was backhauled by a 3mb pair of t1s. There needs to be some oversight that it is at least possible / likely to reach a reasonable expectation of normal destinations with the service limits you were sold. -Blake On Mar 22, 2014 12:17 PM, "Keith Medcalf" wrote: > > >I don't see this as a technical problem, but one of business and ethics. > >ISP X advertises/sells customers "up to 8Mbps" (as an example), but when > >it comes to delivering that product, they've only guaranteed 512Kbps (if > >any) because the ISP hasn't put in the infrastructure to support 8Mbps > >per customer. Customer believes he/she has 8Mbps, Content provider says > >we provide 8Mbps content, but ISP can (theoretically and in practice) > >only deliver a fraction of that. That feels like false advertising to me. > > The problem is that the consumer is too stupid to own a computer and use a > network. > > The consumer purchased a product advertized as "up to 8Mbps" but really > wanted "not less than 8Mbps". > > It is not false advertizing. What was delivered is exactly what was > advertized and exactly what was purchased. > > > > > > > From streiner at cluebyfour.org Sat Mar 22 16:58:41 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 22 Mar 2014 12:58:41 -0400 (EDT) Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: On Sat, 22 Mar 2014, William Herrin wrote: > That's what I hear. Interesting thing though: it hasn't happened yet. > IANA ran out of /8's and it didn't happen. The RIRs dropped to > high-conservation mode on their final allocations and it didn't > happen. How could that be? I never said that things would get bad the instant that IANA ran out of space or your friendly neighborhood RIR reached the trigger point for their IPv4 exhaustion plans. Different RIRs have different consumption rates. There are also different pain points for different networks. A large .edu that has a big enough chunk of legacy IPv4 space to meet their needs for the next several years is in a different place than a large eyeball network that is deploying LSN/CGN to stretch what they have left because they can't go back to the well to get more. A large content/hosting provider who has customers that have different Internet reachability requirements where LSN/CGN doesn't help much has yet another different set of business drivers and pain points. > In completely unrelated news, placard-bearing lunatics on the streets > of New York City report that The End Is Nigh... for most of the last > century. I put my sandwich board away a long time ago. I'm too busy working on deploying IPv6 ;) jms From nick at foobar.org Sat Mar 22 21:05:35 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 22 Mar 2014 21:05:35 +0000 Subject: misunderstanding scale In-Reply-To: <532DDB79.50808@fud.no> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> Message-ID: <532DFB1F.7010805@foobar.org> On 22/03/2014 18:50, Tore Anderson wrote: > * Nick Hilliard >> the level of pain >> associated with continued deployment of ipv4-only services is still nowhere >> near the point that ipv6 can be considered a viable alternative. > > This depends on who you're asking; as a blanket statement it's > demonstrably false: For the likes of T-Mobile USA? and Facebook?, or > even myself?, IPv6-only isn't just an ?alternative?. It's ?happening?. FB, T-mobile and you are all using ipv6->ipv4 protocol translators because ipv6-only services are not a viable alternative at the moment. The advantage that using ipv6 gives in these deployment scenarios is that it scales beyond the amount of address space available from rfc1918. As a side effect, it also makes native end-to-end ipv6 connectivity pleasant. Sadly, ipv4 address availability continues to be necessary at the same run rate as before, except in situations where CGN is a possibility. Nick > [1] > http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 > [2] > https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf > [3] http://www.ipspace.net/IPv6-Only_Data_Centers > > Tore > From streiner at cluebyfour.org Sat Mar 22 19:35:53 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 22 Mar 2014 15:35:53 -0400 (EDT) Subject: misunderstanding scale In-Reply-To: <532DFB1F.7010805@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> Message-ID: On Sat, 22 Mar 2014, Nick Hilliard wrote: > FB, T-mobile and you are all using ipv6->ipv4 protocol translators because > ipv6-only services are not a viable alternative at the moment. Using IPv6 internally is different from being able to use IPv6 end-to-end. 6<->4 translators will be needed to reach the IPv4-only chunks of the Internet. I don't think anyone is disputing that. Traffic that can go IPv6 end-to-end can do so. > The advantage that using ipv6 gives in these deployment scenarios is that > it scales beyond the amount of address space available from rfc1918. As a > side effect, it also makes native end-to-end ipv6 connectivity pleasant. > > Sadly, ipv4 address availability continues to be necessary at the same run > rate as before, except in situations where CGN is a possibility. I think the expectation is that the utilization of those translators will plateau at some point, and then tail off as end-users go dual-stack or v6 only. Large/highly visible chunks of the Internet pushing IPv6 adoption helps get people toward the long-term goal of turning down those translators. Eventually those remaining pockets of IPv4ness will have to sit behind 4<->6 translators to be able to speak with the rest of the Internet. CGN also comes with lots of downside that customers are likely to find unpleasant. For some operators, customer (dis)satisfaction might be the driver that ultimately forces them to deploy IPv6. jms From nick at foobar.org Sat Mar 22 22:49:40 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 22 Mar 2014 22:49:40 +0000 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> Message-ID: <532E1384.1010209@foobar.org> On 22/03/2014 19:35, Justin M. Streiner wrote: > CGN also comes with lots of downside that customers are likely to find > unpleasant. For some operators, customer (dis)satisfaction might be the > driver that ultimately forces them to deploy IPv6. don't believe for a moment that v6 to v4 protocol translation is any less ugly than CGN. Nick From goemon at anime.net Sat Mar 22 22:17:36 2014 From: goemon at anime.net (goemon at anime.net) Date: Sat, 22 Mar 2014 15:17:36 -0700 (PDT) Subject: =?utf-8?B?UkU6IExldmVsIDMgYmxhbWVzIEludGVybmV0IHNsb3dkb3ducyBvbiBJU1Bz?= =?utf-8?B?4oCZIHJlZnVzYWwgdG8gdXBncmFkZSBuZXR3b3JrcyB8IEFycyBUZWNobmlj?= =?utf-8?B?YQ==?= In-Reply-To: <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> References: <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> Message-ID: On Sat, 22 Mar 2014, Keith Medcalf wrote: >> I don't see this as a technical problem, but one of business and ethics. >> ISP X advertises/sells customers "up to 8Mbps" (as an example), but when >> it comes to delivering that product, they've only guaranteed 512Kbps (if >> any) because the ISP hasn't put in the infrastructure to support 8Mbps >> per customer. Customer believes he/she has 8Mbps, Content provider says >> we provide 8Mbps content, but ISP can (theoretically and in practice) >> only deliver a fraction of that. That feels like false advertising to me. > > The problem is that the consumer is too stupid to own a computer and use a network. > > The consumer purchased a product advertized as "up to 8Mbps" but really wanted "not less than 8Mbps". > > It is not false advertizing. What was delivered is exactly what was advertized and exactly what was purchased. Up to includes 0. How close to 0 are you delivering on average? -Dan From streiner at cluebyfour.org Sat Mar 22 19:51:17 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 22 Mar 2014 15:51:17 -0400 (EDT) Subject: misunderstanding scale In-Reply-To: <532E1384.1010209@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> Message-ID: On Sat, 22 Mar 2014, Nick Hilliard wrote: > On 22/03/2014 19:35, Justin M. Streiner wrote: >> CGN also comes with lots of downside that customers are likely to find >> unpleasant. For some operators, customer (dis)satisfaction might be the >> driver that ultimately forces them to deploy IPv6. > > don't believe for a moment that v6 to v4 protocol translation is any less > ugly than CGN. True, but the ugliness of NAT64 and friends will decrease over time as more people go v6. The ugliness of IPv4 in general, and CGN/LSN will likely increase over time as people have to jump through more NAT hoops to reach an increasingly ugly/fragmented IPv4 Internet. jms From m.hallgren at free.fr Sat Mar 22 23:00:57 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Sun, 23 Mar 2014 00:00:57 +0100 Subject: misunderstanding scale In-Reply-To: <532E1384.1010209@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> Message-ID: <532E1629.4020502@free.fr> Le 22/03/2014 23:49, Nick Hilliard a ?crit : > On 22/03/2014 19:35, Justin M. Streiner wrote: >> CGN also comes with lots of downside that customers are likely to find >> unpleasant. For some operators, customer (dis)satisfaction might be the >> driver that ultimately forces them to deploy IPv6. > don't believe for a moment that v6 to v4 protocol translation is any less > ugly than CGN. Shared view. mh > > Nick > > From LarrySheldon at cox.net Sat Mar 22 23:38:23 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 22 Mar 2014 18:38:23 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> Message-ID: <532E1EEF.1040206@cox.net> On 3/22/2014 12:24 PM, Frank Bulk wrote: > It's my understanding and experience that most gov't jurisdictions will give > CLECs and other telecommunication providers access to the RoW -- generally > speaking it's not exclusive to ILECs or MSOs. Now the challenge may be > finding room in the existing RoW for another provider, but the challenges > are not typically politically or "regulatorily" motivated. IANAL I agree that the nasty gubbermint (much as I would rather be wrong here) has little to do with any of the RoW (Rights of Way) I know anything at all (precious little, it is) about. There are RoW and there are RoW. And the rules for each are different and codified (so far as I know) in the deed. There are railroad RoW granted in most case as a freebie from the gubbermint and over which the owning railroad has absolute control. There is the RoW around the perimeter of my property which is open it appears to me to any "utility". I don't know what all is in it here, but at a minimum it is the power company, the "telephone" company, and the "cable" company. I know of people whose property has no access to a public street and the owners thereof have a RoW across other people's property which right grants authority to build and maintain a roadway. There are power line and pipeline RoW where the owner has full rights to the surface as long as access to the facility involved is involved. Of course there are RoW owned and maintained by a variety of agencies for roadways and canals and I suppose they can be a little stuff about sharing. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From randy at psg.com Sun Mar 23 00:19:41 2014 From: randy at psg.com (Randy Bush) Date: Sun, 23 Mar 2014 09:19:41 +0900 Subject: misunderstanding scale In-Reply-To: <532E1384.1010209@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> Message-ID: > don't believe for a moment that v6 to v4 protocol translation is any less > ugly than CGN. it can be stateless randy From pauldotwall at gmail.com Sun Mar 23 01:45:39 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Sat, 22 Mar 2014 21:45:39 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <532D9BC5.8020607@earthlink.net> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> <532D9BC5.8020607@earthlink.net> Message-ID: On Sat, Mar 22, 2014 at 10:18 AM, TGLASSEY wrote: > How do you as the people operating the network think two exabytes of data > gets pushed across your networks to each of the PRISM Collection Sites > (daily) with no one noticing... Know what I mean? Wouldn't You Like To Know? drive slow... Paul From dougb at dougbarton.us Sun Mar 23 03:00:58 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 22 Mar 2014 20:00:58 -0700 Subject: misunderstanding scale In-Reply-To: <532DC580.8060901@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> Message-ID: <532E4E6A.6050701@dougbarton.us> On 03/22/2014 10:16 AM, Nick Hilliard wrote: > On 22/03/2014 16:29, Doug Barton wrote: >> It is a mistake to believe that the only reason to add IPv6 to your network >> is size. Adding IPv6 to your network _now_ is the right decision because at >> some point in the not-too-distant future it will be the dominant network >> technology, and you don't want to get left behind. > > not wanting to rain on anyone's parade, but people have been claiming this > since the days of IPng. Hyperbole of the past doesn't negate the reality of the future. :) The IPng folks did a lot of good things, and they made a lot of mistakes. For me personally the "not-to-distant future" part of the above paragraph is new, I have not (until recently) said to people that you'll need IPv6 *soon*, but I have consistently said to people that "You will need IPv6 eventually, so the sooner you start planning for it and moving forward the better off you'll be." > Granted, we're a couple of years after IANA runout > and two RIRs are also in post-runout phase, Another way to say that would be, "Things have been progressing exactly as predicted starting around say, 2005 or so." That's when I first got really enthusiastic about the IPv4 scarcity/promote IPv6 issues. Things have been playing out basically the way that they were predicted to when Tony Hain came to me (when I was IANA manager) with the first draft of his IPv4 runout projections. > but the level of pain > associated with continued deployment of ipv4-only services is still nowhere > near the point that ipv6 can be considered a viable alternative. With respect I think you're ignoring some pretty important facts. Not the least of which is the level of pressure that's been taken off of IPv4 runout by the large providers (referenced elsewhere in the thread) who have already moved to IPv6. I think you're also ignoring the fact that at this point unless you can afford to buy substantial address space on the darkish-grey market it's basically impossible to launch a new Internet enterprise of any real scale on IPv4. More importantly I'm confused/dismayed by your language, "still nowhere near the point that ipv6 can be considered a viable alternative." Even though the major content networks already have well-established IPv6 networks, referring to IPv6 as "an alternative" is thinking about the problem in the wrong way. As we all know, phases of technology adoption generally follow this model: All IPv4 Some IPv6, mostly IPv4 Roughly half and half Mostly IPv6, some IPv4 All IPv6 We're still in phase 2 now, but the other phases ARE coming. IPv4 addresses are a finite resource, and as the years go on there will simply not be enough to go around. (Arguably we've already passed that point, but things like CGN are going to let us slide along for a little longer.) So at this point IPv6 is not "an alternative," it's a complement to IPv4. "Doing" IPv6 now means that you'll be ready far in advance of the point when you no longer have a choice. Doug From mark.tinka at seacom.mu Sun Mar 23 04:36:31 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 06:36:31 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140322195704.15285.qmail@joyce.lan> References: <20140322195704.15285.qmail@joyce.lan> Message-ID: <201403230636.31419.mark.tinka@seacom.mu> On Saturday, March 22, 2014 09:57:04 PM John Levine wrote: > We've just barely started to move from the era of free > IPv4 to the one where you have to buy it, and from > everyhing I see, there is vast amounts of space that > will be available once people realize they can get real > money for it. The prices cited a couple of messages > back seem to be in the ballpark. It will be a long time > before the price of v4 rises high enough to make it > worth the risk of going v6 only. New ISP's are born everyday. Some of them will be able to have a "Buy an ISP that has IPv4" or "Buy IPv4 space from known brokers" line item in their budget as part of their launch plans. Most won't. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From cse332instructor at gmail.com Sun Mar 23 04:40:40 2014 From: cse332instructor at gmail.com (Kshitiz Verma) Date: Sun, 23 Mar 2014 10:10:40 +0530 Subject: Survey on Internet Disputes. Message-ID: Hi, I am Kshitiz Verma, a Ph.D. student in Madrid, Spain, working in the area of studies on the Internet ecosystem. We are conducting a survey on the Internet disputes, not limited to, but mainly focusing on de-peering. We will appreciate responses from the community that help us build our data on such incidences. We did an initial search ( https://docs.google.com/spreadsheet/ccc?key=0Ajn7QWBNzSlLdGo3UzFDVkNvdGVwYncxNUdJclZWcnc&usp=sharing#gid=0), but unfortunately the results we obtained were mostly limited to well known disputes in North America. We believe there should be more of them but are hard to find, 1. if they occur outside the Tier 1 regime. 2. if outside USA. 3. because the local news may not always be in English. 4. they may not last long or may not have as big an impact and find place in news. We are posting We are also looking for instances like Youtube hijacking by Pakistan Telecom is not a dispute between any two ASes but still for repairing purposes, connectivity between Pakistan Telecom and PCCW (AS 3491), Hong Kong was disrupted. At the same time, we are not looking for disruption of the Internet connectivity due to an accident like Taiwan earthquake in December 2006. As claimed in http://www.cs.columbia.edu/~misra/news/CD070113.pdf , 500 to 1000 de-peering happens on a daily basis today. We are curious to know how this number has evolved since its inception (starting from post commercialization of NSFNET is already very good but before that is excellent :-) ). Please fill in the following form if you have some information that you may want to share with us. Also, as there are so many de-peerings happening, there is a high possibility that most of these don't become International News, so to get information on these disputes we expanded our search to local and regional News but unfortunately this has not added significant information. Once the results are processed and filtered, we intend to share them publicly. Form: https://docs.google.com/forms/d/1X6msZeK0_3SIaIK8IxZaO2-Vrl1MPh_8dTSpbG0oGzY/viewform Many thanks in advance :-) Kshitiz Verma From johnl at iecc.com Sun Mar 23 05:10:37 2014 From: johnl at iecc.com (John Levine) Date: 23 Mar 2014 05:10:37 -0000 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <201403230636.31419.mark.tinka@seacom.mu> Message-ID: <20140323051037.94159.qmail@joyce.lan> >> It will be a long time >> before the price of v4 rises high enough to make it >> worth the risk of going v6 only. > >New ISP's are born everyday. > >Some of them will be able to have a "Buy an ISP that has >IPv4" or "Buy IPv4 space from known brokers" line item in >their budget as part of their launch plans. > >Most won't. In Africa, I suppose, but here in North America, the few remaining ISPs that aren't part of giant cable or phone companies are hanging on by their teeth. Also, although it is fashionable to say how awful CGN is, the users don't seem to mind it at all. R's, John From randy at psg.com Sun Mar 23 10:53:25 2014 From: randy at psg.com (Randy Bush) Date: Sun, 23 Mar 2014 19:53:25 +0900 Subject: arin representation Message-ID: two questions: o of the /24s in the arin region, what percentage are owned by arin members? o of the address holders in the arin region, what percentage are arin members? i understand that the latter will be slightly jittered because of the database mess with multiple org ids for one entity. but i suspect you can get close enough for government work. randy From randy at psg.com Sun Mar 23 10:53:25 2014 From: randy at psg.com (Randy Bush) Date: Sun, 23 Mar 2014 19:53:25 +0900 Subject: [ARIN-20140323.54] arin representation Message-ID: <1320082242.106957.1395578641379.JavaMail.undefined> two questions: o of the /24s in the arin region, what percentage are owned by arin members? o of the address holders in the arin region, what percentage are arin members? i understand that the latter will be slightly jittered because of the database mess with multiple org ids for one entity. but i suspect you can get close enough for government work. randy From blake at ispn.net Sun Mar 23 15:06:12 2014 From: blake at ispn.net (Blake Hudson) Date: Sun, 23 Mar 2014 10:06:12 -0500 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> Message-ID: <532EF864.30408@ispn.net> This is exactly my point. If a subscriber can use the service for 30 consecutive days and never achieve the "8Mbps" because the network is incapable by design, or by virtue of its over subscription is statistically impossible of delivering it, then I believe this is false advertising. I, and most others, accept that when a service is marketed as "up to", the service may not always deliver the "up to" number. But if the service is marketed as "up to" any number, then the service should at least be capable of delivering that advertised number some reasonable fraction of the time; Never is not a reasonable fraction of the time. --Blake Blake Dunlap wrote the following on 3/22/2014 2:59 PM: > I see this argument, and then I remember working for a company that happily > sold 6 and 12 meg dsl from a dslam that was backhauled by a 3mb pair of t1s. > > There needs to be some oversight that it is at least possible / likely to > reach a reasonable expectation of normal destinations with the service > limits you were sold. > > -Blake > On Mar 22, 2014 12:17 PM, "Keith Medcalf" wrote: > >>> I don't see this as a technical problem, but one of business and ethics. >>> ISP X advertises/sells customers "up to 8Mbps" (as an example), but when >>> it comes to delivering that product, they've only guaranteed 512Kbps (if >>> any) because the ISP hasn't put in the infrastructure to support 8Mbps >>> per customer. Customer believes he/she has 8Mbps, Content provider says >>> we provide 8Mbps content, but ISP can (theoretically and in practice) >>> only deliver a fraction of that. That feels like false advertising to me. >> The problem is that the consumer is too stupid to own a computer and use a >> network. >> >> The consumer purchased a product advertized as "up to 8Mbps" but really >> wanted "not less than 8Mbps". >> >> It is not false advertizing. What was delivered is exactly what was >> advertized and exactly what was purchased. >> >> >> >> >> >> >> From mark.tinka at seacom.mu Sun Mar 23 15:14:46 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 17:14:46 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323051037.94159.qmail@joyce.lan> References: <20140323051037.94159.qmail@joyce.lan> Message-ID: <201403231714.47374.mark.tinka@seacom.mu> On Sunday, March 23, 2014 07:10:37 AM John Levine wrote: > In Africa, I suppose, but here in North America, the few > remaining ISPs that aren't part of giant cable or phone > companies are hanging on by their teeth. Incidentally, this doesn't apply to Africa today, because AFRINIC still have lots of IPv4 space to feed any new entrant to their heart's content. I have mates in Asia-Pac, North America and Europe that will be the ones sweating if they are a new start-up. A friend recently started a mobile operation in Malaysia two years ago. You can imagine the problem they are having rolling out and scaling their 3G/3G data service. And if AFRINIC do run out of their IPv4 space, I can almost guarantee you that any new start-ups in Africa will NOT be able to have "IPv4 acquisition" line items in their budget. > Also, although it is fashionable to say how awful CGN is, > the users don't seem to mind it at all. Users won't complain until the CGN starts to do bad things to their traffic, like run out of Layer 4 ports per IP address due to increasing connectedness of applications, add delay to applications getting network, CGN failure, traffic tromboning e.t.c. Operators of CGN's will cry at some point. It's different for different operators, as some are happy throwing millions of CGN $$ at the problem. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From tore at fud.no Sun Mar 23 15:35:28 2014 From: tore at fud.no (Tore Anderson) Date: Sun, 23 Mar 2014 16:35:28 +0100 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323051037.94159.qmail@joyce.lan> References: <20140323051037.94159.qmail@joyce.lan> Message-ID: <532EFF40.3040404@fud.no> * John Levine > Also, although it is fashionable to say how awful CGN is, the users > don't seem to mind it at all. You might just be looking in the wrong places. Try searching for "playstation nat type 3" or "xbox strict nat". Tore From nick at foobar.org Sun Mar 23 16:13:40 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 23 Mar 2014 16:13:40 +0000 Subject: misunderstanding scale In-Reply-To: <532E4E6A.6050701@dougbarton.us> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> Message-ID: <532F0834.9030401@foobar.org> On 23/03/2014 03:00, Doug Barton wrote: > Hyperbole of the past doesn't negate the reality of the future. :) the past and present hyperbole continues to grate. > With respect I think you're ignoring some pretty important facts. Not > the least of which is the level of pressure that's been taken off of > IPv4 runout by the large providers (referenced elsewhere in the thread) > who have already moved to IPv6. it depends where you are in the world. Growing markets in China seem to have spurred on a good deal of development in terms of ipv6-only access, although getting hard data on this is difficult. We've seen a lot less of this in the ripe service region because the access markets peaked several years ago in many (but not all) countries. > I think you're also ignoring the fact > that at this point unless you can afford to buy substantial address > space on the darkish-grey market it's basically impossible to launch a > new Internet enterprise of any real scale on IPv4. yep, it is now very difficult for new market entrants in growing access markets. Africa in particular will be especially hosed from the point of view of ipv4 address availability in the long term, given its overall assignment of 6x /8s. > More importantly I'm confused/dismayed by your language, "still nowhere > near the point that ipv6 can be considered a viable alternative." Even > though the major content networks already have well-established IPv6 > networks A small number of the major content networks have done the internet proud by proving that enabling ipv6 does not substantially break things. But they are low hanging fruit and ultimately only a handful of companies; none of them has plans to disable ipv4 any time soon. > So at this point IPv6 is not "an alternative," it's a > complement to IPv4. "Doing" IPv6 now means that you'll be ready far in > advance of the point when you no longer have a choice. yep, agreed - doing ipv6 now is a sensible business proposition. But it needs to be tempered with the realisation that for nearly all networks, ipv6 is complementary to ipv4 and not a replacement; nor will it become a replacement until the time that people feel that adding A records to their hostnames is unnecessary. Nick From fergdawgster at mykolab.com Sun Mar 23 16:25:38 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 23 Mar 2014 09:25:38 -0700 Subject: misunderstanding scale In-Reply-To: <532F0834.9030401@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> Message-ID: <532F0B02.7090208@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/2014 9:13 AM, Nick Hilliard wrote: > yep, agreed - doing ipv6 now is a sensible business proposition. > But it needs to be tempered with the realisation that for nearly > all networks, ipv6 is complementary to ipv4 and not a replacement; > nor will it become a replacement until the time that people feel > that adding A records to their hostnames is unnecessary. Absolutely concur -- it's a really hard sell to enterprises in the U.S. for any compelling reason, at least right now, why they should take great pains (ad it would be *great* pain) to move to IPv6 while their IPv4 networks work just fine. Also, IPv6 introduces some serious security concerns, and until they are properly addressed, they will be a serious barrier to even considering it. $.02, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMvCwEACgkQKJasdVTchbJUkwD/eWydkUd7DE7XD9V5ETTENzsa fjuzzOR5l+t/0wE0EPYBANVVCYSBoFA7XeD5twSGDZcO+nvCK6BDwlRju9W+5iH5 =FBBN -----END PGP SIGNATURE----- From marka at isc.org Sun Mar 23 16:57:26 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 24 Mar 2014 03:57:26 +1100 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: Your message of "23 Mar 2014 05:10:37 -0000." <20140323051037.94159.qmail@joyce.lan> References: <20140323051037.94159.qmail@joyce.lan> Message-ID: <20140323165726.E2A2F11B18F1@rock.dv.isc.org> In message <20140323051037.94159.qmail at joyce.lan>, "John Levine" writes: > >> It will be a long time > >> before the price of v4 rises high enough to make it > >> worth the risk of going v6 only. > > > >New ISP's are born everyday. > > > >Some of them will be able to have a "Buy an ISP that has > >IPv4" or "Buy IPv4 space from known brokers" line item in > >their budget as part of their launch plans. > > > >Most won't. > > In Africa, I suppose, but here in North America, the few remaining > ISPs that aren't part of giant cable or phone companies are hanging on > by their teeth. > > Also, although it is fashionable to say how awful CGN is, the users > don't seem to mind it at all. Basically because none of them have ever been on the Internet proper where they can connect to their home machines from wherever they are in the world directly. If you don't know what it should be like you don't complain when you are not getting it. ISP's have done a good job of brain washing their customers into thinking that they shouldn't be able to run services from home. That all their machines shouldn't have a globally unique address that is theoritically reachable from everywhere. That NAT is normal and desiriable. I was at work last week and because I have IPv6 at both ends I could just log into the machines at home as easily as if I was there. When I'm stuck using a IPv4 only service on the road I have to jump through lots of hoops to reach the internal machines. Mark > R's, > John > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Sun Mar 23 18:09:46 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 20:09:46 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323165726.E2A2F11B18F1@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> Message-ID: <201403232009.47085.mark.tinka@seacom.mu> On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote: > ISP's have done a good job of brain washing their > customers into thinking that they shouldn't be able to > run services from home. That all their machines > shouldn't have a globally unique address that is > theoritically reachable from everywhere. That NAT is > normal and desiriable. > > I was at work last week and because I have IPv6 at both > ends I could just log into the machines at home as > easily as if I was there. When I'm stuck using a IPv4 > only service on the road I have to jump through lots of > hoops to reach the internal machines. I expect this to change little in the enterprise space. I think use of ULA and NAT66 will be one of the things enterprises will push for, because how can a printer have a public IPv6 address that is reachable directly from the Internet, despite the fact that there is a properly configured firewall at the perimetre offering half-decent protection? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bryan at digitalocean.com Sun Mar 23 18:27:11 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sun, 23 Mar 2014 14:27:11 -0400 Subject: misunderstanding scale In-Reply-To: <532DB095.9040801@ropeguru.com> References: <532DB095.9040801@ropeguru.com> Message-ID: > > First, there may be those that do not require IPv6 due to size. So what is > YOUR big plan to connect all those on IPv4 to the rest of the IPv6 world > that has dropped IPv4 addresses. > We'll be offering v6 standard really soon. It's growth that got in the way both from employee bandwidth and overrunning the point where certain routers couldn't handle doing more than v4 anymore. Both have been sorted out and we're very close, only 1 obscure junos bug we're vetting the impact. Once it's repaired or worked around we'll be launching the public beta. > > Second, as a DO customer, I am now beginning to understand the culture and > ideology over IPv6 at DO. IPv6 has been asked about since at least 2012 > with initial promises of 'Q3 2012 the 'Q4, now no one even wants to > respond. With everyone else bringing native IPv6 on board, I see people > starting to leave unless you change. > > You'll be very surprised at how much care, effort and loss of sleep has gone into it. > Additional support on my feeling of DO and IPv6, is DO's stance of > directly not even allowing IPv6 tunnels to HE, SiXXs, or any of the other > providers by specifically teliing them not to allow connections from your > IPv4 address space. > > There is tens of thousands of active tunnels to us right now and I have no clue what your referring to here. If you have more information on someone not allowed to run a tunnel to us, please get that information to me asap. Some datacenters are directly peered to HE to get better tunnel performance and we are exactly the opposite of your statement. Bryan From tagno25 at gmail.com Sun Mar 23 18:27:57 2014 From: tagno25 at gmail.com (Philip Dorr) Date: Sun, 23 Mar 2014 13:27:57 -0500 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <201403232009.47085.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> Message-ID: On Mar 23, 2014 1:11 PM, "Mark Tinka" wrote: > > On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote: > > > I was at work last week and because I have IPv6 at both > > ends I could just log into the machines at home as > > easily as if I was there. When I'm stuck using a IPv4 > > only service on the road I have to jump through lots of > > hoops to reach the internal machines. > > I expect this to change little in the enterprise space. I > think use of ULA and NAT66 will be one of the things > enterprises will push for, because how can a printer have a > public IPv6 address that is reachable directly from the > Internet, despite the fact that there is a properly > configured firewall at the perimetre offering half-decent > protection? That is what a firewall is for. Drop new inbound connections, allow related, and allow outbound. Then you allow specific IP/ports to have inbound traffic. You may also only allow outbound traffic for specific ports, or from your proxy. From laszlo at heliacal.net Sun Mar 23 18:30:21 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sun, 23 Mar 2014 18:30:21 +0000 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323165726.E2A2F11B18F1@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> Message-ID: <56747C3C-6094-4713-B37B-B2B71423F114@heliacal.net> On Mar 23, 2014, at 4:57 PM, Mark Andrews wrote: > > > Basically because none of them have ever been on the Internet proper > where they can connect to their home machines from wherever they > are in the world directly. If you don't know what it should be > like you don't complain when you are not getting it. > It's ironic that those of us that do understand this are mostly the same ones saying that it's ok to give 'the users' NAT. The reality is that some (many/most/all?) of our 'users' are probably smarter than us and they just get around it with VPNs/tunnels just like we do. Just because they aren't complaining directly to us, doesn't mean they are satisfied. Every gamer with a console is basically screwed - they have to jump through hoops trying to figure out how to forward ports or whatever else, because these home routers all give them NAT. We can probably argue cause/effect on this, but it's all tied together - those routers wouldn't have had to do NAT if they could somehow request unique numbers for each device.. but now carriers are doing that same NAT internally, because hey, 'the users' are already used to it anyway, from having done it on their home gateways. It's not that the users are ok with NAT, or that they prefer it, it's just all they can get. IPv6 is far from perfect, but it's a direct answer to the resource exhaustion problem. It seems unlikely that IPv4 will ever be dropped, but it can be made largely irrelevant by building out IPv6 networks. As far as the enterprise side of things, many of the people working in that area today have likely never known any other kind of network except the NAT kind. A lot of these guys say things like 'private ip' and 'public ip' - they've have this ingrained in them for the past 15+ years, and the idea of real internet is scary. I'm not sure how this problem of education is addressed, and it might sound stupid, but it's a real problem. The other side of things is that some software vendors with large market share are doing their own share of actively trying to undermine IPv6 deployment in subtle ways. You can read RFC6555 for the details. Just as an example, on Mac OS, users accessing a dual stack website from a dual stack host may not ever actually take the IPv6 path, so if there are people auditing how many clients are using v4 vs v6 they would get skewed results. I know everyone has their own parameters that define what's worth it and what's not, but I think most people's lives would be made easier by embracing IPv6. -Laszlo > ISP's have done a good job of brain washing their customers into > thinking that they shouldn't be able to run services from home. > That all their machines shouldn't have a globally unique address > that is theoritically reachable from everywhere. That NAT is normal > and desiriable. > > I was at work last week and because I have IPv6 at both ends I could > just log into the machines at home as easily as if I was there. > When I'm stuck using a IPv4 only service on the road I have to jump > through lots of hoops to reach the internal machines. > > Mark > >> R's, >> John >> >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From saku at ytti.fi Sun Mar 23 18:35:48 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 23 Mar 2014 20:35:48 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <201403232009.47085.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> Message-ID: <20140323183548.GA27838@pob.ytti.fi> On (2014-03-23 20:09 +0200), Mark Tinka wrote: > I expect this to change little in the enterprise space. I > think use of ULA and NAT66 will be one of the things > enterprises will push for, because how can a printer have a > public IPv6 address that is reachable directly from the > Internet, despite the fact that there is a properly > configured firewall at the perimetre offering half-decent > protection? Or IT isn't buying the 'renumbering is easy' argument, for any non-trivial size company even figuring how where exactly can be IP addresses punched out statically would be expensive and long process. If you are pushing for customer to use your PA in their LAN, I'm guessing net-result is you should never reclaim those addresses after customer leaves, since chances are, some customers won't renumber, but will 1:1 NAT your PA to new operator PA, and your next customer with this block will complain about reachability problems to this other customer. But at least we can hope it'll be 1:1 NAT + ULA, which I would suggest to my enterprise customers who won't want to get PI or become LIR. -- ++ytti From marka at isc.org Sun Mar 23 18:39:51 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 24 Mar 2014 05:39:51 +1100 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: Your message of "Sun, 23 Mar 2014 20:09:46 +0200." <201403232009.47085.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> Message-ID: <20140323183952.58ACE11B2B61@rock.dv.isc.org> In message <201403232009.47085.mark.tinka at seacom.mu>, Mark Tinka writes: > On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote: > > > ISP's have done a good job of brain washing their > > customers into thinking that they shouldn't be able to > > run services from home. That all their machines > > shouldn't have a globally unique address that is > > theoritically reachable from everywhere. That NAT is > > normal and desiriable. > > > > I was at work last week and because I have IPv6 at both > > ends I could just log into the machines at home as > > easily as if I was there. When I'm stuck using a IPv4 > > only service on the road I have to jump through lots of > > hoops to reach the internal machines. > > I expect this to change little in the enterprise space. I > think use of ULA and NAT66 will be one of the things > enterprises will push for, because how can a printer have a > public IPv6 address that is reachable directly from the > Internet, despite the fact that there is a properly > configured firewall at the perimetre offering half-decent > protection? > > Mark. Can I suggest that you re-read what I said. I did not say "WILL BE REACHABLE". I said "THEORETICALLY REACHABLE". I also said "GLOBAL UNIQUE" address not "PUBLIC ADDRESS". The point is one should be able to get addresses with these properties. It's your decision about whether to use all the properties the addresses have. As for printers directly reachable from anywhere, why not. We do have the technology to authenticate requests regardless of the IP address the request originates from. Whether that is built into your printer or not is a purchasing decision. I see nothing wrong with being able to print out something from the other side of the world for someone else to pick up. The cost to do this shoudn't amount to more than a couple of cents in the printer's price as it is all one off engineering. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Sun Mar 23 18:48:12 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 20:48:12 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232009.47085.mark.tinka@seacom.mu> Message-ID: <201403232048.12474.mark.tinka@seacom.mu> On Sunday, March 23, 2014 08:27:57 PM Philip Dorr wrote: > That is what a firewall is for. Drop new inbound > connections, allow related, and allow outbound. Then > you allow specific IP/ports to have inbound traffic. > You may also only allow outbound traffic for specific > ports, or from your proxy. How many enterprise installations do you know that favour firewall use for NAT rather than actual firewalling? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sun Mar 23 18:56:51 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 20:56:51 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <56747C3C-6094-4713-B37B-B2B71423F114@heliacal.net> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <56747C3C-6094-4713-B37B-B2B71423F114@heliacal.net> Message-ID: <201403232056.51385.mark.tinka@seacom.mu> On Sunday, March 23, 2014 08:30:21 PM Laszlo Hanyecz wrote: > As far as the enterprise side of things, many of the > people working in that area today have likely never > known any other kind of network except the NAT kind. A > lot of these guys say things like 'private ip' and > 'public ip' - they've have this ingrained in them for > the past 15+ years, and the idea of real internet is > scary. I'm not sure how this problem of education is > addressed, and it might sound stupid, but it's a real > problem. And to add to that, those of us that will welcome GUA IPv6 addresses in the home now have to find CPE that has decent firewall infrastructure that won't impact performance. Modern CPE do have some firewall features, but there is tons of emphasis on NAT and port forwarding. I'd hate to see CPE vendors focusing on NAT66 instead of proper firewall services that can scale with traffic. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sun Mar 23 19:02:05 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 21:02:05 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323183548.GA27838@pob.ytti.fi> References: <20140323051037.94159.qmail@joyce.lan> <201403232009.47085.mark.tinka@seacom.mu> <20140323183548.GA27838@pob.ytti.fi> Message-ID: <201403232102.05910.mark.tinka@seacom.mu> On Sunday, March 23, 2014 08:35:48 PM Saku Ytti wrote: > Or IT isn't buying the 'renumbering is easy' argument, > for any non-trivial size company even figuring how where > exactly can be IP addresses punched out statically would > be expensive and long process. > If you are pushing for customer to use your PA in their > LAN, I'm guessing net-result is you should never reclaim > those addresses after customer leaves, since chances > are, some customers won't renumber, but will 1:1 NAT > your PA to new operator PA, and your next customer with > this block will complain about reachability problems to > this other customer. In all fairness, I'm not so sure, as operators, that we want to push our PA space as assignments to customers in IPv6- land. Yes, it makes sense, but then again, it's not hard for enterprises to obtain PI space from $favorite_registry. Yes, that will pollute the routing table and potentially mean your customer can run away from you at any time. But IPv6 is so vast, and as you rightly point out, Saku, it might be unreasonable for us to expect the enterprise to renumber when they churn and take their business elsewhere. It, physically, is a lot of work. So while I have lots of /56's and /48's to assign to customers from my /32, I'm not sure I want to actively encourage it, unless as a last resort. Of course, assigning this to broadband users makes more sense, as use is generally temporary and well controlled. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mpetach at netflight.com Sun Mar 23 19:04:30 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 23 Mar 2014 12:04:30 -0700 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <532EF864.30408@ispn.net> References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> <532EF864.30408@ispn.net> Message-ID: On Sun, Mar 23, 2014 at 8:06 AM, Blake Hudson wrote: > This is exactly my point. If a subscriber can use the service for 30 > consecutive days and never achieve the "8Mbps" because the network is > incapable by design, or by virtue of its over subscription is statistically > impossible of delivering it, then I believe this is false advertising. I, > and most others, accept that when a service is marketed as "up to", the > service may not always deliver the "up to" number. But if the service is > marketed as "up to" any number, then the service should at least be capable > of delivering that advertised number some reasonable fraction of the time; > Never is not a reasonable fraction of the time. > > --Blake > So, you want something like EPA MPG ratings, where empirical, standardized testing is done to validate manufacturer/vendor claims, rather than just taking their word for it that the claimed speeds might once in a blue moon be achievable. with updates to the claimed performance if subsequent testing fails to validate the initial claims, such as with the ford c-max hybrid: http://yosemite.epa.gov/opa/admpress.nsf/bd4379a92ceceeac8525735900400c27/8a00bfd7633d548f85257bc800637d37!OpenDocument http://epa.gov/otaq/documents/fueleconomy/420f13044.pdf Doesn't sound too outlandish. Mind you, I'm sure it would raise costs, as that testing and validation wouldn't be free. But I'm sure we'd all be willing to pay an additional $10/month on our service to be sure it could deliver what was promised, or at least to ensure that what was promised was scaled down to match what could actually be delivered. Thanks! Matt From mark.tinka at seacom.mu Sun Mar 23 19:05:00 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 21:05:00 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323183952.58ACE11B2B61@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> Message-ID: <201403232105.01177.mark.tinka@seacom.mu> On Sunday, March 23, 2014 08:39:51 PM Mark Andrews wrote: > Can I suggest that you re-read what I said. I did not > say "WILL BE REACHABLE". I said "THEORETICALLY > REACHABLE". I also said "GLOBAL UNIQUE" address not > "PUBLIC ADDRESS". > > The point is one should be able to get addresses with > these properties. It's your decision about whether to > use all the properties the addresses have. I was agreeing with you, not speaking against you, Mark. > As for printers directly reachable from anywhere, why > not. We do have the technology to authenticate requests > regardless of the IP address the request originates > from. Whether that is built into your printer or not is > a purchasing decision. I see nothing wrong with being > able to print out something from the other side of the > world for someone else to pick up. The cost to do this > shoudn't amount to more than a couple of cents in the > printer's price as it is all one off engineering. That question was rhetorical - everybody on this list already knows the answer :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From cb.list6 at gmail.com Sun Mar 23 19:05:54 2014 From: cb.list6 at gmail.com (Cb B) Date: Sun, 23 Mar 2014 12:05:54 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> Message-ID: On Sun, Mar 23, 2014 at 11:27 AM, Philip Dorr wrote: > On Mar 23, 2014 1:11 PM, "Mark Tinka" wrote: >> >> On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote: >> >> > I was at work last week and because I have IPv6 at both >> > ends I could just log into the machines at home as >> > easily as if I was there. When I'm stuck using a IPv4 >> > only service on the road I have to jump through lots of >> > hoops to reach the internal machines. >> >> I expect this to change little in the enterprise space. I >> think use of ULA and NAT66 will be one of the things >> enterprises will push for, because how can a printer have a >> public IPv6 address that is reachable directly from the >> Internet, despite the fact that there is a properly >> configured firewall at the perimetre offering half-decent >> protection? > > That is what a firewall is for. Drop new inbound connections, allow > related, and allow outbound. Then you allow specific IP/ports to have > inbound traffic. You may also only allow outbound traffic for specific > ports, or from your proxy. i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default. i would hate for people to think that a middle box is required, when the best place to provide security is in the host. Other layers are needed as required, but it is sad that we don't look to the host it self as a first step. CB From mark.tinka at seacom.mu Sun Mar 23 19:13:14 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 21:13:14 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> Message-ID: <201403232113.15291.mark.tinka@seacom.mu> On Sunday, March 23, 2014 09:05:54 PM Cb B wrote: > i would say the more appropriate place for this policy is > the printer, not a firewall. For example, maybe a > printer should only be ULA or LLA by default. > > i would hate for people to think that a middle box is > required, when the best place to provide security is in > the host. Other layers are needed as required, but it > is sad that we don't look to the host it self as a first > step. I would support adding security at the host-level, especially because with a centralized firewall, internal infrastructure is usually left wide open to internal staff, with trust being the rope we all hang on to to keep things running. However, if pratical running of the Internet has taught us anything, host-based firewalling (especially in purpose- specific devices like printers, Tv sets, IP phones, IP cameras, e.t.c.) is a long way away from what you can get with a centralized firewall appliance. Do I like it? No. I run a simple packet filter (IPfw) on my MacBook - it does what I need. But we know Joe and Jane won't want things they can't click; and even though they had things they could click, they don't want to have to understand all these geeky things about their computers. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From cb.list6 at gmail.com Sun Mar 23 19:24:35 2014 From: cb.list6 at gmail.com (Cb B) Date: Sun, 23 Mar 2014 12:24:35 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <201403232113.15291.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> Message-ID: On Sun, Mar 23, 2014 at 12:13 PM, Mark Tinka wrote: > On Sunday, March 23, 2014 09:05:54 PM Cb B wrote: > >> i would say the more appropriate place for this policy is >> the printer, not a firewall. For example, maybe a >> printer should only be ULA or LLA by default. >> >> i would hate for people to think that a middle box is >> required, when the best place to provide security is in >> the host. Other layers are needed as required, but it >> is sad that we don't look to the host it self as a first >> step. > > I would support adding security at the host-level, > especially because with a centralized firewall, internal > infrastructure is usually left wide open to internal staff, > with trust being the rope we all hang on to to keep things > running. > > However, if pratical running of the Internet has taught us > anything, host-based firewalling (especially in purpose- > specific devices like printers, Tv sets, IP phones, IP > cameras, e.t.c.) is a long way away from what you can get > with a centralized firewall appliance. > > Do I like it? No. I run a simple packet filter (IPfw) on my > MacBook - it does what I need. But we know Joe and Jane > won't want things they can't click; and even though they had > things they could click, they don't want to have to > understand all these geeky things about their computers. > > Mark. Mark, i think we are largely on the same page. I believe that "home firewalls" in the residential broadband space are likely the most insecure part of the entire internet. They are very rarely updated with software and frequently ship with terrible terrible bugs, much worse than what we have seen in Windows for the last 10 years. For example, http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140110-sbd Why try to hack all the devices in your home when the hackers can simply crack your CPE / firewall / router and own all your traffic, reset your DNS server to a malware box, ..... I am sure this community knows there are many many more problems just like this one in CPE. I don't see a lot of accountability or change in this space, yet people believe these firewalls help. My hope is that folks stop equating firewalls with security, when the first step is to secure the host, accountability is with the host, then layer other tools as needed. CB From niels=nanog at bakker.net Sun Mar 23 19:27:52 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 23 Mar 2014 20:27:52 +0100 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> <532EF864.30408@ispn.net> Message-ID: <20140323192751.GD36211@burnout.tpb.net> * mpetach at netflight.com (Matthew Petach) [Sun 23 Mar 2014, 20:06 CET]: >Doesn't sound too outlandish. Mind you, I'm sure >it would raise costs, as that testing and validation >wouldn't be free. But I'm sure we'd all be willing to >pay an additional $10/month on our service to be >sure it could deliver what was promised, or at least >to ensure that what was promised was scaled down >to match what could actually be delivered. Nice strawman you erected there. >Thanks! Yeah, thanks for standing up for industries holding their customers hostage to extract rents from companies trying to serve those customers. -- Niels. From mark.tinka at seacom.mu Sun Mar 23 19:34:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 23 Mar 2014 21:34:10 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> Message-ID: <201403232134.14890.mark.tinka@seacom.mu> On Sunday, March 23, 2014 09:24:35 PM Cb B wrote: > My hope is that folks stop equating firewalls with > security, when the first step is to secure the host, > accountability is with the host, then layer other tools > as needed. I couldn't agree more. As an example, your home PC (whose OS wasn't updated in months because the wife and kids can't be asked) is hit via HTTP in a way your CPE firewall couldn't prevent. It is then used to re-attack other appliances in your home that have poor software with no security features. CPE firewalls won't do anything about that. I support vendors of all kinds (Tv's, microwaves, STB's, home theatre systems, video game consoles, e.t.c.) to include some kind of localized security features that augment what a CPE firewall can offer. This will be even more critical, I think, to getting homes and offices to accept the use of GUA's on the LAN, if we have any hopes of finally getting rid of NAT with IPv6, at the scale we have it in IPv4. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From xxnog at ledeuns.net Sun Mar 23 19:35:31 2014 From: xxnog at ledeuns.net (Denis Fondras) Date: Sun, 23 Mar 2014 20:35:31 +0100 Subject: misunderstanding scale In-Reply-To: <201403232113.15291.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> Message-ID: <532F3783.4080502@ledeuns.net> Hi all, Le 23/03/2014 20:13, Mark Tinka a ?crit : > On Sunday, March 23, 2014 09:05:54 PM Cb B wrote: > >> i would say the more appropriate place for this policy is >> the printer, not a firewall. For example, maybe a >> printer should only be ULA or LLA by default. >> > > I would support adding security at the host-level, > especially because with a centralized firewall, internal > infrastructure is usually left wide open to internal staff, > with trust being the rope we all hang on to to keep things > running. > When speaking of IPv6 deployment, I routinely hear about host security. I feel like it should be stated that this is *in no way* an IPv6 issue. May the device be ULA, LLA, GUA or RFC1918-addressed, the device is at risk anyway. If this is the only argument for delaying IPv6 deployment, this sounds more like FUD to me ;-) Denis From mpetach at netflight.com Sun Mar 23 20:02:34 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 23 Mar 2014 13:02:34 -0700 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: <20140323192751.GD36211@burnout.tpb.net> References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> <532EF864.30408@ispn.net> <20140323192751.GD36211@burnout.tpb.net> Message-ID: On Sun, Mar 23, 2014 at 12:27 PM, Niels Bakker wrote: > * mpetach at netflight.com (Matthew Petach) [Sun 23 Mar 2014, 20:06 CET]: > > Doesn't sound too outlandish. Mind you, I'm sure >> it would raise costs, as that testing and validation >> wouldn't be free. But I'm sure we'd all be willing to >> pay an additional $10/month on our service to be >> sure it could deliver what was promised, or at least >> to ensure that what was promised was scaled down >> to match what could actually be delivered. >> > > Nice strawman you erected there. > > Thanks! I thought it looked quite nice up on its pole. :) Now it's time for people to take turns poking holes in it. ^_^ Thanks! >> > > Yeah, thanks for standing up for industries holding their customers > hostage to extract rents from companies trying to serve those customers. > I'm not so much standing up for them as pointing out that simply calling for additional oversight and regulation often brings increased costs into the picture. Oddly enough, I'm having a hard time identifying exactly *where* the money comes from to pay for government verification of industry performance claims; I'm sure it's just my weak search-fu, however, and some person with more knowledge on the subject will be able to shed light on how such validation and compliance testing is typically paid for. > > -- Niels. > > Thanks! Matt From nick at foobar.org Sun Mar 23 20:23:06 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 23 Mar 2014 20:23:06 +0000 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323183952.58ACE11B2B61@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> Message-ID: <532F42AA.9000604@foobar.org> On 23/03/2014 18:39, Mark Andrews wrote: > As for printers directly reachable from anywhere, why not. because in practice it's an astonishingly stupid idea. Here's why: chargen / other small services ssh www buffer overflows open smtp relays weak, default or non existent passwords information leakage from non-protected services and so forth. Nothing wrong with global reachability, don't get me wrong - and if I thought for a pico-second that printers or any other connectible device took even the most basic steps at handling security fundamentals, I might even be ok about the idea. But they don't: printer drivers and interface firmware are written by people whose only ability is relaying eps and pcl files from one socket to another and pumping their code full of rage-inducing bloatware, the only purpose of which is to serve the blind whims of idiotic product managers who derive a sadistic satisfaction from ensuring that their products interfere as much as humanly possible with the process of committing ink and toner to paper. Security management doesn't even get a look in. 12 months after market debut, printer firmware updates cease forever for that particular model, and the inevitable result is a line-rate bot spewing obnoxious crap until the day that the device is thrown on to the scrap heap that it deserved when it was first unpacked. Exactly the same principal applies to pretty much any consumer device, although I admit that printers are worse offenders than most. We can all agree that what's needed here is full consumer choice and the ability to address things globally, should one desire to do so. In practice, default deny is more sensible approach to handling the reality of connecting devices to a public network. Nick From marka at isc.org Sun Mar 23 21:02:13 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 24 Mar 2014 08:02:13 +1100 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: Your message of "Sun, 23 Mar 2014 20:23:06 -0000." <532F42AA.9000604@foobar.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> <532F42AA.9000604@foobar.org> Message-ID: <20140323210213.3397F11B3F95@rock.dv.isc.org> In message <532F42AA.9000604 at foobar.org>, Nick Hilliard writes: > On 23/03/2014 18:39, Mark Andrews wrote: > > As for printers directly reachable from anywhere, why not. > > because in practice it's an astonishingly stupid idea. Here's why: > > chargen / other small services > ssh > www > buffer overflows > open smtp relays > weak, default or non existent passwords > information leakage from non-protected services > > and so forth. > > Nothing wrong with global reachability, don't get me wrong - and if I > thought for a pico-second that printers or any other connectible device > took even the most basic steps at handling security fundamentals, I might > even be ok about the idea. > > But they don't: printer drivers and interface firmware are written by > people whose only ability is relaying eps and pcl files from one socket to > another and pumping their code full of rage-inducing bloatware, the only > purpose of which is to serve the blind whims of idiotic product managers > who derive a sadistic satisfaction from ensuring that their products > interfere as much as humanly possible with the process of committing ink > and toner to paper. Security management doesn't even get a look in. > > 12 months after market debut, printer firmware updates cease forever for > that particular model, and the inevitable result is a line-rate bot spewing > obnoxious crap until the day that the device is thrown on to the scrap heap > that it deserved when it was first unpacked. > > Exactly the same principal applies to pretty much any consumer device, > although I admit that printers are worse offenders than most. > > We can all agree that what's needed here is full consumer choice and the > ability to address things globally, should one desire to do so. In > practice, default deny is more sensible approach to handling the reality of > connecting devices to a public network. > > Nick Actually all you have stated in that printer vendors need to clean up their act and not that one shouldn't expect to be able to expose a printer to the world. It isn't hard to do this correctly. It also does not cost much on a per device basis. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tmorizot at gmail.com Sun Mar 23 21:27:16 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 16:27:16 -0500 Subject: misunderstanding scale In-Reply-To: <532F0B02.7090208@mykolab.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> Message-ID: On Mar 23, 2014 11:27 AM, "Paul Ferguson" wrote: > Also, IPv6 introduces some serious security concerns, and until they > are properly addressed, they will be a serious barrier to even > considering it. And that is pure FUD. The sorts of security risks with IPv6 are mostly in the same sorts of categories as those with IPv4 and have appropriate mitigations available. Moreover, by not enabling and controlling IPv6 on their networks, an operator is actually markedly more vulnerable to IPv6 attacks, not less. Scott From fergdawgster at mykolab.com Sun Mar 23 21:45:27 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 23 Mar 2014 14:45:27 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> Message-ID: <532F55F7.3010802@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/2014 2:27 PM, Timothy Morizot wrote: > > On Mar 23, 2014 11:27 AM, "Paul Ferguson" > > > wrote: >> Also, IPv6 introduces some serious security concerns, and until >> they are properly addressed, they will be a serious barrier to >> even considering it. > > And that is pure FUD. The sorts of security risks with IPv6 are > mostly in the same sorts of categories as those with IPv4 and have > appropriate mitigations available. Moreover, by not enabling and > controlling IPv6 on their networks, an operator is actually > markedly more vulnerable to IPv6 attacks, not less. > Only if end-points are unaware of dual-stack capabilities. Also, neighbor discovery, for example, can be dangerous (admittedly, so can ARP spoofing in IPv4). And aside from the spoofable ability of ND, robust DHCPv6 is needed for enterprises for sheer operational continuity. And that's only a "half" example. I haven't even mentioned spam management in v6, which will become a nightmare if people have been relying on IP BL's or similar. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMvVfcACgkQKJasdVTchbLv0AEAhd/IkA19ssgDW/R+YDWe6YTQ YRnWIWwiNM+79NuF1EcBAKuMyULkR2hUXdVO7B/IprgpJxrHtzU0mYdTqJJLgnV1 =1iFc -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Sun Mar 23 21:45:50 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 23 Mar 2014 14:45:50 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> Message-ID: <20140323214550.GB29152@vacation.karoshi.com> On Sun, Mar 23, 2014 at 04:27:16PM -0500, Timothy Morizot wrote: > On Mar 23, 2014 11:27 AM, "Paul Ferguson" wrote: > > Also, IPv6 introduces some serious security concerns, and until they > > are properly addressed, they will be a serious barrier to even > > considering it. > > And that is pure FUD. The sorts of security risks with IPv6 are mostly in > the same sorts of categories as those with IPv4 and have appropriate > mitigations available. Moreover, by not enabling and controlling IPv6 on > their networks, an operator is actually markedly more vulnerable to IPv6 > attacks, not less. > > Scott Yo, Tim/Scott. Seems you have not been keeping up. http://go6.si/wp-content/uploads/2011/11/DREN-6-Slo-IPv6Summit-2011.pdf points out several unique problems w/ IPv6 and in deployments where there are ZERO IPv4 equivalents. Ferg is paranoid, but it doesn;t mean they are not out to get him/IPv6. /bill From nick at foobar.org Sun Mar 23 22:31:57 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 23 Mar 2014 22:31:57 +0000 Subject: misunderstanding scale In-Reply-To: <20140323210213.3397F11B3F95@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> <532F42AA.9000604@foobar.org> <20140323210213.3397F11B3F95@rock.dv.isc.org> Message-ID: <532F60DD.3030302@foobar.org> On 23/03/2014 21:02, Mark Andrews wrote: > Actually all you have stated in that printer vendors need to clean > up their act and not that one shouldn't expect to be able to expose > a printer to the world. It isn't hard to do this correctly. perish the thought - and I look forward to the day that vendors write secure software which is impregnable to all vulnerabilities past and present. When that happens, I'll cast away my default deny configurations and advise other people to do the same. Until then, though, I hope you understand why I suggest that default deny is no less sensible a precaution than locking the front door in a busy city. Nick From bmanning at vacation.karoshi.com Sun Mar 23 22:42:16 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 23 Mar 2014 15:42:16 -0700 Subject: misunderstanding scale In-Reply-To: <532F60DD.3030302@foobar.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> <532F42AA.9000604@foobar.org> <20140323210213.3397F11B3F95@rock.dv.isc.org> <532F60DD.3030302@foobar.org> Message-ID: <20140323224216.GA31230@vacation.karoshi.com> On Sun, Mar 23, 2014 at 10:31:57PM +0000, Nick Hilliard wrote: > On 23/03/2014 21:02, Mark Andrews wrote: > > Actually all you have stated in that printer vendors need to clean > > up their act and not that one shouldn't expect to be able to expose > > a printer to the world. It isn't hard to do this correctly. > > perish the thought - and I look forward to the day that vendors write > secure software which is impregnable to all vulnerabilities past and > present. When that happens, I'll cast away my default deny configurations > and advise other people to do the same. > > Until then, though, I hope you understand why I suggest that default deny > is no less sensible a precaution than locking the front door in a busy city. > > Nick Hum.. perhaps a poor analogy. Tokyo is a busy city, yet I know quite a few people who don;t lock their doors there. Redondo Beach is quite a bit less busy, but -everyone- locks their doors and anything else of value. Its the culture of ethics of the individiual, not the density of individuals. /bill From mpalmer at hezmatt.org Sun Mar 23 22:04:14 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 24 Mar 2014 09:04:14 +1100 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140322195704.15285.qmail@joyce.lan> References: <201403222118.01172.mark.tinka@seacom.mu> <20140322195704.15285.qmail@joyce.lan> Message-ID: <20140323220414.GN6081@hezmatt.org> On Sat, Mar 22, 2014 at 07:57:04PM -0000, John Levine wrote: > >In such a case, where you are still pushing the case for > >IPv4, how do you envisage things will look on your side when > >everybody else you want to talk to is either on IPv6, or > >frantically getting it turned up? Do you reckon anyone will > >have time to help you troubleshoot patchy (for example) IPv4 > >connectivity when all the focus is on IPv6? > > I've put that concern on my calendar for sometime around 2025. > > People have been saying switch to IPv6 now Now NOW for about a decade, > and you can only cry wolf so many times. You've got to remember what happened to the boy who cried wolf, though. He eventually got eaten. The difference here, though, is that the people crying wolf in *this* fairy tale are already safely up the IPv6 tree. It's the people who aren't listening who are going to get eaten. - Matt From tmorizot at gmail.com Sun Mar 23 22:56:32 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 17:56:32 -0500 Subject: misunderstanding scale In-Reply-To: <20140323214550.GB29152@vacation.karoshi.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> Message-ID: On Mar 23, 2014 4:45 PM, wrote: > Yo, Tim/Scott. Seems you have not been keeping up. > > http://go6.si/wp-content/uploads/2011/11/DREN-6-Slo-IPv6Summit-2011.pdf > > points out several unique problems w/ IPv6 and in deployments where > there are ZERO IPv4 equivalents. Ferg is paranoid, but it doesn;t > mean they are not out to get him/IPv6. Seriously? That's the best you can come up? A three year old presentation? The RA and ND vulnerabilities are just the IPv6 versions of ARP floods and similar attacks. They are well-understood and long mitigated. On the other hand, if you have an IPv4 only network with lots of IPv6 capable devices on it and someone compromises a host to start sending out RAs, what exactly is your defense posture? My comments represent reality. Your security posture is much worse in an IPv4 only configuration than if you enable and control IPv6. Scott From marka at isc.org Sun Mar 23 23:15:27 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 24 Mar 2014 10:15:27 +1100 Subject: misunderstanding scale In-Reply-To: Your message of "Sun, 23 Mar 2014 22:31:57 -0000." <532F60DD.3030302@foobar.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> <532F42AA.9000604@foobar.org> <20140323210213.3397F11B3F95@rock.dv.isc.org> <532F60DD.3030302@foobar.org> Message-ID: <20140323231527.50DC711B49E0@rock.dv.isc.org> In message <532F60DD.3030302 at foobar.org>, Nick Hilliard writes: > On 23/03/2014 21:02, Mark Andrews wrote: > > Actually all you have stated in that printer vendors need to clean > > up their act and not that one shouldn't expect to be able to expose > > a printer to the world. It isn't hard to do this correctly. > > perish the thought - and I look forward to the day that vendors write > secure software which is impregnable to all vulnerabilities past and > present. When that happens, I'll cast away my default deny configurations > and advise other people to do the same. And there you go putting stricter requirements on printers that you don't put on laptop, servers. None of us would put any machines on the net if they had to meet your printer's requirements. > Until then, though, I hope you understand why I suggest that default deny > is no less sensible a precaution than locking the front door in a busy city. > > Nick > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fergdawgster at mykolab.com Sun Mar 23 23:21:50 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 23 Mar 2014 16:21:50 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> Message-ID: <532F6C8E.9040705@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/2014 3:56 PM, Timothy Morizot wrote: > My comments represent reality. Your security posture is much worse > in an IPv4 only configuration than if you enable and control IPv6. Says you. On the other hand, there are beaucoup enterprise networks unwilling to consider to moving to v6 until there are management, control, administrative, and security issues addressed. You can continue to deride our issues, and make derisive comments until your heart's content, but it does not change reality. And on that, it will be the last I say on the matter on NANOG. Best & Cheers, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMvbI4ACgkQKJasdVTchbK0igD+JF+M3DRoRz5wIJFo+tLV5dFF KuoOPKOQYJ8Vpf32aMsA/2ccs9CDrbq5hatw+LkL8/CHafTbOWGkhdYfjv7Q6ghM =HeCa -----END PGP SIGNATURE----- From mpalmer at hezmatt.org Sun Mar 23 23:23:19 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 24 Mar 2014 10:23:19 +1100 Subject: misunderstanding scale In-Reply-To: <20140323231527.50DC711B49E0@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <20140323183952.58ACE11B2B61@rock.dv.isc.org> <532F42AA.9000604@foobar.org> <20140323210213.3397F11B3F95@rock.dv.isc.org> <532F60DD.3030302@foobar.org> <20140323231527.50DC711B49E0@rock.dv.isc.org> Message-ID: <20140323232313.GS6081@hezmatt.org> On Mon, Mar 24, 2014 at 10:15:27AM +1100, Mark Andrews wrote: > > In message <532F60DD.3030302 at foobar.org>, Nick Hilliard writes: > > On 23/03/2014 21:02, Mark Andrews wrote: > > > Actually all you have stated in that printer vendors need to clean > > > up their act and not that one shouldn't expect to be able to expose > > > a printer to the world. It isn't hard to do this correctly. > > > > perish the thought - and I look forward to the day that vendors write > > secure software which is impregnable to all vulnerabilities past and > > present. When that happens, I'll cast away my default deny configurations > > and advise other people to do the same. > > And there you go putting stricter requirements on printers that you > don't put on laptop, servers. None of us would put any machines on > the net if they had to meet your printer's requirements. To be fair, laptops and servers today tend to have better baseline security than printers today, and laptops and servers tend to have a better patch release and patch management support than printers. That isn't to say that printers (and other similar devices *cough*Residential CPE*cough*) couldn't be made to be at least as secure, out-of-the-box and ongoing, as today's laptops and servers, but that isn't the case today, and I'm not aware of anything on the horizon that would encourage a swift change in the current trajectory for those devices. On a completely unrelated topic, anyone else looking forward to XPocalypse next month? - Matt (A pragmatic proponent of the end-to-end principle) -- School never taught ME anything at all, except that there are even more morons out there than I would have dreamed, and many of them like to beat up people smaller than they are. -- SeaWasp in RASFW From sixsigma44 at hotmail.com Sun Mar 23 23:28:04 2014 From: sixsigma44 at hotmail.com (Ray) Date: Sun, 23 Mar 2014 19:28:04 -0400 Subject: misunderstanding scale In-Reply-To: <20140323231527.50DC711B49E0@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan>, <20140323165726.E2A2F11B18F1@rock.dv.isc.org>, <201403232009.47085.mark.tinka@seacom.mu>, <20140323183952.58ACE11B2B61@rock.dv.isc.org> <532F42AA.9000604@foobar.org>,<20140323210213.3397F11B3F95@rock.dv.isc.org> <532F60DD.3030302@foobar.org>,<20140323231527.50DC711B49E0@rock.dv.isc.org> Message-ID: Not necessarily. Printers generally run unattended, printers generally are not rebooted periodically for updates (assuring malware can continue to run), printers generally are not updated even periodically, printers generally have almost no logging that could be reviewed, printers are generally "managed" by the Level 1 Help Desk types whose concern is 99.999% availability to the exclusion of everything else and a host of other things. IMHO there's not much comparison because of what they do, how they are (mis)managed and (not) monitored. But since vendors (and our employers) usually do their utmost to maximize profit while minimizing expense, nothing will change unless there is a user uproar. And that uproar for printers is generally a clamoring for more features, not less risk. > And there you go putting stricter requirements on printers that you > don't put on laptop, servers. None of us would put any machines on > the net if they had to meet your printer's requirements. From tmorizot at gmail.com Sun Mar 23 23:37:52 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 18:37:52 -0500 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <532F55F7.3010802@mykolab.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> Message-ID: On Mar 23, 2014 4:45 PM, "Paul Ferguson" wrote: > Also, neighbor discovery, for example, can be dangerous (admittedly, > so can ARP spoofing in IPv4). And aside from the spoofable ability of > ND, robust DHCPv6 is needed for enterprises for sheer operational > continuity. Yes. As I said, same general sorts of risks for the most part as in IPv4. Details differ, but same general types. My point was that it's mostly FUD to wave the flag of scary new security weaknesses with no mitigations in IPv6. It's the same general sort of first hop and link security issues that exist in IPv4 with similar mitigations. Not identical, but not radically different or new either. And yes, I can't imagine any reason a large enterprise would use SLAAC instead of DHCPv6. We're certainly using the latter. But we have robust DHCPv6 available, so I don't understand why you think that's a weakness. > I haven't even mentioned spam management in v6, which will become a > nightmare if people have been relying on IP BL's or similar. Uh-huh. We've had our Internet mail gateways dual-stacked for a year and a half now. There have certainly been bumps and challenges along the way. I wouldn't want to imply it's been a cakewalk. But it hasn't been some sort of insurmountable challenge. And my organization is extremely security conscious and highly visible. You'll pardon my skepticism over claims that unspecified security weaknesses make it impossible to do what we have done and are continuing to do. Scott From tmorizot at gmail.com Sun Mar 23 23:49:36 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 18:49:36 -0500 Subject: misunderstanding scale In-Reply-To: <532F6C8E.9040705@mykolab.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: On Mar 23, 2014 6:21 PM, "Paul Ferguson" wrote: > Says you. And many others. My comments were actually reiterating what I commonly see presented today. > On the other hand, there are beaucoup enterprise networks unwilling to > consider to moving to v6 until there are management, control, > administrative, and security issues addressed. Whereas there are other enterprise networks, including mine, who are actively deploying IPv6 and have been for a number of years now. So unless you can come up with something truly novel that we haven't already dealt with, I'll stick by my use of FUD. > You can continue to deride our issues, and make derisive comments > until your heart's content, but it does not change reality. I wasn't aware that calling out FUD was derisive, but whatever. Cheers, Scott From damien at supremebytes.com Sun Mar 23 17:46:53 2014 From: damien at supremebytes.com (Damien Burke) Date: Sun, 23 Mar 2014 17:46:53 +0000 Subject: tools similar to stat.ripe.net? Message-ID: <2FD50E6D13594B4C93B743BFCF9F528404399878@sbla1-exchange.sb.local> Hello, Are there any tools similar to the routing tab at stat.ripe.net ? To be more specific, I'm looking for the "BGP route visibility" feature. -Damien From eyeronic.design at gmail.com Mon Mar 24 00:24:24 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Sun, 23 Mar 2014 17:24:24 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: "I wasn't aware that calling out FUD was derisive, but whatever." It's derisive because you completely dismiss a huge security issue that, given the state of IPv6 adoption, a great majority of companies are facing. Calling it FUD is completely wrong because it *is* a legitimate security issue for most businesses. Sure, you've got the few who have been able to properly plan for and secure their networks against the increased attack surface of IPv6, but again...most companies haven't. Slinging false proclamations of FUD is as harmful as FUD itself. On Sun, Mar 23, 2014 at 4:49 PM, Timothy Morizot wrote: > On Mar 23, 2014 6:21 PM, "Paul Ferguson" wrote: >> Says you. > > And many others. My comments were actually reiterating what I commonly see > presented today. > >> On the other hand, there are beaucoup enterprise networks unwilling to >> consider to moving to v6 until there are management, control, >> administrative, and security issues addressed. > > Whereas there are other enterprise networks, including mine, who are > actively deploying IPv6 and have been for a number of years now. So unless > you can come up with something truly novel that we haven't already dealt > with, I'll stick by my use of FUD. > >> You can continue to deride our issues, and make derisive comments >> until your heart's content, but it does not change reality. > > I wasn't aware that calling out FUD was derisive, but whatever. > > Cheers, > > Scott -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From tmorizot at gmail.com Mon Mar 24 00:41:00 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 19:41:00 -0500 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: On Mar 23, 2014 7:24 PM, "Mike Hale" wrote: > It's derisive because you completely dismiss a huge security issue > that, given the state of IPv6 adoption, a great majority of companies > are facing. The original assertion was that there are unaddressed security weaknesses in IPv6 itself preventing its adoption. At least that's the way I read it. And that assertion is mostly FUD. > Calling it FUD is completely wrong because it *is* a legitimate > security issue for most businesses. Sure, you've got the few who have > been able to properly plan for and secure their networks against the > increased attack surface of IPv6, but again...most companies haven't. Well, it's hardly a few at this point, unless by few you simply mean a minority. But it's a numerous and growing minority. Moreover, the acknowledgement that enterprises have been able to properly plan and deploy IPv6 while appropriately mitigating the security risks shows the claim that there are security weaknesses in IPv6 preventing its adoption is false. Now admittedly if an enterprise hasn't done any security planning or assessments then they aren't ready to deploy IPv6. But there's nothing inherent to IPv6 stopping them. Scott From contact at winterei.se Mon Mar 24 00:46:52 2014 From: contact at winterei.se (Paul S.) Date: Mon, 24 Mar 2014 09:46:52 +0900 Subject: tools similar to stat.ripe.net? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528404399878@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528404399878@sbla1-exchange.sb.local> Message-ID: <532F807C.3000500@winterei.se> I'd simply just recommend using the route views servers, you don't really need the graphical representation. On 3/24/2014 ?? 02:46, Damien Burke wrote: > Hello, > > Are there any tools similar to the routing tab at stat.ripe.net ? > > To be more specific, I'm looking for the "BGP route visibility" feature. > > -Damien From eyeronic.design at gmail.com Mon Mar 24 00:54:32 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Sun, 23 Mar 2014 17:54:32 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: "unless by few you simply mean a minority" Which I do. "appropriately mitigating the security risks shows the claim that there are security weaknesses in IPv6 preventing its adoption is false." No. It doesn't. It's not the sole reason, but it's a huge factor to consider. "But there's nothing inherent to IPv6 stopping them." There is because it doubles your attack surface at the very least. At the worst, it increases it exponentially since suddenly all your internal devices (that were never configured to be public-facing) are suddenly accessible from everywhere. None of this isn't preventable, by the way. There are a myriad of solutions that can and do mitigate these risks. But to simply dismiss the security considerations is, I think, incredibly na?ve and unrealistic. On Sun, Mar 23, 2014 at 5:41 PM, Timothy Morizot wrote: > > On Mar 23, 2014 7:24 PM, "Mike Hale" wrote: >> It's derisive because you completely dismiss a huge security issue >> that, given the state of IPv6 adoption, a great majority of companies >> are facing. > > The original assertion was that there are unaddressed security weaknesses in > IPv6 itself preventing its adoption. At least that's the way I read it. And > that assertion is mostly FUD. > >> Calling it FUD is completely wrong because it *is* a legitimate >> security issue for most businesses. Sure, you've got the few who have >> been able to properly plan for and secure their networks against the >> increased attack surface of IPv6, but again...most companies haven't. > > Well, it's hardly a few at this point, unless by few you simply mean a > minority. But it's a numerous and growing minority. Moreover, the > acknowledgement that enterprises have been able to properly plan and deploy > IPv6 while appropriately mitigating the security risks shows the claim that > there are security weaknesses in IPv6 preventing its adoption is false. > > Now admittedly if an enterprise hasn't done any security planning or > assessments then they aren't ready to deploy IPv6. But there's nothing > inherent to IPv6 stopping them. > > Scott -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From marka at isc.org Mon Mar 24 01:14:55 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 24 Mar 2014 12:14:55 +1100 Subject: misunderstanding scale In-Reply-To: Your message of "Sun, 23 Mar 2014 17:24:24 -0700." References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: <20140324011455.77B0311B68FE@rock.dv.isc.org> In message , Mike Hale writes: > "I wasn't aware that calling out FUD was derisive, but whatever." > It's derisive because you completely dismiss a huge security issue > that, given the state of IPv6 adoption, a great majority of companies > are facing. > > Calling it FUD is completely wrong because it *is* a legitimate > security issue for most businesses. Sure, you've got the few who have > been able to properly plan for and secure their networks against the > increased attack surface of IPv6, but again...most companies haven't. > > Slinging false proclamations of FUD is as harmful as FUD itself. And there are security issues with IPv4 but no one is saying don't deploy IPv4 because there are security issues. There are security issues with just about everything. Most of them are rare and have mitigations. Saying there are security issues without enumerating them is FUD. There is a security issue with DHCP, there is no authentication of the server. For 99.99% of sites this is a non issue. For those where it is a issue there are mitigation strategies. This doesn't stop it being a security issue. > On Sun, Mar 23, 2014 at 4:49 PM, Timothy Morizot wrote: > > On Mar 23, 2014 6:21 PM, "Paul Ferguson" wrote: > >> Says you. > > > > And many others. My comments were actually reiterating what I commonly see > > presented today. > > > >> On the other hand, there are beaucoup enterprise networks unwilling to > >> consider to moving to v6 until there are management, control, > >> administrative, and security issues addressed. > > > > Whereas there are other enterprise networks, including mine, who are > > actively deploying IPv6 and have been for a number of years now. So unless > > you can come up with something truly novel that we haven't already dealt > > with, I'll stick by my use of FUD. > > > >> You can continue to deride our issues, and make derisive comments > >> until your heart's content, but it does not change reality. > > > > I wasn't aware that calling out FUD was derisive, but whatever. > > > > Cheers, > > > > Scott > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tmorizot at gmail.com Mon Mar 24 01:25:35 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 20:25:35 -0500 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: On Mar 23, 2014 7:54 PM, "Mike Hale" wrote: > "unless by few you simply mean a minority" > Which I do. Then that's fine. But there are numerous enterprises in that minority and it includes some pretty large enterprises. My own enterprise organization has more than 600 sites, 100k employees, and thousands of contractors. > "appropriately mitigating the security risks shows the claim that > there are security weaknesses in IPv6 preventing its adoption is > false." > No. It doesn't. It's not the sole reason, but it's a huge factor to consider. Logic 101? If security-conscious enterprises have successfully implemented IPv6 while mitigating the security risks, then there aren't any inherent security weaknesses preventing its adoption by enterprises. A non-FUD statement would be that we've assessed our infrastructure and preparedness for IPv6 and aren't yet in a position where we can safely deploy IPv6. A FUD statement is the assertion that there are inherent security weaknesses in the protocol preventing enterprises from deploying it. > There is because it doubles your attack surface at the very least. At > the worst, it increases it exponentially since suddenly all your > internal devices (that were never configured to be public-facing) are > suddenly accessible from everywhere. It's an IPv6 world. Your attack surface has already expanded whether or not you deploy IPv6. In fact, an enterprise will be making itself increasingly vulnerable to IPv6 attacks by refusing to deploy it than by securely enabling and controlling the protocol. And if an enterprise doesn't have firewalls in place, then their devices are already accessible. NAT44 doesn't provide any meaningful security protection. If you have firewalls with appropriate policies, then it's silly to claim your internal devices are suddenly accessible from everywhere. My organization is particularly strict at our perimeter. Everything is default deny in both directions for both protocols and we very carefully open holes. We also allow very little unproxied access to the Internet. (DNS, SMTP, and HTTP/HTTPS being the most common services provided in our Internet access points.) > None of this isn't preventable, by the way. There are a myriad of > solutions that can and do mitigate these risks. But to simply dismiss > the security considerations is, I think, incredibly na?ve and > unrealistic. Nowhere have I dismissed security considerations for either IPv4 or IPv6. I've simply pointed out that it really isn't any harder to plan and manage for v6 than for v4. And we currently live in a dual-protocol Internet. Simply pretending that if you don't enable IPv6, you're somehow immune from IPv6 threats is naive. Scott From mike at mtcc.com Mon Mar 24 01:43:10 2014 From: mike at mtcc.com (Michael Thomas) Date: Sun, 23 Mar 2014 18:43:10 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: <532F8DAE.2040507@mtcc.com> [] It seems to me that the only thing that really matters in v6 wars for enterprise is whether their content side has a v6 face. Who really cares whether they migrate away from v4 so long as they make their outward facing content (eg web, etc) available over v6? That's really the key. Mike From eyeronic.design at gmail.com Mon Mar 24 01:44:52 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Sun, 23 Mar 2014 18:44:52 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: "then there aren't any inherent security weaknesses preventing its adoption by enterprises." You're right. There's not an inherent security weakness in the protocol. The increased risk is due to the increase in your attack surface (IMHO). "Your attack surface has already expanded whether or not you deploy IPv6." Not so. If I don't enable IPv6 on my hosts, the attacker can yammer away via IPv6 all day long with no result. "And if an enterprise doesn't have firewalls in place, then their devices are already accessible." For those devices that have publicly routable IP addresses, sure. "My organization is particularly strict at our perimeter" Then sir, you're in a fortunate and small group. "I've simply pointed out that it really isn't any harder to plan and manage for v6 than for v4" Except it is. I get your point that there aren't any additional vulnerabilities in v6 than they are in v4. My point is that it's a lot more work. And as someone who's facing this issue right now, I promise you...it's a lot more work. I'm not saying it's not worth the effort nor that it's unnecessary...but to imply that securing v6 is an easy step up from securing v4 is inaccurate. "Simply pretending that if you don't enable IPv6, you're somehow immune from IPv6 threats is na?ve." No. If I turn off v6 in my kernel, I am absolutely immune from native v6 threats. I'm happy to be proven wrong if you can show me a case where this isn't so. Mark: Everything you've said is correct. But my point is simply that there *are* security considerations when deploying v6, and they're bigger than some rare and esoteric bug that's only exploitable when all the stars align. With v6, a simple misconfiguration can open up every single host directly to the outside. The same simply isn't true with NAT where you have to explicitly define inbound rules. Again...I'm not saying these considerations are insurmountable. I'm not saying you shouldn't deploy v6 because of potential security holes. But to sound dismissive of those security considerations involved with deploying v6 is very counterproductive. On Sun, Mar 23, 2014 at 6:25 PM, Timothy Morizot wrote: > > On Mar 23, 2014 7:54 PM, "Mike Hale" wrote: >> "unless by few you simply mean a minority" >> Which I do. > > Then that's fine. But there are numerous enterprises in that minority and it > includes some pretty large enterprises. My own enterprise organization has > more than 600 sites, 100k employees, and thousands of contractors. > >> "appropriately mitigating the security risks shows the claim that >> there are security weaknesses in IPv6 preventing its adoption is >> false." >> No. It doesn't. It's not the sole reason, but it's a huge factor to >> consider. > > Logic 101? If security-conscious enterprises have successfully implemented > IPv6 while mitigating the security risks, then there aren't any inherent > security weaknesses preventing its adoption by enterprises. A non-FUD > statement would be that we've assessed our infrastructure and preparedness > for IPv6 and aren't yet in a position where we can safely deploy IPv6. A FUD > statement is the assertion that there are inherent security weaknesses in > the protocol preventing enterprises from deploying it. > >> There is because it doubles your attack surface at the very least. At >> the worst, it increases it exponentially since suddenly all your >> internal devices (that were never configured to be public-facing) are >> suddenly accessible from everywhere. > > It's an IPv6 world. Your attack surface has already expanded whether or not > you deploy IPv6. In fact, an enterprise will be making itself increasingly > vulnerable to IPv6 attacks by refusing to deploy it than by securely > enabling and controlling the protocol. > > And if an enterprise doesn't have firewalls in place, then their devices are > already accessible. NAT44 doesn't provide any meaningful security > protection. If you have firewalls with appropriate policies, then it's silly > to claim your internal devices are suddenly accessible from everywhere. My > organization is particularly strict at our perimeter. Everything is default > deny in both directions for both protocols and we very carefully open holes. > We also allow very little unproxied access to the Internet. (DNS, SMTP, and > HTTP/HTTPS being the most common services provided in our Internet access > points.) > >> None of this isn't preventable, by the way. There are a myriad of >> solutions that can and do mitigate these risks. But to simply dismiss >> the security considerations is, I think, incredibly na?ve and >> unrealistic. > > Nowhere have I dismissed security considerations for either IPv4 or IPv6. > I've simply pointed out that it really isn't any harder to plan and manage > for v6 than for v4. And we currently live in a dual-protocol Internet. > Simply pretending that if you don't enable IPv6, you're somehow immune from > IPv6 threats is naive. > > Scott -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From SNaslund at medline.com Mon Mar 24 01:59:51 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 01:59:51 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403211501.s2LF171x005077@aurora.sol.net> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> >> We don't know because the service provider rolls that cost up along >> with th= e services they sell. That is my point. They are able to > >spread the costs= out based on the profitable services they sell. >Okay. >> If they were not able to = > >sell us services I am not sure they could afford to provide that > >infrastruc= ture. >That's a crock. You can always provide infrastructure without selling services on top of it. It's wire. Or fiber. Or whatever. If you're not able to subsidize the >infrastructure with services, then what you actually get is a less distorted reality where you can actually identify the component costs (circuit, services, etc). Sure you could do that. I'm not denying that you could. I am saying good luck making money on that or getting that business model funded. >> In fact, having been a service provider I can tell you that I paid t= >> he LEC about $4 a month for a copper pair to your house to sell DSL > >service= at around ten times that cost. I am sure the LEC was not > >making money at = the $4 a month and I know I could not fund a build out for that price. >Why would you try to fund a build out on that? How are you going to get more than that? I am saying you CAN'T fund a build out that way. That's why a pure infrastructure model is not economically viable unless you have exclusivity that forces people to use it. >Why wouldn't you instead charge for the build out as a NRC and then charge for maintenance as a MRC? Because your customer will not pay a NRC for a residential build-out. I know from experience that it is hard to get even business customers to eat a reasonable construction cost of a couple thousand dollars. Try that model against an incumbent cable company and see how that works. Will they be willing to pay thousands to be on your fiber network not knowing what the service is like until they commit or will they be more likely to go with the incumbent cable company with a simple monthly charge. In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? >What you're suggesting reeks of the deliberate cost distortion games that go on so often. My personal favorite is cell phone contracts where the cost of the >phone is *cough* "subsidized" by the carrier. But what's really happening is that the customer is paying for the phone over the term of the contract, and if >the customer doesn't get a different phone at the end of the contract, then the carrier ... lowers their monthly rate accordingly? No, of course not... they > >keep it as profit. The carriers do subsidize the cost of phones and often they are free. You can also get your phone upgraded on a schedule that is usually a couple years at most, you just have to ask. This is a legacy model to get customers past the entry point of phones that might have cost up to $1,000. Just look at the cost of a cell phone without any service attached to it. It is much greater than what you pay when you buy a phone with service. It is the customer spreading the costs out over the life of a contract because more people care more about monthly costs than overall cost. Do you think people want to fund communications infrastructure to a home they might move out of in a year or two? By the way, how do you continue to collect the NRC if I do move? I can sell my home tomorrow, Do I still have to pay for your fiber build? Can you mandate that the grandma that moves in has to pay for it now even if she does need high speed services? It's not a cost distortion game. What is going on is that the LECs originally built their network out with the model of a captive customer that they could recover costs from for the life of the infrastructure so a 20 - 30 year payout was reasonable. Unfortunately for the competitive communications provider, the capital markets will not fund a model like that and the customer is not captive anymore. Would you bet that any of your customers will be with you 20 -30 years from now? Just about every transport level provider of fiber networks got in serious financial trouble. Look at MFS, Global Crossing, Williams, etc. The more successful model is like Level 3 who sold service on top of an infrastructure (much of which was bought out from under failed transport only providers). It was hard to make money on the city to city and country to country fiber network. The fiber to the home will be completely unprofitable without exclusive access or the ability to sell multiple services on it. The economic reality is that if I build out an expensive infrastructure I have to pile on as many high priced services as possible to order to maximize the revenue from it. A customer who does not balk at a $200 a month TV/voice/Internet service is not going to be happy getting a bill of $50 a month for a fiber loop. The services are what the customer really wants and where you can add bells and whistle with little added expense. The infrastructure is the expensive part. BTW, if you think that NRC infrastructure charge would ever go away, you are kidding yourself. Here in Illinois, we have been paying for the construction of our tollway in perpetuity. When it was originally built the state promised to remove the tolls as soon as construction costs were recovered. We are still waiting and will be forever. If you want, you can criticize the model of the free economic that use profit to determine viability but unfortunately someone pays the bill in the end. Whether it is government funded, a grant, or a commercial enterprise, expenses get recovered. The only difference is that in a free market the customer gets to choose what they pay for. In any other model, everyone pays whether they like it or not. I think our communications model had to develop as a managed monopoly otherwise it would not have been the universal solution that it is today. Now we have to deal with the downside of the monopoly as well. Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 24 02:26:11 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 02:26:11 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403211119.40822.choprboy@dakotacom.net> References: <532BBFEA.70509@cox.net> <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211119.40822.choprboy@dakotacom.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5421800@MUNPRDMBXA1.medline.com> >> ... In fact, having been a service provider I can tell you that I >> paid the LEC about $4 a month for a copper pair to your house to sell > >DSL service at around ten times that cost. I am sure the LEC was not >>making money at the $4 a month and I know I could not fund a build out for that price. >I take it you have not been a service provider for a while? Thanks to its >removal from the tariff list, that $4 DSL pair from the ILEC for a third party >ISP now costs $34... That doesn't include ISP cost. That price is not what a licensed CLEC pays today for an unbundled pair, that is the price of a DSL access loop which includes electronics. As a CLEC providing DSL we had our own terminal equipment collocated, however the increased cost you quote only strengthens the point. If you are buying a DSL transport loop then the ILEC is actually selling a service on the dry loop (they are working at least at layer 2). In the model being discussed they would not be able to do that, they would only provide the copper path. As a DSL provider you would have to collocate to keep the distance down. In a FTTH model you would have to at least locate some kind of aggregation equipment near the area or the fiber count gets unmanageable. The company I work for now builds a lot of warehouses nationwide. Some of them in rural areas like Alabama. If the LEC did not have to provide access to that building they wouldn't. It just would not be profitable for them to install that much cable (in some cases miles of it) and equipment just to sell loops to competitive carriers. Picture this: our average building has maybe four POTS lines as backups to several MPLS high speed connections that carry the bulk of the voice and data. The LEC gets to charge for four POTS lines and a couple of fiber or copper loops to competitive carriers. That is just not profitable for them. They only do it because those are the ground rules for an incumbent carrier. As residential POTS lines continue to die off, their model has become one of trying to move into the service provider area for video and high speed data. Many of them are also cellular carriers in their own right. If they could not sell these services, the model does not work without drastically increasing costs to the CLECs. This may happen in any case since the residential POTS service was the cash cow that funded the entire network they have today. They were able to rely on that monthly revenue with very little overhead for over 50 years, it required little maintenance and technology upgrades. If you are going to try to do a fiber build out to the home, what would be the monthly cost of just the cable if I cannot sell services on it and is anyone will the pay the much. If I have to pay something like say $40 a month for a fiber connection, how much is service and equipment going to cost on top of that? If you have the choice of being a service provider or an infrastructure provider, why would anyone in their right mind want to be the infrastructure provider. The infrastructure guy eats the lion share of the capital expense and takes all of the risk that someone at the home will continue to want the service. That separated model just does not work except in the case of the ILEC which has capitalized that network over the last 50 years. Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 24 02:31:01 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 02:31:01 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> References: <6C136BD0-8675-4115-9F87-0AB8202B7DD0@comcast.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542181A@MUNPRDMBXA1.medline.com> There may not need to be competition in the capitalist sense of the word but there needs to be some feedback loop for the consumer of a service to provide feedback on their satisfaction with it. In the case of a government provided service people vote at the polls. With a commercially provided service people vote with their money. Without any recourse for the consumer of a service there is no motivation to improve or advance the technology. Steven Naslund Chicago IL >-----Original Message----- >From: Keegan Holley [mailto:no.spam at comcast.net] >Sent: Friday, March 21, 2014 1:08 PM >To: David Miller >Cc: nanog at nanog.org >Subject: Re: Level 3 blames Internet slowdowns on Technica >How come no one ever asks if competition is required? From tmorizot at gmail.com Mon Mar 24 02:38:00 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 21:38:00 -0500 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: On Mar 23, 2014 8:44 PM, "Mike Hale" wrote: > "Your attack surface has already expanded whether or not you deploy IPv6." > Not so. If I don't enable IPv6 on my hosts, the attacker can yammer > away via IPv6 all day long with no result. I suppose it depends on the size of your enterprise. But in one our size, despite all the controls we have in place, there is no way we could ever be assured that IPv6 was disabled on every single endpoint everywhere. So you absolutely need IPv6 enabled at your perimeter so you can see what's going in and out. And the more you're able to deploy it internally the better you're able to control it. The odds are if you're an enterprise of any size and you're simply depending on disabling IPv6 for protection, then you're probably more vulnerable than you think. Moreover, most enterprises have significant quantities of Windows clients and servers deployed. While you can alter the registry to completely disable IPv6, it's not a configuration that's supported by Microsoft. All their security and regression tests is done in v4 only, dual-stacked, and v6-only networks, but never with IPv6 disabled entirely. And given that since Vista/Server 2008 their network stack was rewritten to be entirely IPv6 (using v4 mapped addresses for ipv4 support), I'm not sure that placing your hosts in an untested configuration improves your security profile. Moreover it's known to break some things in unpleasant ways. That includes HyperV clustering and Exchange 2010 services. (My own organization ran into the Exchange issue.) So it's may very well be that you can't completely disable IPv6 on hosts and, even if you do, it may make your security profile markedly worse. > For those devices that have publicly routable IP addresses, sure. If there's no firewall and an enterprise is depending on NAT44 alone to protect internal devices, then using an RFC1918 address is no protection. NAT traversal is old hat. It's the firewall that prevents access to/from internal devices, not whether or not they have publicly routable addresses. That's true for IPv4 and IPv6. > "My organization is particularly strict at our perimeter" > Then sir, you're in a fortunate and small group. In can be a pain sometimes. By law, we have some pretty strict security requirements. > "I've simply pointed out that it really isn't any harder to plan and > manage for v6 than for v4" > Except it is. I get your point that there aren't any additional > vulnerabilities in v6 than they are in v4. My point is that it's a > lot more work. And as someone who's facing this issue right now, I > promise you...it's a lot more work. I'm not saying it's not worth the > effort nor that it's unnecessary...but to imply that securing v6 is an > easy step up from securing v4 is inaccurate. I don't think I ever said it was easy. IPv4 security isn't easy to do right. But if you're doing v4 right and have the processes in place to support it, it's not all that much harder to do it for IPv6. And one of my hats has been the IPv6 transition technical lead for my organization since 2011 so I feel your pain. I do mostly rely on our cybersecurity subgroup lead on the security side, but have to keep abreast of security issues myself. > "Simply pretending that if you don't enable IPv6, you're somehow > immune from IPv6 threats is na?ve." > No. If I turn off v6 in my kernel, I am absolutely immune from native > v6 threats. I'm happy to be proven wrong if you can show me a case > where this isn't so. On any given single host, sure. Until that host is compromised and v6 is enabled. But my point was that it's virtually impossible to ensure that's the case across the board for every endpoint device on an enterprise network of any size. And depending on the OS or software used, doing so might just break things or make your system less secure by placing it in an untested state. An OS running in a completely untested state must be assumed to have unknown regressions and security vulnerabilities. And if anyone doesn't believe what I've written about Microsoft operating systems, simply check Technet or ask them. They are completely open and forthright about it. Scott From tmorizot at gmail.com Mon Mar 24 02:46:04 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 21:46:04 -0500 Subject: misunderstanding scale In-Reply-To: <532F8DAE.2040507@mtcc.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <532F8DAE.2040507@mtcc.com> Message-ID: On Mar 23, 2014 8:44 PM, "Michael Thomas" wrote: > It seems to me that the only thing that really matters in v6 wars for enterprise is whether their > content side has a v6 face. Who really cares whether they migrate away from v4 so long as > they make their outward facing content (eg web, etc) available over v6? That's really the key. It doesn't really matter to anyone else. Since I work on the enterprise side rather than the ISP side, I'm arguing that it's really important for the enterprise itself. I'm old enough to have been around when our enterprise had x.25, local Netware, Lanmanager, and Microsoft networks. Everything eventually converged to IP because interoperability both internally and across the Internet is a really important factor. Incompatibility carries an ever increasing cost. Moreover, since most things have IPv6 enabled by default these days, most enterprises who believe they are IPv4 only are deluding themselves. So from a security perspective, they really need to be planning and managing IPv6 internally as well. Scott From rdobbins at arbor.net Mon Mar 24 02:56:29 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 24 Mar 2014 02:56:29 +0000 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> Message-ID: <1EAB7842-DD4B-4758-B9EB-53DA312E859E@arbor.net> On Mar 24, 2014, at 6:37 AM, Timothy Morizot wrote: > You'll pardon my skepticism over claims that unspecified security weaknesses make it impossible to do what we have done and are continuing to > do. All this unfilterable ICMP makes for interesting times - I've already run across ND storms caused remotely (deliberately, IMHO). Insane policies such as /64s for p2p link addresses don't help, either. And the consonance of the English letters 'B', 'C', 'D', & 'E' when spoken aloud is quite likely to prove a major security issue, IMHO. Time for folks to adopt the phonetic alphabet, if they absolutely must communicate verbally. IPv6 has all the security issues associated with IPv4, plus a few new ones which are unique to IPv6. Denying the latter doesn't make them go away. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From SNaslund at medline.com Mon Mar 24 03:07:19 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 03:07:19 +0000 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. A globally routable address does not necessarily mean globally accessible. Any enterprise that cares a wit about network security is going to have a firewall. If you are relying on NAT to protect hosts that have private addresses then you are already in a world of hurt so it won't matter much that IPv6 increases your attack surface because it is already pretty weak. In fact the enterprises running v4 better worry there first. They don't have to worry about the v6 stack too much because their network is not routing v6 yet so are only vulnerable within the network borders or subnets. I think even residential users mostly know that a private address does not make you safe. The same tools that protect your v4 machine are still necessary to protect a v6 machine. In fact, just because I have an IPv6 allocation does not mean I have to allow the world to route to them. There is no reason that a proxy cannot be used on the v6 space you have internally and there is no reason I can't point an entire address range at the outside interface of my firewall. The only difference here is that my firewall no longer has to NAT addresses. Thinking of NAT as a security mechanism is not viable for either address space. An enterprise with a respectable firewall can easily choose to allow or disallow access to any range of addresses that they wish so I don't see much difference between IPv6 and IPv4. I would think in most enterprise models you would have a group of addresses that can be reached from the outside world according to some policy (the DMZ or public NATs in v4 world) and the remainder only have access outbound according to policy (your private space behind your NAT v4 addresses in that world). I don't see how v6 massively changes things for the enterprise and the residential user can easily be protected behind a simple consumer firewall. As far as printers being a more dangerous attack vector than computers, I definitely don't buy that argument. It does not change in v4 or v6. Assuming that both stacks are vulnerable to attack I would be less worried about the printer because I am not aware of any of my printers running malware in v4. I think the PC platform being much more complex and having many more interfaces for active programming like DLLs, Java, ActiveX, etc, are much more the threat. I personally have not seen a DDoS attack launched by printers (they may exist but I am not aware of them). If I was going to design an attack for a printer, I would think that data theft would be the most dangerous. I have wondered about multifunction printers emailing print data to someone but I have never seen that yet. Steven Naslund Chicago IL On Mar 23, 2014 8:44 PM, "Mike Hale" wrote: > "Your attack surface has already expanded whether or not you deploy IPv6." > Not so. If I don't enable IPv6 on my hosts, the attacker can yammer > away via IPv6 all day long with no result. . From frnkblk at iname.com Mon Mar 24 03:08:07 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 23 Mar 2014 22:08:07 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> Message-ID: <001601cf470e$47b1c2a0$d71547e0$@iname.com> Not sure which rural LECs are exempt from competition. Some areas are effectively exempt from facilities-based (i.e. wireline) competition because it's unaffordable, without subsidy, to build a duplicate wireline infrastructure. There are also wireless carriers and WISPs the compete against RLECs, as well as satellite providers. I'm not aware of any exclusivity. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 9:00 PM To: Joe Greco Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 24 03:15:45 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 03:15:45 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <001601cf470e$47b1c2a0$d71547e0$@iname.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> Many rural LECs are not required to provide unbundled network elements. As a network provider you can resell their service but they are not required to provide unbundled elements necessary to compete against them as a facilities based provider. So, for example, in Alamo Tennessee or Northern Wisconsin you can get a T-1 from a competitive carrier that resells their services but you cannot get competitive POTS service. You can buy DSL service from anyone but they are reselling the RLECs DSL access services not just running on their cable pairs. One of the biggest players that specializes in being a rural LEC is Frontier Communications. Yes, there are wireless carriers and satellite providers but especially in rural areas they are not a real viable alternative for high speed data since we know the characteristic of satellite service and WISPs have the same density problem in providing service in rural areas. It is hard for a WISP to be profitable when you only have a handful of customers per mile. Same formula, low density, long distances, high infrastructure per customer cost for the WISP. Steven Naslund Chicago IL -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, March 23, 2014 10:08 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Not sure which rural LECs are exempt from competition. Some areas are effectively exempt from facilities-based (i.e. wireline) competition because it's unaffordable, without subsidy, to build a duplicate wireline infrastructure. There are also wireless carriers and WISPs the compete against RLECs, as well as satellite providers. I'm not aware of any exclusivity. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 9:00 PM To: Joe Greco Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? Steven Naslund Chicago IL From frnkblk at iname.com Mon Mar 24 03:20:33 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 23 Mar 2014 22:20:33 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> Message-ID: <001c01cf4710$0441be60$0cc53b20$@iname.com> I think I understand what you're saying -- you believe that RLECs that don't have to provide UNE's are exempt from competition. I guess I don't see the lack of that requirement meaning that there's no competition -- it just means that the kind of competition is different. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 10:16 PM To: Frank Bulk Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Many rural LECs are not required to provide unbundled network elements. As a network provider you can resell their service but they are not required to provide unbundled elements necessary to compete against them as a facilities based provider. So, for example, in Alamo Tennessee or Northern Wisconsin you can get a T-1 from a competitive carrier that resells their services but you cannot get competitive POTS service. You can buy DSL service from anyone but they are reselling the RLECs DSL access services not just running on their cable pairs. One of the biggest players that specializes in being a rural LEC is Frontier Communications. Yes, there are wireless carriers and satellite providers but especially in rural areas they are not a real viable alternative for high speed data since we know the characteristic of satellite service and WISPs have the same density problem in providing service in rural areas. It is hard for a WISP to be profitable when you only have a handful of customers per mile. Same formula, low density, long distances, high infrastructure per customer cost for the WISP. Steven Naslund Chicago IL -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, March 23, 2014 10:08 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Not sure which rural LECs are exempt from competition. Some areas are effectively exempt from facilities-based (i.e. wireline) competition because it's unaffordable, without subsidy, to build a duplicate wireline infrastructure. There are also wireless carriers and WISPs the compete against RLECs, as well as satellite providers. I'm not aware of any exclusivity. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 9:00 PM To: Joe Greco Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 24 03:20:55 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 03:20:55 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5421888@MUNPRDMBXA1.medline.com> Here is the legal definition of an RLEC. http://definitions.uslegal.com/r/rural-telephone-company/ Steven Naslund Chicago IL -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 10:16 PM To: Frank Bulk Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Many rural LECs are not required to provide unbundled network elements. As a network provider you can resell their service but they are not required to provide unbundled elements necessary to compete against them as a facilities based provider. So, for example, in Alamo Tennessee or Northern Wisconsin you can get a T-1 from a competitive carrier that resells their services but you cannot get competitive POTS service. You can buy DSL service from anyone but they are reselling the RLECs DSL access services not just running on their cable pairs. One of the biggest players that specializes in being a rural LEC is Frontier Communications. Yes, there are wireless carriers and satellite providers but especially in rural areas they are not a real viable alternative for high speed data since we know the characteristic of satellite service and WISPs have the same density problem in providing service in rural areas. It is hard for a WISP to be profitable when you only have a handful of customers per mile. Same formula, low density, long distances, high infrastructure per customer cost for the WISP. Steven Naslund Chicago IL -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, March 23, 2014 10:08 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Not sure which rural LECs are exempt from competition. Some areas are effectively exempt from facilities-based (i.e. wireline) competition because it's unaffordable, without subsidy, to build a duplicate wireline infrastructure. There are also wireless carriers and WISPs the compete against RLECs, as well as satellite providers. I'm not aware of any exclusivity. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 9:00 PM To: Joe Greco Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 24 03:29:17 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 03:29:17 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <001c01cf4710$0441be60$0cc53b20$@iname.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> <001c01cf4710$0441be60$0cc53b20$@iname.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542189B@MUNPRDMBXA1.medline.com> Correct, there is competition to them including the local cable company (if there is one). You just cannot get competitive access to their infrastructure. You have to pay at least the full wholesale rate. That tends to make them the most cost effective choice for wireline services like DSL and local T-1s and makes it impossible to sell facilities based POTS service in their area. The idea was that they are at a competitive disadvantage because the cost of their infrastructure to serve these areas so they deserved some special consideration. If these guys were put in a fully competitive situation that made them insolvent, who would step up to provide POTS service to grandma on the end of that five mile cable run out to the farm. That was the thinking when the Telecom Act passed. The RLEC are where a lot of your "universal access charges" go to help subsidize their buildouts. My point was that there is some regulation in place that recognizes that in some areas (actually a lot of the US in terms of square miles) it is just not cost effective to provide infrastructure in a fully competitive environment. If you think you can make money just selling infrastructure without services, it might work in a major metro area but not in these areas. Steven Naslund -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, March 23, 2014 10:21 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica I think I understand what you're saying -- you believe that RLECs that don't have to provide UNE's are exempt from competition. I guess I don't see the lack of that requirement meaning that there's no competition -- it just means that the kind of competition is different. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 10:16 PM To: Frank Bulk Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Many rural LECs are not required to provide unbundled network elements. As a network provider you can resell their service but they are not required to provide unbundled elements necessary to compete against them as a facilities based provider. So, for example, in Alamo Tennessee or Northern Wisconsin you can get a T-1 from a competitive carrier that resells their services but you cannot get competitive POTS service. You can buy DSL service from anyone but they are reselling the RLECs DSL access services not just running on their cable pairs. One of the biggest players that specializes in being a rural LEC is Frontier Communications. Yes, there are wireless carriers and satellite providers but especially in rural areas they are not a real viable alternative for high speed data since we know the characteristic of satellite service and WISPs have the same density problem in providing service in rural areas. It is hard for a WISP to be profitable when you only have a handful of customers per mile. Same formula, low density, long distances, high infrastructure per customer cost for the WISP. Steven Naslund Chicago IL -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, March 23, 2014 10:08 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Not sure which rural LECs are exempt from competition. Some areas are effectively exempt from facilities-based (i.e. wireline) competition because it's unaffordable, without subsidy, to build a duplicate wireline infrastructure. There are also wireless carriers and WISPs the compete against RLECs, as well as satellite providers. I'm not aware of any exclusivity. Frank -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Sunday, March 23, 2014 9:00 PM To: Joe Greco Cc: nanog at nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? Steven Naslund Chicago IL From jcurran at arin.net Mon Mar 24 03:35:59 2014 From: jcurran at arin.net (John Curran) Date: Mon, 24 Mar 2014 03:35:59 +0000 Subject: arin representation In-Reply-To: References: Message-ID: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> On Mar 23, 2014, at 6:53 PM, Randy Bush wrote: > two questions: > > o of the /24s in the arin region, what percentage are owned by arin > members? Randy - Happy to generate these - two questions for clarity. 1) Should we expand /16's and /8's into the corresponding number of /24's ? (or do you only want those blocks issued originally as /24's to be counted) 2) In terms of categories, we could go strictly with /24's held by ARIN members versus /24's held by non-members (and resulting percentages); note that would be predominantly ISPs since end-users assignments from ARIN are unlikely to be members unless they specifically opted to join. Alternatively, we could provide counts /24's under RSA, /24's under LRSA, and /24's legacy-no-agreement as the three categories of counts desired (and each percentage of the total) So, based on above, would you prefer the /24 space statistics as asked (member/non-member) or rsa/lrsa/legacy-no-agreement? > o of the address holders in the arin region, what percentage are arin > members? Will do. Thanks! /John John Curran President and CEO ARIN From SNaslund at medline.com Mon Mar 24 03:46:11 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 03:46:11 +0000 Subject: arin representation In-Reply-To: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Exactly right John. I think the term "owned" is a problem here. It seems to me that the terms would correctly be "holder" or who the address space was issued to or "user" being the end user using that space. Wouldn't all of the holders be ARIN members unless grandfathered in? Steven Naslund Chicago IL -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, March 23, 2014 10:36 PM To: Randy Bush Cc: North American Network Operators' Group Subject: Re: arin representation On Mar 23, 2014, at 6:53 PM, Randy Bush wrote: > two questions: > > o of the /24s in the arin region, what percentage are owned by arin > members? Randy - Happy to generate these - two questions for clarity. 1) Should we expand /16's and /8's into the corresponding number of /24's ? (or do you only want those blocks issued originally as /24's to be counted) 2) In terms of categories, we could go strictly with /24's held by ARIN members versus /24's held by non-members (and resulting percentages); note that would be predominantly ISPs since end-users assignments from ARIN are unlikely to be members unless they specifically opted to join. Alternatively, we could provide counts /24's under RSA, /24's under LRSA, and /24's legacy-no-agreement as the three categories of counts desired (and each percentage of the total) So, based on above, would you prefer the /24 space statistics as asked (member/non-member) or rsa/lrsa/legacy-no-agreement? > o of the address holders in the arin region, what percentage are arin > members? Will do. Thanks! /John John Curran President and CEO ARIN From randy at psg.com Mon Mar 24 03:51:03 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Mar 2014 12:51:03 +0900 Subject: arin representation In-Reply-To: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> Message-ID: >> o of the /24s in the arin region, what percentage are owned by arin >> members? > 1) Should we expand /16's and /8's into the corresponding number of > /24's ? sorry. i mean the number of /24 equivalents. so yes, expand /7-/23 > 2) In terms of categories, we could go strictly with /24's held by ARIN members > versus /24's held by non-members (and resulting percentages) yep > Alternatively, we could provide counts /24's under RSA, /24's under > LRSA, and /24's legacy-no-agreement as the three categories of counts > desired (and each percentage of the total) that would work, presuming those three categories cover all space, e.g. us military etc. randy From randy at psg.com Mon Mar 24 03:52:27 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Mar 2014 12:52:27 +0900 Subject: arin representation In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: > I think the term "owned" is a problem here. sorry not to get your religious icons correctly. full refund below. jeezus! get a life. randy From SNaslund at medline.com Mon Mar 24 03:57:54 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 03:57:54 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> Sorry Randy, I was not trying to criticize your terminology. I was just wondering about the question trying to be answered here. The holder of an address space and the end user of the address space are two really different things. The holder is often an ARIN member or grandfathered in and an end user (including most ISP customers) are not going to be ARIN members. I know that you and most of the other on here know that they are not "owners" of the space. I was just trying to figure out if your term "owner" refers to the holder of the space or the user of the space. Not trying to make a political statement. I apologize if I gave you the impression that I disapproved of your question. Steve -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Sunday, March 23, 2014 10:52 PM To: Naslund, Steve Cc: John Curran; North American Network Operators' Group Subject: Re: arin representation > I think the term "owned" is a problem here. sorry not to get your religious icons correctly. full refund below. jeezus! get a life. randy From randy at psg.com Mon Mar 24 04:09:51 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Mar 2014 13:09:51 +0900 Subject: arin representation In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> Message-ID: sorry steve. was not chasing down the tree. not clear what a useful measurement would be. randy From jcurran at arin.net Mon Mar 24 04:16:24 2014 From: jcurran at arin.net (John Curran) Date: Mon, 24 Mar 2014 04:16:24 +0000 Subject: arin representation In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> , <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> Message-ID: Steve - Thanks for the reminder; terminology aside, I think we have a good understanding of Randy's request for statistics. We'll put these together asap. /John > On Mar 24, 2014, at 11:58 AM, "Naslund, Steve" wrote: > > Sorry Randy, > > I was not trying to criticize your terminology. I was just wondering about the question trying to be answered here. The holder of an address space and the end user of the address space are two really different things. The holder is often an ARIN member or grandfathered in and an end user (including most ISP customers) are not going to be ARIN members. I know that you and most of the other on here know that they are not "owners" of the space. I was just trying to figure out if your term "owner" refers to the holder of the space or the user of the space. Not trying to make a political statement. > > I apologize if I gave you the impression that I disapproved of your question. > > Steve > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Sunday, March 23, 2014 10:52 PM > To: Naslund, Steve > Cc: John Curran; North American Network Operators' Group > Subject: Re: arin representation > >> I think the term "owned" is a problem here. > > sorry not to get your religious icons correctly. full refund below. > > jeezus! get a life. > > randy From SNaslund at medline.com Mon Mar 24 04:17:07 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 04:17:07 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5421B74@MUNPRDMBXA1.medline.com> No problem. One of the risks in text communication. I guess the usefulness of the measurement would be in what the original question is? If we knew more about what the membership / non-membership question was about it would be easier. I guess if we were really trying to figure out how much address space is within ARIN member "control", just the holder would be enough to know. For example, you could say the X% of space is being used by ARIN members and X% is in use by legacy users. Since the holder could change or revoke access to the space by an end user I guess we could say they control it. For other questions it might be more important to know who is "using" an address space. Like how much space is issued to end users directly by ARIN vs provided to them by service providers. The two types would have very different rules regarding reallocation and such. Steve -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Sunday, March 23, 2014 11:10 PM To: Naslund, Steve Cc: North American Network Operators' Group Subject: Re: arin representation sorry steve. was not chasing down the tree. not clear what a useful measurement would be. randy From SNaslund at medline.com Mon Mar 24 04:18:11 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 04:18:11 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> , <9578293AE169674F9A048B2BC9A081B4B5421B56@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5421B81@MUNPRDMBXA1.medline.com> He is definitely in the authoritative hands :) Steve -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, March 23, 2014 11:16 PM To: Naslund, Steve Cc: Randy Bush; North American Network Operators' Group Subject: Re: arin representation Steve - Thanks for the reminder; terminology aside, I think we have a good understanding of Randy's request for statistics. We'll put these together asap. /John > On Mar 24, 2014, at 11:58 AM, "Naslund, Steve" wrote: > > Sorry Randy, > > I was not trying to criticize your terminology. I was just wondering about the question trying to be answered here. The holder of an address space and the end user of the address space are two really different things. The holder is often an ARIN member or grandfathered in and an end user (including most ISP customers) are not going to be ARIN members. I know that you and most of the other on here know that they are not "owners" of the space. I was just trying to figure out if your term "owner" refers to the holder of the space or the user of the space. Not trying to make a political statement. > > I apologize if I gave you the impression that I disapproved of your question. > > Steve > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Sunday, March 23, 2014 10:52 PM > To: Naslund, Steve > Cc: John Curran; North American Network Operators' Group > Subject: Re: arin representation > >> I think the term "owned" is a problem here. > > sorry not to get your religious icons correctly. full refund below. > > jeezus! get a life. > > randy From nick at pelagiris.org Mon Mar 24 04:24:42 2014 From: nick at pelagiris.org (Nick B) Date: Mon, 24 Mar 2014 00:24:42 -0400 Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: References: <532AF83A.8010805@ispn.net> <77fb8d18d5fb3b46b651f438257e2899@mail.dessus.com> <532EF864.30408@ispn.net> <20140323192751.GD36211@burnout.tpb.net> Message-ID: I thought the 40% I paid in taxes covered prosecution of fraudulent advertising. Nick On Mar 23, 2014 4:02 PM, "Matthew Petach" wrote: > On Sun, Mar 23, 2014 at 12:27 PM, Niels Bakker >wrote: > > > * mpetach at netflight.com (Matthew Petach) [Sun 23 Mar 2014, 20:06 CET]: > > > > Doesn't sound too outlandish. Mind you, I'm sure > >> it would raise costs, as that testing and validation > >> wouldn't be free. But I'm sure we'd all be willing to > >> pay an additional $10/month on our service to be > >> sure it could deliver what was promised, or at least > >> to ensure that what was promised was scaled down > >> to match what could actually be delivered. > >> > > > > Nice strawman you erected there. > > > > > Thanks! I thought it looked quite nice up on its pole. :) > > Now it's time for people to take turns poking > holes in it. ^_^ > > > Thanks! > >> > > > > Yeah, thanks for standing up for industries holding their customers > > hostage to extract rents from companies trying to serve those customers. > > > > I'm not so much standing up for them as > pointing out that simply calling for additional > oversight and regulation often brings increased > costs into the picture. Oddly enough, I'm having > a hard time identifying exactly *where* the money > comes from to pay for government verification of > industry performance claims; I'm sure it's just my > weak search-fu, however, and some person with > more knowledge on the subject will be able to > shed light on how such validation and > compliance testing is typically paid > for. > > > > > > -- Niels. > > > > > Thanks! > > Matt > From jcurran at arin.net Mon Mar 24 04:40:27 2014 From: jcurran at arin.net (John Curran) Date: Mon, 24 Mar 2014 04:40:27 +0000 Subject: arin representation In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net>, <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: <7A985856-5F27-4FAC-8C51-12666B26EC76@arin.net> On Mar 24, 2014, at 12:20 PM, "Naslund, Steve" wrote: > > Exactly right John. I think the term "owned" is a problem here. > > It seems to me that the terms would correctly be "holder" or who the address space was issued to or "user" being the end user using that space. We use address holder to recognize the party with the rights to the address block. > Wouldn't all of the holders be ARIN members unless grandfathered in? If you are an ISP who has an ARIN-issued allocation, you are a member. If you have an end-user assignment or legacy block, you can be a member, but it is not automatic. FYI, /John John Curran President and CEO ARIN From tmorizot at gmail.com Mon Mar 24 04:53:10 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 23 Mar 2014 23:53:10 -0500 Subject: arin representation In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: Unless I misremember, everyone who receives a direct allocation from ARIN and signs an RSA is automatically a member. It's not clear to me what "owner of a /24 network" means in that context. (I don't recall if signing an LRSA in and of itself also makes one a member, since by the time we had signed an LRSA, we had long since received our direct IPv6 allocation under an RSA.) But perhaps Randy is looking for the number of /24 equivalents allocated to legacy resource holders who haven't also received an IPv6 direct allocation or other IPv4 direct allocation under an RSA? Scott On Sun, Mar 23, 2014 at 10:46 PM, Naslund, Steve wrote: > Exactly right John. I think the term "owned" is a problem here. > > It seems to me that the terms would correctly be "holder" or who the > address space was issued to or "user" being the end user using that space. > > Wouldn't all of the holders be ARIN members unless grandfathered in? > > Steven Naslund > Chicago IL > > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Sunday, March 23, 2014 10:36 PM > To: Randy Bush > Cc: North American Network Operators' Group > Subject: Re: arin representation > > On Mar 23, 2014, at 6:53 PM, Randy Bush wrote: > > > two questions: > > > > o of the /24s in the arin region, what percentage are owned by arin > > members? > > Randy - > > Happy to generate these - two questions for clarity. > > 1) Should we expand /16's and /8's into the corresponding number of /24's ? > (or do you only want those blocks issued originally as /24's to be > counted) > > 2) In terms of categories, we could go strictly with /24's held by ARIN > members > versus /24's held by non-members (and resulting percentages); note > that would > be predominantly ISPs since end-users assignments from ARIN are > unlikely to be > members unless they specifically opted to join. Alternatively, we > could provide > counts /24's under RSA, /24's under LRSA, and /24's > legacy-no-agreement as the > three categories of counts desired (and each percentage of the total) > > So, based on above, would you prefer the /24 space statistics as asked > (member/non-member) or rsa/lrsa/legacy-no-agreement? > > > o of the address holders in the arin region, what percentage are arin > > members? > > Will do. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > > From randy at psg.com Mon Mar 24 04:59:12 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Mar 2014 13:59:12 +0900 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: > But perhaps Randy is looking for the number of /24 equivalents > allocated to legacy resource holders who haven't also received an IPv6 > direct allocation or other IPv4 direct allocation under an RSA? what percentage of address space is held by members and what percentage by non-members (lrsa-only is part of the latter)? what percentage of holding organizations are members and what percentage not members (lrsa-only being part of the latter)? i thought this was simple. randy From jcurran at arin.net Mon Mar 24 05:46:59 2014 From: jcurran at arin.net (John Curran) Date: Mon, 24 Mar 2014 05:46:59 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: On Mar 24, 2014, at 12:59 PM, Randy Bush wrote: >> But perhaps Randy is looking for the number of /24 equivalents >> allocated to legacy resource holders who haven't also received an IPv6 >> direct allocation or other IPv4 direct allocation under an RSA? > > what percentage of address space is held by members and what percentage > by non-members (lrsa-only is part of the latter)? > > what percentage of holding organizations are members and what percentage > not members (lrsa-only being part of the latter)? > > i thought this was simple. Randy - It is... we'll put these together. Folks who wish to discuss ARIN address holders and members, please find an ARIN mailing list (such as ppml) Thanks! /John John Curran President and CEO ARIN From Valdis.Kletnieks at vt.edu Mon Mar 24 06:31:38 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 Mar 2014 02:31:38 -0400 Subject: misunderstanding scale In-Reply-To: Your message of "Sun, 23 Mar 2014 16:21:50 -0700." <532F6C8E.9040705@mykolab.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: <206553.1395642698@turing-police.cc.vt.edu> On Sun, 23 Mar 2014 16:21:50 -0700, Paul Ferguson said: > On the other hand, there are beaucoup enterprise networks unwilling to > consider to moving to v6 until there are management, control, > administrative, and security issues addressed. The problem is that for many of those enterprises, the actual understanding of those issues even in the v4 arena is tenuous at best. You know - the same sort of beancounters and auditors with checklists that insist on NAT and won't allow a stateful firewall, or worry about ND attacks but don't check if you have anything in place to defeat ARP flooding.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mark.tinka at seacom.mu Mon Mar 24 06:38:27 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 08:38:27 +0200 Subject: misunderstanding scale In-Reply-To: <532F3783.4080502@ledeuns.net> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> Message-ID: <201403240838.27974.mark.tinka@seacom.mu> On Sunday, March 23, 2014 09:35:31 PM Denis Fondras wrote: > When speaking of IPv6 deployment, I routinely hear about > host security. I feel like it should be stated that this > is *in no way* an IPv6 issue. May the device be ULA, > LLA, GUA or RFC1918-addressed, the device is at risk > anyway. > > If this is the only argument for delaying IPv6 > deployment, this sounds more like FUD to me ;-) I guess it's no surprise that host security is not an IPv4 or IPv6 issue. It's just that with IPv4, the majority of unclean and unupdated hosts have been living behind NAT44. In an ideal IPv6 world, all hosts have GUA's, and in this case, host security becomes a bigger problem, because now the host is directly accessible without a NAT66 in between (we hope). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Mar 24 06:40:44 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 08:40:44 +0200 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323210213.3397F11B3F95@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <532F42AA.9000604@foobar.org> <20140323210213.3397F11B3F95@rock.dv.isc.org> Message-ID: <201403240840.44621.mark.tinka@seacom.mu> On Sunday, March 23, 2014 11:02:13 PM Mark Andrews wrote: > Actually all you have stated in that printer vendors need > to clean up their act and not that one shouldn't expect > to be able to expose a printer to the world. It isn't > hard to do this correctly. It also does not cost much > on a per device basis. Well, all consumer device vendors, really... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Mar 24 06:47:39 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 08:47:39 +0200 Subject: misunderstanding scale In-Reply-To: <20140323231527.50DC711B49E0@rock.dv.isc.org> References: <20140323051037.94159.qmail@joyce.lan> <532F60DD.3030302@foobar.org> <20140323231527.50DC711B49E0@rock.dv.isc.org> Message-ID: <201403240847.39555.mark.tinka@seacom.mu> On Monday, March 24, 2014 01:15:27 AM Mark Andrews wrote: > And there you go putting stricter requirements on > printers that you don't put on laptop, servers. None of > us would put any machines on the net if they had to meet > your printer's requirements. Because, at the very least, a laptop or server can run a stateless packet filter to keep out pokes at ports that may be running by default, but have no business being queried over the network. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Mar 24 06:51:03 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 08:51:03 +0200 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532F55F7.3010802@mykolab.com> Message-ID: <201403240851.03704.mark.tinka@seacom.mu> On Monday, March 24, 2014 01:37:52 AM Timothy Morizot wrote: > Yes. As I said, same general sorts of risks for the most > part as in IPv4. Details differ, but same general types. > My point was that it's mostly FUD to wave the flag of > scary new security weaknesses with no mitigations in > IPv6. It's the same general sort of first hop and link > security issues that exist in IPv4 with similar > mitigations. Not identical, but not radically different > or new either. While the mitigations may not exist yet (like proper firewalls in CPE to protect GUA'ed devices in the home), it still a good idea to bring the risks to light so folk can think about how to get them fixed. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Mar 24 06:53:17 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 08:53:17 +0200 Subject: misunderstanding scale In-Reply-To: References: Message-ID: <201403240853.17543.mark.tinka@seacom.mu> On Monday, March 24, 2014 02:41:00 AM Timothy Morizot wrote: > The original assertion was that there are unaddressed > security weaknesses in IPv6 itself preventing its > adoption. At least that's the way I read it. And that > assertion is mostly FUD. The risks have less to do with IPv6, and more to do with the fact that boxes that lived on RFC 1918 behind NAT44 "security gateways" may now, very possibly, be given a GUA address that now exposes them directly to the Interweb. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kauer at biplane.com.au Mon Mar 24 07:00:46 2014 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 24 Mar 2014 18:00:46 +1100 Subject: misunderstanding scale In-Reply-To: <201403240838.27974.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> Message-ID: <1395644446.3279.26.camel@karl> On Mon, 2014-03-24 at 08:38 +0200, Mark Tinka wrote: > In an ideal IPv6 world, all hosts have GUA's, and in this > case, host security becomes a bigger problem, because now > the host is directly accessible without a NAT66 in between > (we hope). The mantras from my training courses: Addressable is not the same as accessible; routable is not the same as routed. Just because you give every host a globally routable address doesn't mean you have to route them. Just because you route them doesn't mean you have to forward all traffic to or from them. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From mark.tinka at seacom.mu Mon Mar 24 07:23:49 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 09:23:49 +0200 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5421800@MUNPRDMBXA1.medline.com> References: <532BBFEA.70509@cox.net> <201403211119.40822.choprboy@dakotacom.net> <9578293AE169674F9A048B2BC9A081B4B5421800@MUNPRDMBXA1.medline.com> Message-ID: <201403240923.50011.mark.tinka@seacom.mu> On Monday, March 24, 2014 04:26:11 AM Naslund, Steve wrote: > If you are going to try to do a fiber build out to the > home, what would be the monthly cost of just the cable > if I cannot sell services on it and is anyone will the > pay the much. If I have to pay something like say $40 a > month for a fiber connection, how much is service and > equipment going to cost on top of that? If you have the > choice of being a service provider or an infrastructure > provider, why would anyone in their right mind want to > be the infrastructure provider. The infrastructure guy > eats the lion share of the capital expense and takes all > of the risk that someone at the home will continue to > want the service. That separated model just does not > work except in the case of the ILEC which has > capitalized that network over the last 50 years. All dark fibre providers I know of, that eventually start off as pure dark fibre players, will eventually enter into the services game. Even those that do so cautiously, but only deploying DWDM spectrum before to maintain the "darkness" of the fibre, will eventually add yet more serices on top of that. It's just like how wholesale providers have to, at some point, look into enterprise business. You can't just survive being an infrastructure-only provider, in the long run. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Mar 24 07:37:00 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 09:37:00 +0200 Subject: misunderstanding scale In-Reply-To: <1395644446.3279.26.camel@karl> References: <20140323051037.94159.qmail@joyce.lan> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> Message-ID: <201403240937.03567.mark.tinka@seacom.mu> On Monday, March 24, 2014 09:00:46 AM Karl Auer wrote: > The mantras from my training courses: Addressable is not > the same as accessible; routable is not the same as > routed. > > Just because you give every host a globally routable > address doesn't mean you have to route them. Just > because you route them doesn't mean you have to forward > all traffic to or from them. Agree, but also practically, there is a higher likelihood that a good majority of deployments (enterprise, home of wholesale backbones) will be reasonably more accessible over time, not less. You know the new mantras of this day - any computing or communications device is only as good as its connectivity. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jcurran at arin.net Mon Mar 24 08:13:15 2014 From: jcurran at arin.net (John Curran) Date: Mon, 24 Mar 2014 08:13:15 +0000 Subject: TIMELY - Request for expedited input on development process for IANA oversight transition plan References: <8E1240AB-68D1-4B93-8186-D23EE41BB9F7@arin.net> Message-ID: <43F41D4A-1AC5-4258-AB68-4D4A6EE9CC9A@arin.net> NANOGers - On Friday 14 March, the United States Government announced that it intends to transition oversight of key Internet functions (including the Internet Assigned Numbers Authority, or IANA) to the global multi-stakeholder community. NTIA has asked ICANN to facilitate, in consultation with the global multi-stakeholder community, the development of a proposal for the transition of IANA oversight. NTIA announcement - I believe that this is a topic which some in the NANOG community may want to participate in, given the importance of the Internet identifier system to proper operation of the Internet. It clearly has potential for impacting ARIN's performance of its mission, as such we will be discussing this topic at our upcoming ARIN 33 meeting in Chicago next month. This may also be a topic that warrants discussion at NANOG 61 in June. However, on a very expedited basis prior to these events, ICANN is seeking input on the timeline and process to be used for development of the IANA transition plan, and so I am forwarding some information to the extent that any in the NANOG community have views on the plan development process. Note that the deadline for this initial input is 3 days hence (27 March 2014), and a draft process and timeline incorporating input received will be put out by ICANN for community consultation and comment on 7 April 2014. Please find attached the ARIN announcement covering this consultation process; my apologies for disturbing your inbox on a topic that may not be of interest to the entire community, but we'd prefer to be overly informative in matters such as these. FYI, /John John Curran President and CEO ARIN Begin forwarded message: From: John Curran > Subject: [arin-ppml] TIMELY - Request for expedited input to IANA plan development process (was: ARIN and the Evolution of the IANA Functions) Date: March 24, 2014 at 3:47:06 PM GMT+8 To: ARIN > Cc: "arin-ppml at arin.net" > On Mar 20, 2014, at 11:20 PM, ARIN > wrote: Separately, ICANN released a timeline that details its expectations of the multi-stakeholder consultation process. More information on these plans will undoubtedly come out of the upcoming ICANN Meeting in Singapore from 23-27 March. The timeline document is available here: http://www.icann.org/en/about/agreements/iana/functions-transfer-process-14mar14-en.pdf Today at ICANN 49 in Singapore, there was a session which discussed the need to develop an IANA Accountability plan, as it will be necessary to provide NTIA with a community-wide plan for transition of the oversight duties which they presently perform. ICANN is coordinating the effort to develop this plan for IANA transition, and the first step is establishing a formal timeline and process for plan development. ICANN has provided a mail list for expedited input on the _process_ to be used for IANA transition plan development. This includes items such as feedback on the timeline document noted above, engagement processes, etc. The list is here: > (An public archive is also available here: ) The goal is to gather the input by 27 March 2014, and then combine the mail list discussion and the discussions happening at ICANN 49, with the resulting timeline and next steps to be released for public comment and community feedback on 7 April 2014. If you have specific views on the process for development of the IANA transition plan, please contribute promptly. Thank you! /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From kuenzler at init7.net Mon Mar 24 09:23:50 2014 From: kuenzler at init7.net (Fredy Kuenzler) Date: Mon, 24 Mar 2014 10:23:50 +0100 Subject: Survey on Internet Disputes. In-Reply-To: References: Message-ID: <532FF9A6.7020006@init7.net> Am 23.03.2014 05:40, schrieb Kshitiz Verma: > As claimed in http://www.cs.columbia.edu/~misra/news/CD070113.pdf , > 500 to 1000 de-peering happens on a daily basis today. I suppose this is just by technical incapabilities. People leak prefixes, hit max-pref limters, forget to clear sessions or don't bother increasing limits, they migrate gear from Cisco to Brocade or Juniper and cannot recover encrypted MD5 passwords... or management decisions decide to pull from an exchange. I don't consider this "de-peering" a peering dispute or an offensive act. The majority of vanished BGP adjacencies are due to laziness or technical limitations. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From tim at pelican.org Mon Mar 24 10:35:42 2014 From: tim at pelican.org (Tim Franklin) Date: Mon, 24 Mar 2014 10:35:42 +0000 (GMT) Subject: misunderstanding scale In-Reply-To: <532DB095.9040801@ropeguru.com> References: <532DB095.9040801@ropeguru.com> Message-ID: <1187505780.26852.1395657342604.JavaMail.zimbra@pelican.org> > Additional support on my feeling of DO and IPv6, is DO's stance of > directly not even allowing IPv6 tunnels to HE, SiXXs, or any of the > other providers by specifically teliing them not to allow connections > from your IPv4 address space. Say *what*? I've got HE tunnels into DO, purely because they won't get their finger out and offer native v6, but the rest of the service currently outweighs the hassle of tunneling. If this is going to get blocked, I'll be reversing the migration of my existing VPS services elsewhere *into* DO, and starting to look for yet-another provider :( I've already had a rather strange conversation with SIXXS where they swore seven ways from Sunday I couldn't have a tunnel because DO already offer native v6, despite sending them numerous official statements to the contrary, but trying to reason with SIXXS is always "interesting"... Regards, Tim. From bross at pobox.com Mon Mar 24 11:46:09 2014 From: bross at pobox.com (Brandon Ross) Date: Mon, 24 Mar 2014 07:46:09 -0400 (EDT) Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: Since you seem to know a lot more than the rest of us about the value of an IPv4 address, why aren't you buying them for this $1-4 price and then making yourself a billionaire by selling them at $11? On Sat, 22 Mar 2014, Bryan Socha wrote: > As someone growing in the end of ipv4, its all fake. Sure, the rirs will > run out, but that's boring. Don't believe the fake auction sites. > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > there is no shortage and don't lie for rirs with IPS left. > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From wbailey at satelliteintelligencegroup.com Mon Mar 24 11:50:36 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 24 Mar 2014 11:50:36 +0000 Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: Because he doesn?t have 1/4 billion dollars to buy 1-4 dollar price and sell at 10+.. Duh. On 3/24/14, 4:46 AM, "Brandon Ross" wrote: >Since you seem to know a lot more than the rest of us about the value of >an IPv4 address, why aren't you buying them for this $1-4 price and then >making yourself a billionaire by selling them at $11? > >On Sat, 22 Mar 2014, Bryan Socha wrote: > >> As someone growing in the end of ipv4, its all fake. Sure, the rirs >>will >> run out, but that's boring. Don't believe the fake auction sites. >> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 >>for no >> spam and $4 for legacy. Stop the inflation. Millions of IPS >>exist, >> there is no shortage and don't lie for rirs with IPS left. >> > >-- >Brandon Ross Yahoo & AIM: >BrandonNRoss >+1-404-635-6667 ICQ: >2269442 > Skype: >brandonross >Schedule a meeting: http://www.doodle.com/bross > From saku at ytti.fi Mon Mar 24 11:56:44 2014 From: saku at ytti.fi (Saku Ytti) Date: Mon, 24 Mar 2014 13:56:44 +0200 Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: <20140324115644.GA31516@pob.ytti.fi> On (2014-03-24 07:46 -0400), Brandon Ross wrote: > Since you seem to know a lot more than the rest of us about the value of an > IPv4 address, why aren't you buying them for this $1-4 price and then making > yourself a billionaire by selling them at $11? Maybe he does not suspect enough clueless people exist to pay that premium? Starting LIR + company, costs about 4000EUR, this gives you /22 for LIR, putting IPv4 address price at <4EUR. You can do this as many times you want right now, and migrate the LIRs together to avoid subsequent YRC. -- ++ytti From cse332instructor at gmail.com Mon Mar 24 10:01:56 2014 From: cse332instructor at gmail.com (Kshitiz Verma) Date: Mon, 24 Mar 2014 15:31:56 +0530 Subject: Survey on Internet Disputes. In-Reply-To: <532FF9A6.7020006@init7.net> References: <532FF9A6.7020006@init7.net> Message-ID: Thanks for the clarification on the number. I was surprised to see that number too! At the same time, we couldn't even find genuine disputes apart from the ones we shared. It seems there should be more but we just could not find them on the web. On Mon, Mar 24, 2014 at 2:53 PM, Fredy Kuenzler wrote: > Am 23.03.2014 05:40, schrieb Kshitiz Verma: > > As claimed in http://www.cs.columbia.edu/~misra/news/CD070113.pdf , > > 500 to 1000 de-peering happens on a daily basis today. > > I suppose this is just by technical incapabilities. People leak > prefixes, hit max-pref limters, forget to clear sessions or don't bother > increasing limits, they migrate gear from Cisco to Brocade or Juniper > and cannot recover encrypted MD5 passwords... or management decisions > decide to pull from an exchange. > > I don't consider this "de-peering" a peering dispute or an offensive > act. The majority of vanished BGP adjacencies are due to laziness or > technical limitations. > > -- > Fredy Kuenzler > > Init7 (Switzerland) Ltd. > AS13030 > St. Georgen-Strasse 70 > CH-8400 Winterthur > Skype: flyingpotato > Phone: +41 44 315 4400 > Fax: +41 44 315 4401 > Twitter: @init7 / @kuenzler > http://www.init7.net/ > > From tmorizot at gmail.com Mon Mar 24 12:42:07 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Mon, 24 Mar 2014 07:42:07 -0500 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <201403240851.03704.mark.tinka@seacom.mu> References: <532F55F7.3010802@mykolab.com> <201403240851.03704.mark.tinka@seacom.mu> Message-ID: On Mon, Mar 24, 2014 at 1:51 AM, Mark Tinka wrote: > On Monday, March 24, 2014 01:37:52 AM Timothy Morizot wrote: > > > Yes. As I said, same general sorts of risks for the most > > part as in IPv4. Details differ, but same general types. > > My point was that it's mostly FUD to wave the flag of > > scary new security weaknesses with no mitigations in > > IPv6. It's the same general sort of first hop and link > > security issues that exist in IPv4 with similar > > mitigations. Not identical, but not radically different > > or new either. > > While the mitigations may not exist yet (like proper > firewalls in CPE to protect GUA'ed devices in the home), it > still a good idea to bring the risks to light so folk can > think about how to get them fixed. > > While I don't really disagree with that statement, I'm not entirely sure what CPE firewalls and home devices have to do with enterprise deployments, the topic I was discussing. We've been actively working this for the past three years now and have yet to encounter an IPv6 specific enterprise risk for which no appropriate mitigation exists. That's why I called out the assertion that security weaknesses in IPv6 were *preventing* enterprise deployments as FUD. And until someone specifically names some major unmitigated IPv6-only security weakness blocking enterprise deployment instead of vague hand-waving or lists of security risks (as opposed to weaknesses) with well-defined mitigations, I'll stand by that statement. Scott From tmorizot at gmail.com Mon Mar 24 12:56:13 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Mon, 24 Mar 2014 07:56:13 -0500 Subject: misunderstanding scale In-Reply-To: <201403240838.27974.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> Message-ID: On Mon, Mar 24, 2014 at 1:38 AM, Mark Tinka wrote: > On Sunday, March 23, 2014 09:35:31 PM Denis Fondras wrote: > > When speaking of IPv6 deployment, I routinely hear about > > host security. I feel like it should be stated that this > > is *in no way* an IPv6 issue. May the device be ULA, > > LLA, GUA or RFC1918-addressed, the device is at risk > > anyway. > > > > If this is the only argument for delaying IPv6 > > deployment, this sounds more like FUD to me ;-) > > I guess it's no surprise that host security is not an IPv4 > or IPv6 issue. > > It's just that with IPv4, the majority of unclean and > unupdated hosts have been living behind NAT44. > > In an ideal IPv6 world, all hosts have GUA's, and in this > case, host security becomes a bigger problem, because now > the host is directly accessible without a NAT66 in between > (we hope). > > NAT traversal is and has long been fairly trivial. NAT and RFC1918 provides no meaningful host protection whatsoever and never has. The only thing that limits direct access to internal networks is a stateful firewall. (Well, IPS can also drop packets.) That's true for IPv4 and for IPv6. So an enterprise relying n NAT44 and RFC1918 for internal host protection instead of a stateful firewall already has no meaningful security in place. There's no way for IPv6 to make things any worse other than puncturing the delusion under which they are currently operating. Scott From simon.knight at gmail.com Mon Mar 24 13:03:38 2014 From: simon.knight at gmail.com (Simon Knight) Date: Mon, 24 Mar 2014 23:33:38 +1030 Subject: tools similar to stat.ripe.net? In-Reply-To: <532F807C.3000500@winterei.se> References: <2FD50E6D13594B4C93B743BFCF9F528404399878@sbla1-exchange.sb.local> <532F807C.3000500@winterei.se> Message-ID: If you're interested in the visualisation, checkout the "info" link at the bottom of the applet. Specifically: BGPlay was created in collaboration with the Compunet Research Lab at Roma Tre University http://www.dia.uniroma3.it/~compunet/www/view/index.php. The source code is freely available at https://github.com/compunet/BGPlay.js. Refer to http://www.bgplayjs.com for more information about BGPlay.js. Check also the RIPE Labs article regarding the release of BGPlay. if you're after the raw data there's a link in the info to the API calls https://stat.ripe.net/docs/data_api#BGPlay So you should be able to modify either component according to your needs. --Simon On 24 March 2014 11:16, Paul S. wrote: > I'd simply just recommend using the route views servers, you don't really > need the graphical representation. > > > On 3/24/2014 ?? 02:46, Damien Burke wrote: >> >> Hello, >> >> Are there any tools similar to the routing tab at stat.ripe.net ? >> >> To be more specific, I'm looking for the "BGP route visibility" feature. >> >> -Damien > > > From tmorizot at gmail.com Mon Mar 24 13:02:55 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Mon, 24 Mar 2014 08:02:55 -0500 Subject: Ipv4 end, its fake. In-Reply-To: <20140324115644.GA31516@pob.ytti.fi> References: <20140324115644.GA31516@pob.ytti.fi> Message-ID: On Mon, Mar 24, 2014 at 6:56 AM, Saku Ytti wrote: > On (2014-03-24 07:46 -0400), Brandon Ross wrote: > Maybe he does not suspect enough clueless people exist to pay that premium? > > Starting LIR + company, costs about 4000EUR, this gives you /22 for LIR, > putting IPv4 address price at <4EUR. > You can do this as many times you want right now, and migrate the LIRs > together to avoid subsequent YRC. > > Perhaps that's a way to game the last /8 policy in the RIPE region. I don't know enough about it to say one way or another. (And even then it seems like you can only do that for a limited period of time.) But ARIN doesn't have a last /8 policy. When we're out, we're out. Just a small bit in reserve for critical infrastructure. None for ISP startups or end users. If you need IPv4 at that point, best see if you can find some on the market. Scott From saku at ytti.fi Mon Mar 24 13:35:50 2014 From: saku at ytti.fi (Saku Ytti) Date: Mon, 24 Mar 2014 15:35:50 +0200 Subject: Ipv4 end, its fake. In-Reply-To: References: <20140324115644.GA31516@pob.ytti.fi> Message-ID: <20140324133550.GA12410@pob.ytti.fi> On (2014-03-24 08:02 -0500), Timothy Morizot wrote: > Perhaps that's a way to game the last /8 policy in the RIPE region. I don't > know enough about it to say one way or another. (And even then it seems > like you can only do that for a limited period of time.) But ARIN doesn't > have a last /8 policy. When we're out, we're out. Just a small bit in > reserve for critical infrastructure. None for ISP startups or end users. If > you need IPv4 at that point, best see if you can find some on the market. Britons are jovial bunch and will let you incorporate there just like anyone else. -- ++ytti From jgreco at ns.sol.net Mon Mar 24 09:47:41 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 24 Mar 2014 04:47:41 -0500 (CDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> Message-ID: <201403240947.s2O9lfUC056977@aurora.sol.net> > The economic reality is that if I build out an expensive infrastructure I have to pile on as many high priced services as possible to order to maximize the revenue from it. A customer who does not balk at a $200 a month TV/voice/Internet service is not going to be happy getting a bill of $50 a month for a fiber loop. The services are what the customer really wants and where you can add bells and whistle with little added expense. The infrastructure is the expensive part. That's correct, but it is still the wrong way to try to approach the problem. It is simply not practical for N different companies to all try to build out their own networks; we already had the cable and telco monopolies each building out communications infrastructure, which in hindsight seems a little foolish, though it was largely due to the available technologies at the time. > BTW, if you think that NRC infrastructure charge would ever go away, you are kidding yourself. The "N" in NRC means non-recurring. > Here in Illinois, we have been paying for the construction of our tollway in perpetuity. When it was originally built the state promised to remove the tolls as soon as construction costs were recovered. We are still waiting and will be forever. As someone who has worked in the Loop on and off for twenty years, I am fully aware of the history and folly of the Illinois trollway. As an out-of-stater, I've watched the way that the tollways have been modified over the years to more heavily impact those of us coming from the north (Deerfield/Waukegan restructuring), to more heavily impact those paying cash, etc. I note that it wasn't all that many years ago that I was paying 40c cash at the Waukegan toll; today that same toll is $2.80. > If you want, you can criticize the model of the free economic that use profit to determine viability but unfortunately someone pays the bill in the end. Whether it is government funded, a grant, or a commercial enterprise, expenses get recovered. The only difference is that in a free market the customer gets to choose what they pay for. In any other model, everyone pays whether they like it or not. I think our communications model had to develop as a managed monopoly otherwise it would not have been the universal solution that it is today. Now we have to deal with the downside of the monopoly as well. > The problem is that if you accept such a fatalistic position as the only possible way, you end up with Comcast and U-Verse. Unfortunately it is a fallacy to imagine that this is the only way it can be. We've seen last mile infrastructure built by municipalities, for example. We know from the historical examples of gas, water, sewer, power, oh and also telephone and cable that it is perfectly possible to create a monopoly to deliver basic services. The entire point, in fact, of my first post in this thread was to point out that this is in fact what Ma Bell had promised to deliver as part of the NII, to provide the last mile fiber to the house, and then to allow competitive access to that network. They did want - and in fact got - concessions and other inducements to actually deliver such a network, by some accounts as much as $200 billion in incentives, which they promptly kept, but then slowly chipped away at what they were expected to deliver in return, until they were finally allowed to just deliver their own services on the infrastructure. So guess what. In this case, we actually spent the money to do it already and in return we got shafted with U-Verse. ... 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 Mon Mar 24 14:00:09 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 Mar 2014 10:00:09 -0400 Subject: Survey on Internet Disputes. In-Reply-To: Your message of "Mon, 24 Mar 2014 15:31:56 +0530." References: <532FF9A6.7020006@init7.net> Message-ID: <230282.1395669609@turing-police.cc.vt.edu> On Mon, 24 Mar 2014 15:31:56 +0530, Kshitiz Verma said: > At the same time, we couldn't even find genuine disputes apart from the > ones we shared. It seems there should be more but we just could not find > them on the web. Much more common than actual depeering is the passive-agressive version, where you continue to peer but bring a smaller hose to the peering point than the peering partner does. We see a *lot* of reports of the resulting congestion and packet misbehavior on this list... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From oscar.vives at gmail.com Mon Mar 24 14:30:50 2014 From: oscar.vives at gmail.com (Tei) Date: Mon, 24 Mar 2014 15:30:50 +0100 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <201403240947.s2O9lfUC056977@aurora.sol.net> References: <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <201403240947.s2O9lfUC056977@aurora.sol.net> Message-ID: On 24 March 2014 10:47, Joe Greco wrote: >> Here in Illinois, we have been paying for the construction of our tollway in perpetuity. When it was originally built the state promised to remove the tolls as soon as construction costs were recovered. We are still waiting and will be forever. > > As someone who has worked in the Loop on and off for twenty years, I am > fully aware of the history and folly of the Illinois trollway. I heard you guys have been paying taxes for the war against my country (Spain) since 1898. http://en.wikipedia.org/wiki/Federal_telephone_excise_tax So yea. Is much easier to create a new tax, than to remove it. From nick at foobar.org Mon Mar 24 16:02:11 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 24 Mar 2014 16:02:11 +0000 Subject: misunderstanding scale In-Reply-To: <201403240847.39555.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <532F60DD.3030302@foobar.org> <20140323231527.50DC711B49E0@rock.dv.isc.org> <201403240847.39555.mark.tinka@seacom.mu> Message-ID: <53305703.9030100@foobar.org> On 24/03/2014 06:47, Mark Tinka wrote: > Because, at the very least, a laptop or server can run a > stateless packet filter to keep out pokes at ports that may > be running by default, but have no business being queried > over the network. once upon a time, they didn't have host firewalls or packet filters, which was why we ended up with: https://isc.sans.edu/diary/Survival+Time+on+the+Internet/4721 Nick From lowen at pari.edu Mon Mar 24 16:05:28 2014 From: lowen at pari.edu (Lamar Owen) Date: Mon, 24 Mar 2014 12:05:28 -0400 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <001601cf470e$47b1c2a0$d71547e0$@iname.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> Message-ID: <533057C8.7090405@pari.edu> On 03/23/2014 11:08 PM, Frank Bulk wrote: > Not sure which rural LECs are exempt from competition. This is a quagmire;but it boils down to "if the FCC says they're exempt, then they're exempt and have a 'rural monopoly'" (there's a lot of caselaw and a number of FCC Report and Orders (and further Report and Orders and Notices of Rulemaking and Public Notices and the like) on the subject, but it goes back essentially to the definition found in 47 USC ? 153(37) of a "Rural Telephone Company"). Just being covered by an NECA (National Exchange Carriers Association) tariff doesn't automatically grant this, since there is a subsection in 47 CFR ? 61 dealing with "Rural CLEC's" and their exemptions. This landscape is changing constantly, and it has been quite some time since I've traced the threads in the various R&O's and PN's from the FCC on the subject; it would take probably a full week just to get up to date on the current state of things, since it's been five years since I last looked at it. This is one case where you would have to ask a good communications attorney to know for sure. From bill at herrin.us Mon Mar 24 16:20:48 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 12:20:48 -0400 Subject: misunderstanding scale In-Reply-To: <1395644446.3279.26.camel@karl> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> Message-ID: On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: > Addressable is not the same as > accessible; routable is not the same as routed. Indeed. However, all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Mar 24 16:21:08 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 12:21:08 -0400 Subject: misunderstanding scale In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> Message-ID: On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: > I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. Hi Steve, It is your privilege to believe this and to practice it in the networks you operate. Many of the folks you would have deploy IPv6 do not agree. They take comfort in the mathematical impossibility of addressing an internal host from an outside packet that is not part of an ongoing session. These folks find that address-overloaded NAT provides a valuable additional layer of security. Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Mar 24 16:21:27 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 12:21:27 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> Message-ID: On Sat, Mar 22, 2014 at 8:19 PM, Randy Bush wrote: >> don't believe for a moment that v6 to v4 protocol translation is any less >> ugly than CGN. > > it can be stateless You're smarter than that. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Mon Mar 24 16:28:48 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 24 Mar 2014 09:28:48 -0700 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> Message-ID: <53305D40.9020908@mtcc.com> On 03/24/2014 09:20 AM, William Herrin wrote: > On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: >> Addressable is not the same as >> accessible; routable is not the same as routed. > Indeed. However, all successful security is about _defense in depth_. > If it is inaccessible, unrouted, unroutable and unaddressable then you > have four layers of security. If it is merely inaccessible and > unrouted you have two. > > A distinction without a difference, IMHO. Either I can send you an incoming SYN or I can't. The real battle here, IMHO, is to get the next gen CPE vendors to do the right thing. NANOG folks ought to be keeping tabs on the Homenet working group and then DEMAND that any CPE support its security, etc, baselines. Mike From mark.tinka at seacom.mu Mon Mar 24 16:30:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 18:30:20 +0200 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <201403240851.03704.mark.tinka@seacom.mu> Message-ID: <201403241830.24061.mark.tinka@seacom.mu> On Monday, March 24, 2014 02:42:07 PM Timothy Morizot wrote: > While I don't really disagree with that statement, I'm > not entirely sure what CPE firewalls and home devices > have to do with enterprise deployments, the topic I was > discussing. We've been actively working this for the > past three years now and have yet to encounter an IPv6 > specific enterprise risk for which no appropriate > mitigation exists. That's why I called out the assertion > that security weaknesses in IPv6 were *preventing* > enterprise deployments as FUD. And until someone > specifically names some major unmitigated IPv6-only > security weakness blocking enterprise deployment instead > of vague hand-waving or lists of security risks (as > opposed to weaknesses) with well-defined mitigations, > I'll stand by that statement. Agree - the security issues for deploying IPv6 in the enterprise are not that dissimilar from the concerns in the home in as far as assigning GUA's to enterprise printers, staff laptops, surveillance cameras, e.t.c., is concerned. This is not necessarily an issue of IPv6. It's more of an issue having a direct connetion to the Internet without NAT (a.k.a security by obscurity, false sense of security, e.t.c.), and what that means for the host's security. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Mar 24 16:35:18 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 18:35:18 +0200 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403240838.27974.mark.tinka@seacom.mu> Message-ID: <201403241835.19186.mark.tinka@seacom.mu> On Monday, March 24, 2014 02:56:13 PM Timothy Morizot wrote: > NAT traversal is and has long been fairly trivial. NAT > and RFC1918 provides no meaningful host protection > whatsoever and never has. The only thing that limits > direct access to internal networks is a stateful > firewall. (Well, IPS can also drop packets.) That's true > for IPv4 and for IPv6. So an enterprise relying n NAT44 > and RFC1918 for internal host protection instead of a > stateful firewall already has no meaningful security in > place. Don't disagree with you there. I'm saying many an enterprise (small and large) as well as homes operate this way. There is a lot of unlearning to do. The whole issue is that a number of enterprises "may" only feel safe if IPv6 comes with NAT66, probably on top (or not on top) of a stateful IPv6 firewall. We need to think about how to re-train the enterprise, if we don't want to repeat the erasure of the end-to-end model, second time around. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jgreco at ns.sol.net Mon Mar 24 12:31:44 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 24 Mar 2014 07:31:44 -0500 (CDT) Subject: misunderstanding scale In-Reply-To: Message-ID: <201403241231.s2OCViii058805@aurora.sol.net> > On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: > > Addressable is not the same as > > accessible; routable is not the same as routed. > > Indeed. However, all successful security is about _defense in depth_. > If it is inaccessible, unrouted, unroutable and unaddressable then you > have four layers of security. If it is merely inaccessible and > unrouted you have two. Yet there is significant value to providing uniqueness in address space, a property that is incredibly useful. The proponents of this sort of "in depth" "defense" typically view NAT as a way to protect their networks, which it does, in some limited sense, from being addressable from the outside world. The problem is that it has broken one of the key design principles in IPv4, and so we've had to suffer for years under broken NAT regimes and workarounds and other folly. This is overall a bad thing for the Internet, and for the development of future protocols and applications. Time to give up two layers of meaningless security for the riches offered by the vastness of the new address space. If this job were easy, anyone could do it. ... 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 alex.lopez at opsys.com Mon Mar 24 16:36:55 2014 From: alex.lopez at opsys.com (Alexander Lopez) Date: Mon, 24 Mar 2014 16:36:55 +0000 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com>, Message-ID: <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> not to mention the cost in readdressing your entire network when you change an upstream provider. Nat was a fix to a problem of lack of addresses, however, the use of private address space 10/8, 192.168/16 has allowed many to enjoy a simple network addressing scheme. I have and will continue to deploy IPV6, however the ease and simplicity of IPv4 cannot and should not be overlooked. Ipv6 requires a complete reeducation of they way we look at routing and the core of the network. I will not be trolling here, I prefer to troll off the Florida straits for large fish instead. .. -------- Original message -------- From: William Herrin Date:03/24/2014 12:27 PM (GMT-05:00) To: "Naslund, Steve" Cc: NANOG list Subject: Re: misunderstanding scale On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: > I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. Hi Steve, It is your privilege to believe this and to practice it in the networks you operate. Many of the folks you would have deploy IPv6 do not agree. They take comfort in the mathematical impossibility of addressing an internal host from an outside packet that is not part of an ongoing session. These folks find that address-overloaded NAT provides a valuable additional layer of security. Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mark.tinka at seacom.mu Mon Mar 24 16:37:55 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Mar 2014 18:37:55 +0200 Subject: misunderstanding scale In-Reply-To: <53305703.9030100@foobar.org> References: <20140323051037.94159.qmail@joyce.lan> <201403240847.39555.mark.tinka@seacom.mu> <53305703.9030100@foobar.org> Message-ID: <201403241837.55752.mark.tinka@seacom.mu> On Monday, March 24, 2014 06:02:11 PM Nick Hilliard wrote: > once upon a time, they didn't have host firewalls or > packet filters, which was why we ended up with: > > https://isc.sans.edu/diary/Survival+Time+on+the+Internet/ > 4721 :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From SNaslund at medline.com Mon Mar 24 16:43:04 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 16:43:04 +0000 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54220AB@MUNPRDMBXA1.medline.com> I think it would be just as easy to claim that breaking the end-to-end model is more of a security concern that lack of NAT. Having the NAT is essentially condoning a permanent man-in-the-middle. A lot of customers do believe that NAT adds to their security. I would advise them however that it probably offers a lot less than they think. It is a very common technique get an inside computer to establish a connection out to a bad host. That's how most of the malware today works (through the "extra layer of defense that NAT provides),so I am not seeing how much worse IPv6 would make things. If you are going to allow inbound connections to your internal machines from anywhere you are unsecure. How hard is it to block inbound connections with a firewall? If the user cannot accomplish that then there is not much we can do to save them. I suppose NAT could add some sort of minimal additional assurance but if you cannot pull off a simple firewall or routing policy you are already unable to adequately secure your network. I see no technical reason that someone could not implement a transparent proxy whether it is v4 or v6. It does not really violate the end-to-end model because the proxy connects to the remote system and the local system connects to the proxy so there really is not an end-to-end connection as much as there are two separate connections. For that matter, is there really a technical reason that you could not do a NAT if you wanted to with IPv6? All we are really talking about here is replacing one address with another. Could you not get something similar by translating a routable IPv6 address to a link local address? I don't think I would want to but I suppose you could if you are really married to NAT and private addressing. I, for one, will not miss NAT very much. I have seen quite a few misconfigured NATs and holes being punched through firewalls because applications don't like NATs to believe that they are at least as much trouble as they are worth as a security feature. Steven Naslund -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Monday, March 24, 2014 11:21 AM To: Karl Auer Cc: nanog at nanog.org Subject: Re: misunderstanding scale On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: > Addressable is not the same as > accessible; routable is not the same as routed. Indeed. However, all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SNaslund at medline.com Mon Mar 24 16:53:47 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 16:53:47 +0000 Subject: misunderstanding scale In-Reply-To: <201403241835.19186.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <201403240838.27974.mark.tinka@seacom.mu> <201403241835.19186.mark.tinka@seacom.mu> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54220DA@MUNPRDMBXA1.medline.com> If they have a stateful IPv6 firewall (which they should and which most firewall vendors support), they already have what they need to prevent their internal systems from being accessible from the outside. If you are an enterprise and you don't have a stateful firewall, you are in trouble from a security standpoint whether you run v4 or v6. If you cannot configure a stateful firewall to block connections being initiated from outside, you are not qualified to be working with the firewall, v4 or v6 does not matter. If someone is relying on NAT in case their firewall is misconfigured, they have major issues with security. In the home, I am not sure what the major issue is there either. How many CPE devices have you seen that do not implement basic firewall functionality? People may not use them correctly but that is no more an issue with v6 than it is with v4. Most CPE even comes out of the box blocking inbound connections by default. Steve -----Original Message----- From: Mark Tinka [mailto:mark.tinka at seacom.mu] Sent: Monday, March 24, 2014 11:35 AM To: Timothy Morizot Cc: NANOG list Subject: Re: misunderstanding scale >>Don't disagree with you there. >>I'm saying many an enterprise (small and large) as well as homes operate this way. There is a lot of unlearning to do. >>The whole issue is that a number of enterprises "may" only feel safe if IPv6 comes with NAT66, probably on top (or not on top) of a stateful IPv6 firewall. >>We need to think about how to re-train the enterprise, if we don't want to repeat the erasure of the end-to-end model, second time around. >>Mark. From patrick at ianai.net Mon Mar 24 17:05:11 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 24 Mar 2014 13:05:11 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> Message-ID: <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> On Mar 24, 2014, at 12:21, William Herrin wrote: > On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: >> I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. > Many of the folks you would have deploy IPv6 do not agree. They take > comfort in the mathematical impossibility of addressing an internal > host from an outside packet that is not part of an ongoing session. > These folks find that address-overloaded NAT provides a valuable > additional layer of security. > > Some folks WANT to segregate their networks from the Internet via a > general-protocol transparent proxy. They've had this capability with > IPv4 for 20 years. IPv6 poorly addresses their requirement. NAT i s not required for the above. Any firewall can stop incoming packets unless they are part of an established session. NAT doesn't add much of anything, especially given that you can have one-to-one NAT. -- TTFN, patrick From bill at herrin.us Mon Mar 24 17:08:46 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 13:08:46 -0400 Subject: misunderstanding scale In-Reply-To: <53305D40.9020908@mtcc.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> <53305D40.9020908@mtcc.com> Message-ID: On Mon, Mar 24, 2014 at 12:28 PM, Michael Thomas wrote: > On 03/24/2014 09:20 AM, William Herrin wrote: >> On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: >>> Addressable is not the same as >>> accessible; routable is not the same as routed. >> >> Indeed. However, all successful security is about _defense in depth_. >> If it is inaccessible, unrouted, unroutable and unaddressable then you >> have four layers of security. If it is merely inaccessible and >> unrouted you have two. > > A distinction without a difference, IMHO. Either I can send you an incoming > SYN or I can't. Hi Mike, You can either press the big red button and fire the nukes or you can't, so what difference how many layers of security are involved with the "Football?" I say this with the utmost respect, but you must understand the principle of defense in depth in order to make competent security decisions for your organization. Smart people disagree on the details but the principle is not only iron clad, it applies to all forms of security, not just IP network security. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Mar 24 17:13:43 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 13:13:43 -0400 Subject: misunderstanding scale In-Reply-To: <201403241231.s2OCViii058805@aurora.sol.net> References: <201403241231.s2OCViii058805@aurora.sol.net> Message-ID: On Mon, Mar 24, 2014 at 8:31 AM, Joe Greco wrote: >> all successful security is about _defense in depth_. >> If it is inaccessible, unrouted, unroutable and unaddressable then you >> have four layers of security. If it is merely inaccessible and >> unrouted you have two. > > Time to give up two layers of meaningless security for the riches offered > by the vastness of the new address space. Hi Joe, You'd expect folks to give up two layers of security at exactly the same time as they're absorbing a new network protocol with which they're yet unskilled? Does that make sense to you from a risk-management standpoint? -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Mon Mar 24 17:17:09 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Mar 2014 13:17:09 -0400 (EDT) Subject: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica In-Reply-To: Message-ID: <30408533.12487.1395681429532.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > Hey, what part of "up to 8Mbps" is an assurance, that the system supports > 8Mbps from all customers 24x7 simultaneously? Only the former can be > delivered inexpensively; the latter from large service providers is a > business service that doesn't seem to be in the compass of ordinary > mortals. Because this is the well-known industry standard; it can't > accurately be described as one of deception. [ started this, and then got tied up with community theatre. Oops. ] No part of it is, legally; all of it is, to the paying customer who isn't versed in oversubscription. Oversubscription (what I used to call bandwidth-surfing when I had to do it -- 1995, 60 33k6 modems on a 256k FR link :-), will be around for a long time to come. How far you can *push* it without losing customers is the question, and the feedback loop is slow, and the response to a new provider who doesn't push it as hard is usually sharper than you can survive... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bill at herrin.us Mon Mar 24 17:17:39 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 13:17:39 -0400 Subject: misunderstanding scale In-Reply-To: <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> Message-ID: On Mon, Mar 24, 2014 at 1:05 PM, Patrick W. Gilmore wrote: > On Mar 24, 2014, at 12:21, William Herrin wrote: >> Some folks WANT to segregate their networks from the Internet via a >> general-protocol transparent proxy. They've had this capability with >> IPv4 for 20 years. IPv6 poorly addresses their requirement. > > NAT i s not required for the above. Any firewall can stop incoming packets unless they are part of an established session. NAT doesn't add much of anything, especially given that you can have one-to-one NAT. Hi Patrick, What sort of traction are you getting from that argument with enterprise security folks who object to deploying IPv6 because of NAT? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Mon Mar 24 17:18:00 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Mar 2014 13:18:00 -0400 (EDT) Subject: =?utf-8?Q?Re:_Level_3_blames_Internet_slowdowns_on_ISPs=C3=A2_EU?= =?utf-8?Q?RO(tm)_re_fusal_to_upgrade_networks_|_Ars_Technica?= In-Reply-To: <3A4324BB-975E-48CE-B826-B8F04174C274@delong.com> Message-ID: <7743481.12489.1395681480943.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > The only way we will ever see real and true competition is if we > prohibit Layer 2+ providers from playing in the Layer 1 space. > > At some point, we will need to recognize that for the population > densities in the vast majority of the united States (including most > urban areas), Layer 1 is effectively a natural monopoly and you will > rarely get more than one provider installing any given media type. An > independent layer 1 provider required to provide equal access to all > competing layer 2+ providers in each are would drive increased > competition in L2+ services. Gee; what a great idea. Cheers, -- jr ':-)' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Mar 24 17:22:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Mar 2014 13:22:56 -0400 (EDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <3b7925b6836a99dda6b01c02a18b0401.squirrel@66.201.44.180> Message-ID: <8667772.12493.1395681776304.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Bob Evans" > Well, don't forget the labor, taxes, business licenses fees, county > taxes on chairs, Obama care, accountants and time required. $ enable # conf t (conf)# Obamacare ^ command not understood Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Mar 24 17:25:07 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Mar 2014 13:25:07 -0400 (EDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> Message-ID: <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Steve Naslund" > What do you mean by average monthly bill? That is the issue here. The > average monthly bill includes the services you are getting. In the > Chicago area a fiber optic access circuit unbundled from the imcumbent > carrier to a competitive carrier is something like $10 a month or so. > How could you possibly think you can fund a build out in a new area > for that price? It may be possible to pay for that over 20 years. The > problem is that no one goes into business to break even over 20 years. Well, Steve, happens we had this conversation in some detail last year when I was up for a City IT director position, and contemplating fibering 12,000 passings. The magic number is apparently $700-800 per passing, not the $2400 you seem to suggest... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jgreco at ns.sol.net Mon Mar 24 13:25:42 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 24 Mar 2014 08:25:42 -0500 (CDT) Subject: misunderstanding scale In-Reply-To: Message-ID: <201403241325.s2ODPg35059533@aurora.sol.net> > Hi Mike, > > You can either press the big red button and fire the nukes or you > can't, so what difference how many layers of security are involved > with the "Football?" > > I say this with the utmost respect, but you must understand the > principle of defense in depth in order to make competent security > decisions for your organization. Smart people disagree on the details > but the principle is not only iron clad, it applies to all forms of > security, not just IP network security. The problem here is that what's actually going on is that you're now enshrining as a "security" device a hacky, ill-conceived workaround for a lack of flexibility/space/etc in IPv4. NAT was not designed to act as a security feature. If you want more layers of security, put a second firewall into your design. Don't perpetuate horrid IPv4 hacks that were necessary for specific reasons into IPv6 where those hacks are no longer needed. ... 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 Mon Mar 24 13:27:51 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 24 Mar 2014 08:27:51 -0500 (CDT) Subject: misunderstanding scale In-Reply-To: Message-ID: <201403241327.s2ODRpoB059546@aurora.sol.net> > On Mon, Mar 24, 2014 at 8:31 AM, Joe Greco wrote: > >> all successful security is about _defense in depth_. > >> If it is inaccessible, unrouted, unroutable and unaddressable then you > >> have four layers of security. If it is merely inaccessible and > >> unrouted you have two. > > > > Time to give up two layers of meaningless security for the riches offered > > by the vastness of the new address space. > > Hi Joe, > > You'd expect folks to give up two layers of security at exactly the > same time as they're absorbing a new network protocol with which > they're yet unskilled? Does that make sense to you from a > risk-management standpoint? Actually, yes, it does. Using the product as intended is substantially less risky than trying to figure out how to use some sort of proxy or gateway functionality to emulate NAT, and then screwing that up. If you're afraid that you're insufficiently competent, help for hire is available, as are two levels of firewalling, which isn't really a bad idea anyways. ... 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 laszlo at heliacal.net Mon Mar 24 17:35:18 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 24 Mar 2014 17:35:18 +0000 Subject: misunderstanding scale In-Reply-To: <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> Message-ID: On Mar 24, 2014, at 5:05 PM, "Patrick W. Gilmore" wrote: > On Mar 24, 2014, at 12:21, William Herrin wrote: >> On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: > >>> I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. > >> Many of the folks you would have deploy IPv6 do not agree. They take >> comfort in the mathematical impossibility of addressing an internal >> host from an outside packet that is not part of an ongoing session. >> These folks find that address-overloaded NAT provides a valuable >> additional layer of security. >> >> Some folks WANT to segregate their networks from the Internet via a >> general-protocol transparent proxy. They've had this capability with >> IPv4 for 20 years. IPv6 poorly addresses their requirement. > It's unfortunate that it is the way it is, but many enterprise people have this ingrained in them - they don't want to be connected to the internet except for a few exceptions. Just the fact that they can't ping their machines gives them a warm and fuzzy. In a run-of-the-mill default NAT setup, you can deploy a network printer with no security and nobody from the internet can print to it. It's default deny, even without setting anything else up, by virtue of not being on the internet and not having an address. I know there are ways to subvert a NAT but that applies to perimeter and host firewalls too. IPv6 global numbers are great for those of us that actually want to connect to the internet, but enterprise people with rfc1918 numbering have gotten used to being disconnected, and while most of us know that it's trivial to firewall IPv6, it's still a big jump from using a NAT/proxy to being 'on the internet'. It's even more complex if it's only halfway and there are two different protocols to manage. People will always resist change, and in this case, why should they change when it's only going to make their job harder? Makes sense to me, but I wish it weren't that way. They will probably just find ways to proxy and NAT IPv6 too, so that it fits the IPv4 model with 'private' addresses. Just look at what's been happening with UDP floods. It's scared people enough that some are just blocking certain UDP ports or UDP completely. I imagine we will soon see some big IPv6 specific attacks that result in crashing hosts/routers, and that will just make people resist it harder, because why would they want that headache? I think in a lot of situations, unless their business is networking specifically, the network is considered good enough if you can browse (most) webpages. For IPv6 only sites, that could be accomplished with a web proxy setting on all the desktops. It's not really right, it's inefficient, error prone and bunch of other things, but that doesn't mean people won't do it. They do all this today with v4 anyway, so if anything, the 'wrong way' is easier there since they're used to doing it. There has to be some big compelling reason to convince people that global addressing is the right way. We all know the reasons but they're obviously not good enough for enterprise security people. -Laszlo > NAT i s not required for the above. Any firewall can stop incoming packets unless they are part of an established session. NAT doesn't add much of anything, especially given that you can have one-to-one NAT. > > -- > TTFN, > patrick > > From bill at herrin.us Mon Mar 24 17:37:06 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 13:37:06 -0400 Subject: misunderstanding scale In-Reply-To: <201403241325.s2ODPg35059533@aurora.sol.net> References: <201403241325.s2ODPg35059533@aurora.sol.net> Message-ID: On Mon, Mar 24, 2014 at 9:25 AM, Joe Greco wrote: >> I say this with the utmost respect, but you must understand the >> principle of defense in depth in order to make competent security >> decisions for your organization. Smart people disagree on the details >> but the principle is not only iron clad, it applies to all forms of >> security, not just IP network security. > > The problem here is that what's actually going on is that you're now > enshrining as a "security" device a hacky, ill-conceived workaround > for a lack of flexibility/space/etc in IPv4. NAT was not designed > to act as a security feature. Hi Joe, That would be one of those "details" on which smart people disagree. In this case, I think you're wrong. Modern NAT superseded the transparent proxies and bastion hosts of the '90s because it does the same security job a little more smoothly. And proxies WERE designed to act as a security feature. >> You'd expect folks to give up two layers of security at exactly the >> same time as they're absorbing a new network protocol with which >> they're yet unskilled? Does that make sense to you from a >> risk-management standpoint? > > Actually, yes, it does. Using the product as intended is substantially > less risky than trying to figure out how to use some sort of proxy or > gateway functionality to emulate NAT, and then screwing that up. What sort of traction are you getting from that argument when you speak with enterprise security folks? 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 Mon Mar 24 17:37:41 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 Mar 2014 13:37:41 -0400 Subject: misunderstanding scale In-Reply-To: Your message of "Mon, 24 Mar 2014 13:13:43 -0400." References: <201403241231.s2OCViii058805@aurora.sol.net> Message-ID: <8555.1395682661@turing-police.cc.vt.edu> On Mon, 24 Mar 2014 13:13:43 -0400, William Herrin said: > You'd expect folks to give up two layers of security at exactly the > same time as they're absorbing a new network protocol with which > they're yet unskilled? Does that make sense to you from a > risk-management standpoint? The problem is that the two layers of "security" that they're "giving up" are made from the same fabric as the Emperor's new clothes.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From SNaslund at medline.com Mon Mar 24 17:44:31 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 17:44:31 +0000 Subject: misunderstanding scale In-Reply-To: <53306C7F.30001@xyonet.com> References: <20140323051037.94159.qmail@joyce.lan> <201403240838.27974.mark.tinka@seacom.mu> <201403241835.19186.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B54220DA@MUNPRDMBXA1.medline.com> <53306C7F.30001@xyonet.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54221D3@MUNPRDMBXA1.medline.com> I don't buy that one at all. Grandma does not care or know about ipv4 or ipv6. When the ipv4 CPE gets installed it blocks inbound connections by default, why would ipv6 be any different? Windows firewall if she is relying on that should not have any problems with v6 than it does with v4. I am also pretty sure that grandma does not care that NAT is present or not. In fact, grandma's cell phone might already using v6. If the equipment does not work right out of the box, that is the equipment supplier or service provider problem. Do you really believe that most people deploying home gateways understand ipv4, NAT, or stateful firewalls? No, they plug it in and the defaults should work for them. It might require an engineering degree (or reading) to understand how IPv6 works however grandma does not need to know how IPv6 works or even how a network works. She plugs in the CPE, plugs in her PC and off you go. The smart people on this list are to ones that need to know how is works. If we can't make the customer experience transparent to them, then bad on us. Steve -----Original Message----- From: Curtis Maurand [mailto:cmaurand at xyonet.com] Sent: Monday, March 24, 2014 12:34 PM To: Naslund, Steve Subject: Re: misunderstanding scale On 3/24/2014 12:53 PM, Naslund, Steve wrote: > If they have a stateful IPv6 firewall (which they should and which most firewall vendors support), they already have what they need to prevent their internal systems from being accessible from the outside. If you are an enterprise and you don't have a stateful firewall, you are in trouble from a security standpoint whether you run v4 or v6. If you cannot configure a stateful firewall to block connections being initiated from outside, you are not qualified to be working with the firewall, v4 or v6 does not matter. If someone is relying on NAT in case their firewall is misconfigured, they have major issues with security. > > In the home, I am not sure what the major issue is there either. How many CPE devices have you seen that do not implement basic firewall functionality? People may not use them correctly but that is no more an issue with v6 than it is with v4. Most CPE even comes out of the box blocking inbound connections by default. > But grandma doesn't have the ability to deploy a statefull firewall at her house. She doesn't even understand what statefull means putting up a NAT firewall on an IPv4 network is simple and it's easy. It provides adequate protection of one's internal network from the outside. You plug them in and they work. IPv6 just about requires an engineering degree to understand it. Nobody thought about simplicity with it. From SNaslund at medline.com Mon Mar 24 17:53:47 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 17:53:47 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> References: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54221F9@MUNPRDMBXA1.medline.com> That number will change depending on distance, terrain, and a lot of other factors. I have personally installed a lot of outside plant fiber and $700 can turn into $2400 the first time you find a rock or need to add a manhole somewhere. It also depends on distance between customers and their distance from a right of way. Are we talking New York labor or Atlanta labor charges? Big difference there. Did the municipality require conduit? Some do and it becomes much more expensive. Are you digging up any pavement or direct boring it all? It does not matter much though. Bottom line is that if you can get a residential customer to pay even $700 construction charge very often, I will be impressed. Steve -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Monday, March 24, 2014 12:25 PM To: NANOG Subject: Re: Level 3 blames Internet slowdowns on Technica ----- Original Message ----- >> From: "Steve Naslund" >> What do you mean by average monthly bill? That is the issue here. The >> average monthly bill includes the services you are getting. In the >> Chicago area a fiber optic access circuit unbundled from the imcumbent >> carrier to a competitive carrier is something like $10 a month or so. >> How could you possibly think you can fund a build out in a new area >> for that price? It may be possible to pay for that over 20 years. The > problem is that no one goes into business to break even over 20 years. >Well, Steve, happens we had this conversation in some detail last year when I was up for a City IT director position, and contemplating fibering >12,000 passings. >The magic number is apparently $700-800 per passing, not the $2400 you seem to suggest... From patrick at ianai.net Mon Mar 24 18:19:41 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 24 Mar 2014 14:19:41 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> Message-ID: <37811B4D-F848-40B3-B5FF-428B005DF06F@ianai.net> On Mar 24, 2014, at 13:17 , William Herrin wrote: > On Mon, Mar 24, 2014 at 1:05 PM, Patrick W. Gilmore wrote: >> On Mar 24, 2014, at 12:21, William Herrin wrote: >>> Some folks WANT to segregate their networks from the Internet via a >>> general-protocol transparent proxy. They've had this capability with >>> IPv4 for 20 years. IPv6 poorly addresses their requirement. >> >> NAT i s not required for the above. Any firewall can stop incoming packets unless they are part of an established session. NAT doesn't add much of anything, especially given that you can have one-to-one NAT. > > Hi Patrick, > > What sort of traction are you getting from that argument with > enterprise security folks who object to deploying IPv6 because of NAT? The _good_ security people complain about deploying NAT in v4 or v6, because they don't think it is "security". What sort of traction do you get with security people when you tell them NAT == "security in depth"? If you mean "do people who get hired by $CORPORATION and do not know anything about security get upset when you tell them something they did not know?" The answer is "frequently, yes". I'm not sure what that has to do with the discussion at hand, though. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Lee at asgard.org Mon Mar 24 18:23:03 2014 From: Lee at asgard.org (Lee Howard) Date: Mon, 24 Mar 2014 14:23:03 -0400 Subject: misunderstanding scale In-Reply-To: References: <201403241325.s2ODPg35059533@aurora.sol.net> Message-ID: On 3/24/14 1:37 PM, "William Herrin" wrote: >On Mon, Mar 24, 2014 at 9:25 AM, Joe Greco wrote: >>> I say this with the utmost respect, but you must understand the >>> principle of defense in depth in order to make competent security >>> decisions for your organization. Smart people disagree on the details >>> but the principle is not only iron clad, it applies to all forms of >>> security, not just IP network security. >> >> The problem here is that what's actually going on is that you're now >> enshrining as a "security" device a hacky, ill-conceived workaround >> for a lack of flexibility/space/etc in IPv4. NAT was not designed >> to act as a security feature. > >Hi Joe, > >That would be one of those "details" on which smart people disagree. >In this case, I think you're wrong. Modern NAT superseded the >transparent proxies and bastion hosts of the '90s because it does the >same security job a little more smoothly. And proxies WERE designed to >act as a security feature. What kinds of devices are we talking about here? Are we talking about the default NAT on a home network router, or an enterprise-level NAT operating on a firewall? The NAT on home gateways may be a full-cone NAT. This allows easier setup of online gaming, for instance, or other applications where an inbound SYN is required. This provides no security, since as soon as a connection is established, all traffic is allowed. Even restricted cone NATs provide little protection, just a bit of guessing that even a human could manage. If we're talking about an enterprise firewall, then I don't understand--we're talking about a firewall. If it implements a symmetric NAT in addition to a stateful firewall, then it's implementing the same function twice. But, hey, it's your network, if security-through-obscurity is one of your defense in depth layers, that's fine. You may use NPT66 with ULA; that function is defined. Lee From tmorizot at gmail.com Mon Mar 24 18:37:16 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Mon, 24 Mar 2014 13:37:16 -0500 Subject: misunderstanding scale In-Reply-To: <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> Message-ID: On Mon, Mar 24, 2014 at 11:36 AM, Alexander Lopez wrote: > not to mention the cost in readdressing your entire network when you > change an upstream provider. > > Nat was a fix to a problem of lack of addresses, however, the use of > private address space 10/8, 192.168/16 has allowed many to enjoy a simple > network addressing scheme. > Which is, of course, precisely the use case that ULA and NPTv6 (RFC 6296, not to be confused with a non-existent NAT66) addresses.... From bill at herrin.us Mon Mar 24 18:38:53 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 14:38:53 -0400 Subject: misunderstanding scale In-Reply-To: References: <201403241325.s2ODPg35059533@aurora.sol.net> Message-ID: On Mon, Mar 24, 2014 at 2:23 PM, Lee Howard wrote: > On 3/24/14 1:37 PM, "William Herrin" wrote: >>That would be one of those "details" on which smart people disagree. >>In this case, I think you're wrong. Modern NAT superseded the >>transparent proxies and bastion hosts of the '90s because it does the >>same security job a little more smoothly. And proxies WERE designed to >>act as a security feature. > > What kinds of devices are we talking about here? Are we talking about the > default NAT on a home network router, or an enterprise-level NAT operating > on a firewall? Hi Lee, I don't see NAT as a deployment issue for residential networks. Most folks just hook their computer up to whatever CPE the vendor sends them without any further attention. > If we're talking about an enterprise firewall, then I don't > understand--we're talking about a firewall. If it implements a symmetric > NAT in addition to a stateful firewall, then it's implementing the same > function twice. But, hey, it's your network, if > security-through-obscurity is one of your defense in depth layers, that's > fine. "Obscurity" offers one or more defense layers. If you disagree, post your passwords here. Unaddressibility is a second defense layer. Stateful firewalling is a third. You observe that all three are accomplished by the same lines of code in the firewall. The firewall doesn't exist in a void. It's part of a system. That system is configured with unroutable addresses or it isn't. It has many public addresses or it doesn't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tmorizot at gmail.com Mon Mar 24 18:46:06 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Mon, 24 Mar 2014 13:46:06 -0500 Subject: misunderstanding scale In-Reply-To: <201403241325.s2ODPg35059533@aurora.sol.net> References: <201403241325.s2ODPg35059533@aurora.sol.net> Message-ID: On Mon, Mar 24, 2014 at 8:25 AM, Joe Greco wrote: > Bill Herrin wrote: > > I say this with the utmost respect, but you must understand the > > principle of defense in depth in order to make competent security > > decisions for your organization. Smart people disagree on the details > > but the principle is not only iron clad, it applies to all forms of > > security, not just IP network security. > > The problem here is that what's actually going on is that you're now > enshrining as a "security" device a hacky, ill-conceived workaround > for a lack of flexibility/space/etc in IPv4. NAT was not designed > to act as a security feature. > > If you want more layers of security, put a second firewall into your > design. Don't perpetuate horrid IPv4 hacks that were necessary for > specific reasons into IPv6 where those hacks are no longer needed. > With 24 million small businesses in the US alone, that's way too many > apples. > Precisely. Repeat after me. NAT is not a security feature. Period. It offers no meaningful protection. We've known how to bypass NATs almost from the moment they were developed. Defense in depth has nothing to do with NAT. In our enterprise deployment, it involves two layers of heterogeneous firewalls (protecting multiple security zones from the internal network and the Internet), IPS/IDS, web filters, mail filters, and an active CSIRC monitoring, analyzing, and responding to threats and attacks. If you're an enterprise and don't have something similar in place, then you have no security defense in depth. Thanks goodness our Cybersecurity organization actually comprehends real computer and network security instead of promoting snake oil. Scott From tmorizot at gmail.com Mon Mar 24 18:50:49 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Mon, 24 Mar 2014 13:50:49 -0500 Subject: misunderstanding scale In-Reply-To: References: <201403241325.s2ODPg35059533@aurora.sol.net> Message-ID: On Mon, Mar 24, 2014 at 12:37 PM, William Herrin wrote: > What sort of traction are you getting from that argument when you > speak with enterprise security folks? > Actually, I never even had to make the argument in our enterprise. Our cybersecurity organization already knew that overall NAT reduced rather than enhanced network security and had a deeper real understanding of security defense in depth than I did. I never had to convince anyone that NAT wasn't a security feature. It sounds like we have so many enterprises that do security poorly because many don't even understand the basics. Scott From jgreco at ns.sol.net Mon Mar 24 14:48:35 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 24 Mar 2014 09:48:35 -0500 (CDT) Subject: misunderstanding scale In-Reply-To: Message-ID: <201403241448.s2OEmZah060675@aurora.sol.net> > it involves two layers of heterogeneous firewalls (protecting multiple ^^^^^^^^^^^^^ Ugh. Knew I was forgetting something. ... 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 SNaslund at medline.com Mon Mar 24 18:55:37 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 18:55:37 +0000 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54222A7@MUNPRDMBXA1.medline.com> I doubt that many residential customers will be readdressing their networks except for us geeks. Most of them are going to be using CPE that grabs an address via DHCP for the WAN interface and then does an IPv6 DHCP PD with the /64 it gets from the service provider. The customer sees nothing at all. It is plug and play. In IPv6 the concept of manual addressing is strongly discouraged so the issue of readdressing networks should be improved not made more difficult. Private address space assignments might be simple to you but grandma and my sister in law, not so much. They just plug in their gear and don't worry about addresses. In the corporate world, there is nothing stopping you from keeping your ipv4 private addressing going for a long time. In fact, I think that is what most companies will do. If you want IPv6 internally, then have at it and please use DHCP. Steven Naslund >On Mon, Mar 24, 2014 at 11:36 AM, Alexander Lopez > wrote: >not to mention the cost in readdressing your entire network when you change an upstream provider. >Nat was a fix to a problem of lack of addresses, however, the use of private address space 10/8, 192.168/16 has allowed many to enjoy a simple network addressing scheme. >Which is, of course, precisely the use case that ULA and NPTv6 (RFC 6296, not to be confused with a non-existent NAT66) addresses.... From tore at fud.no Mon Mar 24 18:56:24 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 24 Mar 2014 19:56:24 +0100 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> Message-ID: <53307FD8.3040000@fud.no> * William Herrin > On Sat, Mar 22, 2014 at 8:19 PM, Randy Bush wrote: >>> don't believe for a moment that v6 to v4 protocol translation is any less >>> ugly than CGN. >> >> it can be stateless > > You're smarter than that. https://tools.ietf.org/html/rfc6145 https://tools.ietf.org/html/draft-ietf-softwire-map-t-05 https://tools.ietf.org/html/draft-anderson-siit-dc-00 Tore From SNaslund at medline.com Mon Mar 24 18:57:34 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 24 Mar 2014 18:57:34 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54221F9@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> <9578293AE169674F9A048B2BC9A081B4B54221F9@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54222B9@MUNPRDMBXA1.medline.com> Thinking about this again, let's take Jay at his word that he can make a "passing" for $700-800. Unfortunately, the ISP or service provider does not pay for a passing, they pay for an entry. After all we can't let them make their own entry or we will have everyone and their brother in our splice case. We will also have third world aerial spaghetti as they all run their own drop cables using God knows who as "skilled labor". I will take my home here in residential Chicago as a best case example because the neighborhood is dense. All of our utilities here are aerial so there are no underground conduits available to you. I assume to keep costs down you are going to try to use what's there and go aerial. If you are in the suburbs that cable is all underground so at a minimum you will need a directional boring machine and put in the necessary pedestals and hand holes. In this county you are required to use conduit every time you go under a public street as well. I digress though, let's take the easy case. 1. You need to decide how many strands you are going to drop to my home. You could drop a single fiber or pair but then you have to put mux equipment on the end of it. After all I want choice and that might include TV from provider X, phone from provider Y, and high speed data from provider Z. 2. Since you are the sole provider of the physical layer, you now have to roll a two man crew with a bucket truck and an experienced splicer. By the way, this is Chicago so we have to have a two man crew at a minimum and they are both IBEW union contractors since this city will NEVER hire non-union labor. Figure they might have a 20-30 minute drive here is traffic cooperates. They get paid hourly so they don't much care how long it takes but let's say they are feeling frisky today and only take about two hours on the job itself plus the hour of travel. 3. Let's assume that the best case exists and the splice case is directly in my alley behind my house. Your crew needs to splice a drop cable in at the splice case (you did pay to install the splice cases right?) and run it about 100 ft to the back of my house and anchor it to my brick home at the prescribed height above ground. You can't get the bucket truck in my yard so they break out the extension ladder. In most case though the splice case will not be that close and certainly can't afford to put a case at every home at $700 per passing. So in reality that cable probably runs to the alley and several poles down the block, they have to anchor that cable at every poll so Tarzan can't use your fiber for fun. 4. Now that they have the cable at my house you have to place a MPOE (minimum point of entry) device on my house. That box probably costs a couple bucks and has to be anchored into brick. Are we getting closer to that $2,400 per home yet? What if this is the suburbs and you have to direct bury enough cable to reach the pedestal on the corner and cross my one acre lot with it? Steven Naslund Chicago IL -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Monday, March 24, 2014 12:25 PM To: NANOG Subject: Re: Level 3 blames Internet slowdowns on Technica ----- Original Message ----- >> From: "Steve Naslund" >> What do you mean by average monthly bill? That is the issue here. The >> average monthly bill includes the services you are getting. In the >> Chicago area a fiber optic access circuit unbundled from the >> imcumbent carrier to a competitive carrier is something like $10 a month or so. >> How could you possibly think you can fund a build out in a new area >> for that price? It may be possible to pay for that over 20 years. The > problem is that no one goes into business to break even over 20 years. >Well, Steve, happens we had this conversation in some detail last year when I was up for a City IT director position, and contemplating fibering >12,000 passings. >The magic number is apparently $700-800 per passing, not the $2400 you seem to suggest... From EWieling at nyigc.com Mon Mar 24 19:04:54 2014 From: EWieling at nyigc.com (Eric Wieling) Date: Mon, 24 Mar 2014 15:04:54 -0400 Subject: misunderstanding scale In-Reply-To: References: <201403241231.s2OCViii058805@aurora.sol.net> Message-ID: <616B4ECE1290D441AD56124FEBB03D0818E24FCE0F@mailserver2007.nyigc.globe> Yes, that is exactly what IPv6 expects of us. The only surprising part is by all indications the IPv6 designers did not think this would be a problem. -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Monday, March 24, 2014 1:14 PM To: Joe Greco Cc: nanog at nanog.org Subject: Re: misunderstanding scale On Mon, Mar 24, 2014 at 8:31 AM, Joe Greco wrote: >> all successful security is about _defense in depth_. >> If it is inaccessible, unrouted, unroutable and unaddressable then >> you have four layers of security. If it is merely inaccessible and >> unrouted you have two. > > Time to give up two layers of meaningless security for the riches > offered by the vastness of the new address space. Hi Joe, You'd expect folks to give up two layers of security at exactly the same time as they're absorbing a new network protocol with which they're yet unskilled? Does that make sense to you from a risk-management standpoint? -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpetach at netflight.com Mon Mar 24 19:57:21 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 24 Mar 2014 12:57:21 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> Message-ID: On Sun, Mar 23, 2014 at 6:59 PM, Naslund, Steve wrote: > [...] > The economic reality is that if I build out an expensive infrastructure I > have to pile on as many high priced services as possible to order to > maximize the revenue from it. A customer who does not balk at a $200 a > month TV/voice/Internet service is not going to be happy getting a bill of > $50 a month for a fiber loop. The services are what the customer really > wants and where you can add bells and whistle with little added expense. > The infrastructure is the expensive part. > Oh good lord, if anyone could deliver a fiber loop to my property for $50/month, I would prepay the next 20 years right now to make it happen. Heck, I'd pay 10x that for a fiber loop to the property, if I could have it cross connected to the ISP of my choice at the far end. I think you might underestimate what people would be willing to pay for competitive infrastructure access to their property. Conversely, I'd be happy to pay $5,000 in NRC installation charges to get a fiber run to the property, with a correspondingly lower MRC. Matt From mike at mtcc.com Mon Mar 24 20:18:50 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 24 Mar 2014 13:18:50 -0700 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> <53305D40.9020908@mtcc.com> Message-ID: <5330932A.3000304@mtcc.com> On 3/24/14 10:08 AM, William Herrin wrote: > On Mon, Mar 24, 2014 at 12:28 PM, Michael Thomas wrote: >> On 03/24/2014 09:20 AM, William Herrin wrote: >>> On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: >>>> Addressable is not the same as >>>> accessible; routable is not the same as routed. >>> Indeed. However, all successful security is about _defense in depth_. >>> If it is inaccessible, unrouted, unroutable and unaddressable then you >>> have four layers of security. If it is merely inaccessible and >>> unrouted you have two. >> A distinction without a difference, IMHO. Either I can send you an incoming >> SYN or I can't. > Hi Mike, > > You can either press the big red button and fire the nukes or you > can't, so what difference how many layers of security are involved > with the "Football?" > > I say this with the utmost respect, but you must understand the > principle of defense in depth in order to make competent security > decisions for your organization. Smart people disagree on the details > but the principle is not only iron clad, it applies to all forms of > security, not just IP network security. > > The point here is that your "depth" is the same with or without nat. The act of address translation does not alter its routability, it's the firewall rules that say "no incoming SYN's without an existing connection state", etc. That, and always has been, the business end of firewalls. The other thing about v6 is that counting on addressibility in any way shape or form is a fool's errand: hosts want desperately to number their interfaces with whatever GUA's they can given RA's, etc. So you may think you're only giving out ULA's, but I wouldn't count on that from a security perspective. v6 is not like DHCPv4 even a little in that respect: if the hosts can get a GUA, they will configure it and use it. Mike From greg.whynott at gmail.com Mon Mar 24 20:49:07 2014 From: greg.whynott at gmail.com (greg whynott) Date: Mon, 24 Mar 2014 16:49:07 -0400 Subject: 59.229.189.0/24 Message-ID: Hello, Up until today we have been able to reach hosts in the 59.229.189.0/24network via AS174, Cogent, in Toronto. Now we can not, our packets stop at 38.112.36.101. The support team at Cogent informed me that network isn't in the internet routing table. I attempted to do an AS lookup on it and sure enough it is not. Using looking glass routers in Korea indicate the same. Yet it is still reachable from other networks, I can use 'Team Viewer' and webx to connect to hosts at the remote office which sits within that /24. When on the remote site, i can do traceroutes back to our office in Toronto. This part is a bit confusing to me, from Toronto I get a 'no route to host'. So packets arriving from Korea to our network shouldn't be able to find a route back, even if its taking a different path. any guess why this network may not be advertising its routes or what is going on here? thanks in advance, greg This is the network route from Toronto to Korea: Host Loss% Snt Last Avg Best Wrst StDev 1. 10.101.2.1 0.0% 6 1.5 15.1 1.5 83.3 33.4 2. 10.101.111.11 0.0% 6 0.2 0.2 0.2 0.2 0.0 3. 10.101.101.101 0.0% 6 0.7 0.8 0.7 0.8 0.0 4. 38.122.184.161 0.0% 6 <-- ISP ROUTER 5. 38.20.50.130 0.0% 6 1.9 2.0 1.9 2.1 0.0 6. 38.112.36.101 89.0% 5 1.6 1.7 1.6 1.7 0.0 This is the route from Korea to Toronto, done at the same time as the above. 1 <1 ms <1 ms <1 ms 192.168.0.1 2 1 ms <1 ms <1 ms 58.229.189.1 3 1 ms 1 ms 1 ms 10.254.241.205 4 1 ms 1 ms 1 ms 58.229.66.9 5 2 ms 1 ms 1 ms 58.229.66.105 6 7 ms 5 ms 3 ms 58.229.119.149 7 2 ms 2 ms 2 ms 118.221.7.34 8 144 ms 144 ms 144 ms 58.229.92.254 9 276 ms 208 ms 192 ms te-8-2.car1.SanJose2.Level3.net [4.59.0.161] 10 204 ms 162 ms 162 ms ae-2-70.edge1.SanJose3.Level3.net[4.69.152.80] 11 165 ms 165 ms 165 ms Cogent-level3-4x10G.SanJose.Level3.net[4.68.110.138] 12 156 ms 156 ms 156 ms be2000.ccr21.sjc01.atlas.cogentco.com[154.54.6.105] 13 166 ms 165 ms 165 ms be2164.ccr21.sfo01.atlas.cogentco.com[154.54.28.33] 14 187 ms 187 ms 187 ms be2256.mpd21.mci01.atlas.cogentco.com[154.54.6.90] 15 206 ms 206 ms 206 ms be2158.mpd21.ord01.atlas.cogentco.com[154.54.7.130] 16 216 ms 216 ms 216 ms be2081.ccr21.yyz02.atlas.cogentco.com[154.54.42.10] 17 221 ms 221 ms 221 ms te3-8.ccr02.yyz01.atlas.cogentco.com[154.54.5.85] 18 231 ms 230 ms 230 ms te4-1.mag03.yyz01.atlas.cogentco.com[154.54.86.82] 19 214 ms 215 ms 214 ms 38.122.184.162 <-- OUR ROUTER From morrowc.lists at gmail.com Mon Mar 24 20:53:44 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Mar 2014 16:53:44 -0400 Subject: 59.229.189.0/24 In-Reply-To: References: Message-ID: On Mon, Mar 24, 2014 at 4:49 PM, greg whynott wrote: > 59.229.189.0 $ whois -h whois.cymru.com 59.229.189.0 AS | IP | AS Name NA | 59.229.189.0 | NA cymru seems to think there's no route for that network. my network agrees. From jeroen at massar.ch Mon Mar 24 21:08:42 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 24 Mar 2014 14:08:42 -0700 Subject: 59.229.189.0/24 In-Reply-To: References: Message-ID: <53309EDA.8040709@massar.ch> On 2014-03-24 13:49, greg whynott wrote: [..] > 4 1 ms 1 ms 1 ms 58.229.66.9 > 5 2 ms 1 ms 1 ms 58.229.66.105 > 6 7 ms 5 ms 3 ms 58.229.119.149 Seems you mean 58 instead of 59. Greets, Jeroen From fergdawgster at mykolab.com Mon Mar 24 21:13:57 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 24 Mar 2014 14:13:57 -0700 Subject: 59.229.189.0/24 In-Reply-To: References: Message-ID: <5330A015.3050102@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/24/2014 1:53 PM, Christopher Morrow wrote: > On Mon, Mar 24, 2014 at 4:49 PM, greg whynott > wrote: >> 59.229.189.0 > > $ whois -h whois.cymru.com 59.229.189.0 AS | IP > | AS Name NA | 59.229.189.0 | NA > > cymru seems to think there's no route for that network. my network > agrees. > > > ********************************************************************** Oregon Exchange BGP Route Viewer route-views.oregon-ix.net / route-views.routeviews.org route views data is archived on http://archive.routeviews.org This hardware is part of a grant from Cisco Systems. Please contact help at routeviews.org if you have questions or comments about this service, its use, or if you might be able to contribute your view. This router has views of the full routing tables from several ASes. The list of ASes is documented under "Current Participants" on http://www.routeviews.org/. ************** route-views.routeviews.org is now using AAA for logins. Login with username "rviews". See http://routeviews.org/aaa.html ********************************************************************** route-views>sho ip bgp 59.229.189.0 % Network not in table route-views> - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMwoBIACgkQKJasdVTchbLZkQD/Xb6RRs2bMkl5te8Ga6OrSW6B Z2KSJyeZ+LMUEnw8BVEA/R9jI6cswaLTx+wGUX7zCTCZNzKuyIn+zykP6jVXNxEy =JPAp -----END PGP SIGNATURE----- From scott at doc.net.au Mon Mar 24 21:17:51 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 24 Mar 2014 14:17:51 -0700 Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: https://www.digitalocean.com/community/questions/when-ipv6-will-be-fully-supportedwhich then links to http://digitalocean.uservoice.com/forums/136585-digital-ocean/suggestions/2639897-ipv6-addressessays it all, really... Scott On Sat, Mar 22, 2014 at 12:07 AM, Bryan Socha wrote: > As someone growing in the end of ipv4, its all fake. Sure, the rirs will > run out, but that's boring. Don't believe the fake auction sites. > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no > spam and $4 for legacy. Stop the inflation. Millions of IPS exist, > there is no shortage and don't lie for rirs with IPS left. > From fergdawgster at mykolab.com Mon Mar 24 21:26:53 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 24 Mar 2014 14:26:53 -0700 Subject: 59.229.189.0/24 In-Reply-To: <5330A015.3050102@mykolab.com> References: <5330A015.3050102@mykolab.com> Message-ID: <5330A31D.8000707@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/24/2014 2:13 PM, Paul Ferguson wrote: > On 3/24/2014 1:53 PM, Christopher Morrow wrote: > >> On Mon, Mar 24, 2014 at 4:49 PM, greg whynott >> wrote: >>> 59.229.189.0 > >> $ whois -h whois.cymru.com 59.229.189.0 AS | IP | AS Name NA >> | 59.229.189.0 | NA > >> cymru seems to think there's no route for that network. my >> network agrees. > > > > > > ********************************************************************** > > Oregon Exchange BGP Route Viewer route-views.oregon-ix.net / > route-views.routeviews.org > > route views data is archived on http://archive.routeviews.org > > This hardware is part of a grant from Cisco Systems. Please contact > help at routeviews.org if you have questions or comments about this > service, its use, or if you might be able to contribute your view. > > This router has views of the full routing tables from several > ASes. The list of ASes is documented under "Current Participants" > on http://www.routeviews.org/. > > ************** > > route-views.routeviews.org is now using AAA for logins. Login > with username "rviews". See http://routeviews.org/aaa.html > > ********************************************************************** > > > > > > route-views>sho ip bgp 59.229.189.0 % Network not in table > route-views> > Derp. Hello, this is Quagga (version 0.99.21). Copyright 1996-2005 Kunihiro Ishiguro, et al. route-views2.routeviews.org> sho ip bgp 59.229.189.0/24 % Network not in table route-views2.routeviews.org> route-views2.routeviews.org> - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMwox0ACgkQKJasdVTchbJgbAEAhCCMIaiacSobZY78gdh0PGHw V33PZIZCqOsyNll3BhIA/3tdScGQaKAsW6TTzWz1X2xgrTuBMXJuUgSxxLATS/Zl =RH8X -----END PGP SIGNATURE----- From greg.whynott at gmail.com Mon Mar 24 21:40:34 2014 From: greg.whynott at gmail.com (greg whynott) Date: Mon, 24 Mar 2014 17:40:34 -0400 Subject: 59.229.189.0/24 In-Reply-To: <5330A31D.8000707@mykolab.com> References: <5330A015.3050102@mykolab.com> <5330A31D.8000707@mykolab.com> Message-ID: oh my.... how embarrassing is that... 15 years doing networking too... It was a typo this whole time as indicated by Jeroen and I didn't even catch it.. will 'its monday' work as an excuse? ;) 58 instead of 59. I was pulling my hair on this one, the network drawing I was referencing has the wrong IP and its been like that for months. I sent support those trace routes and they didn't even catch that. I mention this only to make myself feel a weee bit better.. so sorry for wasting your time but thanks very much for it everyone. -g On Mon, Mar 24, 2014 at 5:26 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 3/24/2014 2:13 PM, Paul Ferguson wrote: > > > On 3/24/2014 1:53 PM, Christopher Morrow wrote: > > > >> On Mon, Mar 24, 2014 at 4:49 PM, greg whynott > >> wrote: > >>> 59.229.189.0 > > > >> $ whois -h whois.cymru.com 59.229.189.0 AS | IP | AS Name NA > >> | 59.229.189.0 | NA > > > >> cymru seems to think there's no route for that network. my > >> network agrees. > > > > > > > > > > > > ********************************************************************** > > > > Oregon Exchange BGP Route Viewer route-views.oregon-ix.net / > > route-views.routeviews.org > > > > route views data is archived on http://archive.routeviews.org > > > > This hardware is part of a grant from Cisco Systems. Please contact > > help at routeviews.org if you have questions or comments about this > > service, its use, or if you might be able to contribute your view. > > > > This router has views of the full routing tables from several > > ASes. The list of ASes is documented under "Current Participants" > > on http://www.routeviews.org/. > > > > ************** > > > > route-views.routeviews.org is now using AAA for logins. Login > > with username "rviews". See http://routeviews.org/aaa.html > > > > ********************************************************************** > > > > > > > > > > > > route-views>sho ip bgp 59.229.189.0 % Network not in table > > route-views> > > > > Derp. > > > Hello, this is Quagga (version 0.99.21). > Copyright 1996-2005 Kunihiro Ishiguro, et al. > > route-views2.routeviews.org> sho ip bgp 59.229.189.0/24 > % Network not in table > route-views2.routeviews.org> > route-views2.routeviews.org> > > - - ferg > > > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlMwox0ACgkQKJasdVTchbJgbAEAhCCMIaiacSobZY78gdh0PGHw > V33PZIZCqOsyNll3BhIA/3tdScGQaKAsW6TTzWz1X2xgrTuBMXJuUgSxxLATS/Zl > =RH8X > -----END PGP SIGNATURE----- > > From jcurran at arin.net Mon Mar 24 21:47:11 2014 From: jcurran at arin.net (John Curran) Date: Mon, 24 Mar 2014 21:47:11 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Randy - Total number of /24s of space directly registered in ARIN's database = 6,644,175 (101.38 /8 equivalents) Of those: 2,808,621 /24s of space (42.3%) are registered to ARIN members (42.86 /8 equivalents) Total number of Org IDs with directly registered IPv4 addresses = 26,148 Of those: 4,520 (17%) are ARIN members FYI, /John John Curran President and CEO ARIN From randy at psg.com Mon Mar 24 21:47:54 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 06:47:54 +0900 Subject: misunderstanding scale In-Reply-To: <53307FD8.3040000@fud.no> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: > https://tools.ietf.org/html/rfc6145 > https://tools.ietf.org/html/draft-ietf-softwire-map-t-05 > https://tools.ietf.org/html/draft-anderson-siit-dc-00 derived from 6346 randy From mike at mtcc.com Mon Mar 24 21:57:44 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 24 Mar 2014 14:57:44 -0700 Subject: misunderstanding scale In-Reply-To: <8555.1395682661@turing-police.cc.vt.edu> References: <201403241231.s2OCViii058805@aurora.sol.net> <8555.1395682661@turing-police.cc.vt.edu> Message-ID: <5330AA58.3090602@mtcc.com> On 3/24/14 10:37 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 24 Mar 2014 13:13:43 -0400, William Herrin said: > >> You'd expect folks to give up two layers of security at exactly the >> same time as they're absorbing a new network protocol with which >> they're yet unskilled? Does that make sense to you from a >> risk-management standpoint? > The problem is that the two layers of "security" that they're "giving up" > are made from the same fabric as the Emperor's new clothes.... Made of neutrinos for which nobody is exactly sure have mass. Mike From bill at herrin.us Mon Mar 24 22:42:56 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 18:42:56 -0400 Subject: misunderstanding scale In-Reply-To: <53307FD8.3040000@fud.no> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: On Mon, Mar 24, 2014 at 2:56 PM, Tore Anderson wrote: > * William Herrin >> On Sat, Mar 22, 2014 at 8:19 PM, Randy Bush wrote: >>>> don't believe for a moment that v6 to v4 protocol translation is any less >>>> ugly than CGN. >>> >>> it can be stateless >> >> You're smarter than that. > > https://tools.ietf.org/html/rfc6145 > https://tools.ietf.org/html/draft-ietf-softwire-map-t-05 > https://tools.ietf.org/html/draft-anderson-siit-dc-00 And all those IPv4 addresses for the 1:1 translation required by the stateless version are coming from where exactly? And then only for the v6 hosts you've configured in the v6 address range for which v4 translation is allowed (no SLAAC!). Like I told Randy: you're smarter than that. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Mon Mar 24 22:46:36 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 07:46:36 +0900 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: > And all those IPv4 addresses for the 1:1 translation required by the > stateless version are coming from where exactly? maybe you should read the documents From randy at psg.com Mon Mar 24 23:07:50 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 08:07:50 +0900 Subject: ms word Message-ID: this would be a good time to tll your users not to send or open ms word documents. active 0day http://arstechnica.com/security/2014/03/zero-day-vulnerability-in-microsoft-word-under-active-attack/ randy From bill at herrin.us Mon Mar 24 23:11:49 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 19:11:49 -0400 Subject: misunderstanding scale In-Reply-To: <8555.1395682661@turing-police.cc.vt.edu> References: <201403241231.s2OCViii058805@aurora.sol.net> <8555.1395682661@turing-police.cc.vt.edu> Message-ID: On Mon, Mar 24, 2014 at 1:37 PM, wrote: > On Mon, 24 Mar 2014 13:13:43 -0400, William Herrin said: >> You'd expect folks to give up two layers of security at exactly the >> same time as they're absorbing a new network protocol with which >> they're yet unskilled? Does that make sense to you from a >> risk-management standpoint? > > The problem is that the two layers of "security" that they're "giving up" > are made from the same fabric as the Emperor's new clothes.... Howdy, In an environment of increasing breaches despite massive attention and expenditure on cyber security, you'll find that giving up any layer of security is a very hard sell. You'll find convincing folks to deploy new technologies which demand that they give up a layer of security an even harder sell. And of course everybody likes to be told that they're an idiot by someone whose explanation of the error in their reasoning consists of restating the claim of error in the form of a metaphor. But don't let me dissuade you from trying. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Mon Mar 24 23:23:27 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Mar 2014 19:23:27 -0400 (EDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54222B9@MUNPRDMBXA1.medline.com> Message-ID: <19655220.12521.1395703407850.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Steve Naslund" > Thinking about this again, let's take Jay at his word that he can make > a "passing" for $700-800. Let's not. I was quoting vendors who had themselves been quoted by other NANOGers. Whether those other NANOGers had *paid* that price is unclear, but the price was assuming a bulk greenfield install. Whether it included TAs I don't remember, and would have to look at the archives. > Unfortunately, the ISP or service provider > does not pay for a passing, they pay for an entry. After all we can't > let them make their own entry or we will have everyone and their > brother in our splice case. They will terminate their equipment in my building, and I will feed them cross-connects. > We will also have third world aerial > spaghetti as they all run their own drop cables using God knows who as > "skilled labor". No, cause the fiber that's in the ground is all that's ever going there, since it was installed by the city. You're running with my number, you need to run with *all* the context which accompanied it, none of which you inquired about. > 1. You need to decide how many strands you are going to drop to my > home. You could drop a single fiber or pair but then you have to put > mux equipment on the end of it. After all I want choice and that might > include TV from provider X, phone from provider Y, and high speed data > from provider Z. I was going to install 3-pair per passing, except in multi-unit res and business, where the ratio would drop off to about 1.2 or so at 500 units. > 2. Since you are the sole provider of the physical layer, you now have > to roll a two man crew with a bucket truck and an experienced splicer. I do like hell; I have Mongo walk over into the wire room and feed a patch cord. Everything is already wired. > By the way, this is Chicago so we have to have a two man crew at a > minimum and they are both IBEW union contractors since this city will > NEVER hire non-union labor. Figure they might have a 20-30 minute > drive here is traffic cooperates. They get paid hourly so they don't > much care how long it takes but let's say they are feeling frisky > today and only take about two hours on the job itself plus the hour of > travel. It's clear that you're making the assumptions for *your* environment, so I won't leave any more of these in now that I've made my point. > Are we getting closer to that $2,400 per home yet? What if this is the > suburbs and you have to direct bury enough cable to reach the pedestal > on the corner and cross my one acre lot with it? Probably, but $2400 got nothing to do with *my* environment. 100% passings, 100% MPOE, on a pedestal for empty lots, of which there aren't many. Helps to be aiming at the target before you pull the trigger, Steve. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bill at herrin.us Mon Mar 24 23:27:53 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 19:27:53 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: On Mon, Mar 24, 2014 at 6:46 PM, Randy Bush wrote: >> And all those IPv4 addresses for the 1:1 translation required by the >> stateless version are coming from where exactly? > > maybe you should read the documents I did. They were abstruse beyond even the normal level for RFCs but I made it through. You propose stateless NAT64 as an viable alternative to CGN. The question stands: where are you planning to get the extra IPv4 addresses for the static 1:1 mapping? -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Mon Mar 24 23:37:38 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 08:37:38 +0900 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: > You propose stateless NAT64 as an viable alternative to CGN. where do i do that? > The question stands: where are you planning to get the extra IPv4 > addresses for the static 1:1 mapping? maybe look at the +P in A+P randy From bill at herrin.us Mon Mar 24 23:47:46 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 19:47:46 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: On Mon, Mar 24, 2014 at 7:37 PM, Randy Bush wrote: >> You propose stateless NAT64 as an viable alternative to CGN. > > where do i do that? Nick Hilliard: "don't believe for a moment that v6 to v4 protocol translation is any less ugly than CGN." Your reply (verbosity added for clarity): "[Sure it is! Unlike where folks solve their problem with CGN, v6 to v4 protocol translation] can be stateless." >> The question stands: where are you planning to get the extra IPv4 >> addresses for the static 1:1 mapping? > > maybe look at the +P in A+P Nah, I'm done following bread crumbs for the day. Explain yourself or don't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Mon Mar 24 23:53:23 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 08:53:23 +0900 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: >>> You propose stateless NAT64 as an viable alternative to CGN. ^^^ >> where do i do that? > Nick Hilliard ahh. i see your error. i am not nick hilliard. he's the cute one. > Your reply (verbosity added for clarity): "[Sure it is! Unlike where > folks solve their problem with CGN, v6 to v4 protocol translation] can > be stateless." again, you put words in my mouth which were not there. i did not say v6 to v4 translation. > Nah, I'm done following bread crumbs for the day. cool. then we can all go back to reality and whet people actually said. bye randy From owen at delong.com Mon Mar 24 23:54:53 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 16:54:53 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> References: <532BBFEA.70509@cox.net> <532CED53.6080709@cox.net> <616B4ECE1290D441AD56124FEBB03D0818E24FCD02@mailserver2007.nyigc.globe> Message-ID: <14383CB0-C67C-4463-83D8-038AA92F22F1@delong.com> A natural monopoly exists without force of arms or regulation very easily. Any place where the market density is insufficient to support the cost of multiple providers building out the infrastructure for a given service, a natural monopoly exists. For example, if cities were to simply open up the provision of sewer services* to residential areas, you wouldn?t have a bunch of companies choosing to suddenly get into the sewer business. Instead, whoever has pipes already in the ground will continue to serve customers and no competitor is going to see enough market upside to build a second set of pipes out or build a pipe network on an ad-hoc basis. So it also goes with other similar types of services, such as copper pairs (telephony/DSL), co-ax (Cable), Fiber (GPON, Active Ethernet, Etc). Companies have created the illusion of competition by convincing regulators that cellular competes with cable competes with copper pair, but in reality, the service profiles of those media are so radically different that in most areas, any perceived competition is mostly imaginary. ($99 for 50Mbps/10Mbps co-ax does not, IMHO, compete with $50 for 1.5Mbps/384Kbps DSL, for example) Very few, if any neighborhoods have copper pairs from more than one phone company. You can argue that there are regulations preventing a second phone company from deploying, but in reality, even if such regulations were removed, there wouldn?t be a second phone company laying copper in most areas. In many areas, the regulation is the result of the USF process attempting to get at least one phone company to do a subsidized build-out into the area because subscriber density was so low that it didn?t even support a natural monopoly, let alone competitive environment. Even if the incumbents gave up their ?right-of-way?, you wouldn?t see enough of a market in any but the most densely populated areas to support establishment of a competitor and you likely wouldn?t even see initial build-out into most locations. Instead, the part that needs to be heavily regulated, the natural monopoly, the last-mile local loop should be provided by an independent operator who does not have a conflict of interest with regards to serving all of the providers trying to provide higher layer services. An owner of the physical infrastructure that is allowed to use that physical infrastructure in anti-competitive ways against other higher-layer service providers will do so to the detriment of the customers. Prohibiting them from owning the last-mile physical infrastructure and, instead, requiring that to be managed by an independent system operator who provides equal footing to all comers just makes sense. Owen *By sewer services in this context, I mean the actual sewers themselves and the waste-removal service that they provide, not services such as roto-rooter/rescue-rooter/etc. On Mar 21, 2014, at 8:45 PM, Eric Wieling wrote: > > Make the regulation and force of arms be as targeted as reasonable. In the case of telecommunications as targeted as reasonable means the "last mile" or, more correctly, the "local loop". I advocate stringent ongoing oversight and regulation of the local loop and very little regulation for the rest of the communications industry. > > If the incumbent telcos want to compete on equal footing in a free market then I invite them to give up their government granted right of ways to run their copper or fiber and compete on a level playing field. They will never do that and therefore the last mile can never be a free market. > > > -----Original Message----- > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > Sent: Friday, March 21, 2014 9:54 PM > To: nanog at nanog.org > Subject: Re: Level 3 blames Internet slowdowns on Technica > > *too old, failing memory and all, I'll have to go read up on "natural monopoly"--I can not think of one that does not require regulation and force of arms to exist. > From wbailey at satelliteintelligencegroup.com Tue Mar 25 00:05:12 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 25 Mar 2014 00:05:12 +0000 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: FYI He tells everyone they?re cute. Don?t buy his tricks, he doesn?t call back the next morning. ;) Ps. Take it easy on each other. It?s the beginning of spring.. Head outside.. Go have a beer.. Smoke a joint.. What I am getting at is.. It?s possible you guys should relax and realize that in the grand scheme of things a lot of this really doesn?t matter. Go be humans beings in the world, the internet and this flame thread will still be here as it has been for generations (internet generations, anyways..) Just my .02 WOOOOOSAHHHHHHHHHHHHHHHH On 3/24/14, 4:53 PM, "Randy Bush" wrote: >>>> You propose stateless NAT64 as an viable alternative to CGN. > ^^^ >>> where do i do that? >> Nick Hilliard > >ahh. i see your error. i am not nick hilliard. he's the cute one. > >> Your reply (verbosity added for clarity): "[Sure it is! Unlike where >> folks solve their problem with CGN, v6 to v4 protocol translation] can >> be stateless." > >again, you put words in my mouth which were not there. i did not say v6 >to v4 translation. > >> Nah, I'm done following bread crumbs for the day. > >cool. then we can all go back to reality and whet people actually said. > >bye > >randy > > > From owen at delong.com Tue Mar 25 00:07:13 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:07:13 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> In order for IPv6 to truly work, everyone needs to be moving towards IPv6. Maintaining dual protocols for the entire internet is problematic, wasteful, and horribly inefficient at best. Bottom line, the internet outgrew IPv4 almost 30 years ago and we?ve been using various hacks like NAT as a sort of IPv4 life-support ever since. Ask any doctor about the prospects for a patient on life support for years at a time and they will probably laugh at you. Patients rarely survive more than a few days on life support, let alone weeks, months, or even years. Yes, we?ve done really well with internet life support. So well that many have been lulled into a false sense of safety believing that these extreme measures can be continued indefinitely and scaled well beyond their breaking points. There is little visibility into the escalating cost and complexity of these measures and even less awareness of the relative ease of deploying IPv6 compared to most of these mechanisms. Owen On Mar 22, 2014, at 2:25 AM, Bryan Socha wrote: > Fair point. There are some situations that do need more than most, but > aren't they the ones that should be on ipv6 already??????? > > I know a few are shouldn't I be on ipv6 and that's fair too. I'm > plqnnning some speaking engagements to cover that. Its not blind and > ignoring. > On Mar 22, 2014 4:36 AM, "TJ" wrote: > >> Millions of IPs don't matter in the face of X billions of people, and >> XX-XXX billions of devices - and this is just the near term estimate. >> (And don't forget utilization efficiency - Millions of IPs is not >> millions of customers served.) >> >> Do IPv6. >> /TJ >> >> On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: >>> >>> As someone growing in the end of ipv4, its all fake. Sure, the rirs >> will >>> run out, but that's boring. Don't believe the fake auction sites. >>> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for >> no >>> spam and $4 for legacy. Stop the inflation. Millions of IPS exist, >>> there is no shortage and don't lie for rirs with IPS left. >> From owen at delong.com Tue Mar 25 00:10:45 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:10:45 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: Let?s assume, for a moment, that there are 32 /8s out there that could be reclaimed. Let?s further assume that renumbering out of a /8 takes, on average, about 18 months. (That?s moving almost 1,000,000 customers per month on average, potentially). Even if we got all 32 /8 equivalents back over the next 18 months, it would only buy us approximately 2 years of additional IPv4 life-span when divvied up among APNIC, RIPE, etc. The IPv4 situation is not artificial. IPv4 is being maintained well past its useful life at great cost. Owen On Mar 22, 2014, at 2:30 AM, Bryan Socha wrote: > Oh btw, how many ipv4s are you hording with zero justification to keep > them? I was unpopular during apricot for not liking the idea of no > liability leasing of v4. I don't like this artificial v4 situation > every eyeball network created. Why is v4 a commodity and asset? Where > is the audits. I can justify my 6 /14s, can you still? > On Mar 22, 2014 4:36 AM, "TJ" wrote: > >> Millions of IPs don't matter in the face of X billions of people, and >> XX-XXX billions of devices - and this is just the near term estimate. >> (And don't forget utilization efficiency - Millions of IPs is not >> millions of customers served.) >> >> Do IPv6. >> /TJ >> >> On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: >>> >>> As someone growing in the end of ipv4, its all fake. Sure, the rirs >> will >>> run out, but that's boring. Don't believe the fake auction sites. >>> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for >> no >>> spam and $4 for legacy. Stop the inflation. Millions of IPS exist, >>> there is no shortage and don't lie for rirs with IPS left. >> From owen at delong.com Tue Mar 25 00:26:56 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:26:56 -0700 Subject: misunderstanding scale In-Reply-To: <532DC580.8060901@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> Message-ID: <176B4BDC-7B2E-472A-80CF-AC04FC885965@delong.com> On Mar 22, 2014, at 10:16 AM, Nick Hilliard wrote: > On 22/03/2014 16:29, Doug Barton wrote: >> It is a mistake to believe that the only reason to add IPv6 to your network >> is size. Adding IPv6 to your network _now_ is the right decision because at >> some point in the not-too-distant future it will be the dominant network >> technology, and you don't want to get left behind. > > not wanting to rain on anyone's parade, but people have been claiming this > since the days of IPng. Granted, we're a couple of years after IANA runout > and two RIRs are also in post-runout phase, but the level of pain > associated with continued deployment of ipv4-only services is still nowhere > near the point that ipv6 can be considered a viable alternative. > > Nick > True. However, if you wait until that point to start deploying IPv6, you?re in for a LOT of pain during that protracted emergency transition phase you just volunteered for. OTOH, if you implement IPv6 in parallel to your IPv4 from this point forward, there?s very little additional pain and retrofitting your IPv4 can proceed at some pace until complete. After that, you can turn off IPv4 as soon as you don?t need it any more and enjoy the show while everyone else plays catchup. Owen From hslabbert at stargate.ca Mon Mar 24 17:36:46 2014 From: hslabbert at stargate.ca (hslabbert at stargate.ca) Date: Mon, 24 Mar 2014 10:36:46 -0700 Subject: misunderstanding scale In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54220DA@MUNPRDMBXA1.medline.com> References: <20140323051037.94159.qmail@joyce.lan> <201403240838.27974.mark.tinka@seacom.mu> <201403241835.19186.mark.tinka@seacom.mu> <9578293AE169674F9A048B2BC9A081B4B54220DA@MUNPRDMBXA1.medline.com> Message-ID: <20140324173646.GB14377@stargate.ca> On 2014-03-24, "Naslund, Steve" wrote: >If they have a stateful IPv6 firewall (which they should and which most firewall vendors support), they already have what they need to prevent their internal systems from being accessible from the outside. If you are an enterprise and you don't have a stateful firewall, you are in trouble from a security standpoint whether you run v4 or v6. If you cannot configure a stateful firewall to block connections being initiated from outside, you are not qualified to be working with the firewall, v4 or v6 does not matter. If someone is relying on NAT in case their firewall is misconfigured, they have major issues with security. > >In the home, I am not sure what the major issue is there either. How many CPE devices have you seen that do not implement basic firewall functionality? People may not use them correctly but that is no more an issue with v6 than it is with v4. Most CPE even comes out of the box blocking inbound connections by default. Tell that to our little D-Link AP/router with stateless filters only for v6, and broken config options that make it impossible to apply even that to a tunnel interface (HE). I agree with you on pushing v6 adoption and that the at the root of it you should have a stateful firewall be it v4 or v6, but: - if this thread is any indication and as per your first paragraph, way too many orgs are depending on NAT as a security feature and v6 is exposing that weakness in their posture - home CPE implementations are largely crap, and good luck getting a decent portion of them supporting (functional) stateful v6 firewalls > >Steve > -- Hugo > >-----Original Message----- >From: Mark Tinka [mailto:mark.tinka at seacom.mu] >Sent: Monday, March 24, 2014 11:35 AM >To: Timothy Morizot >Cc: NANOG list >Subject: Re: misunderstanding scale > > >>>Don't disagree with you there. > >>>I'm saying many an enterprise (small and large) as well as homes operate this way. There is a lot of unlearning to do. > >>>The whole issue is that a number of enterprises "may" only feel safe if IPv6 comes with NAT66, probably on top (or not on top) of a stateful IPv6 firewall. > >>>We need to think about how to re-train the enterprise, if we don't want to repeat the erasure of the end-to-end model, second time around. > >>>Mark. > -- Hugo Slabbert Network Specialist Phone: 604.606.4448 Email: hslabbert at stargate.ca Stargate Connections Inc. http://www.stargate.ca -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From owen at delong.com Tue Mar 25 00:31:09 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:31:09 -0700 Subject: Ipv4 end, its fake. In-Reply-To: References: Message-ID: <14D56DE0-1429-4F1E-B35F-8527AAE92492@delong.com> On Mar 22, 2014, at 7:40 AM, Justin M. Streiner wrote: > On Sat, 22 Mar 2014, Cb B wrote: > >> You can pay $3 per ipv4, that is your business. But, it may be worth noting >> that AT&T, Verizon, Comcast, T-Mobile, TWT, Google Fiber all have have >> double digit ipv6 penetration today. > > To be fair: > Verizon Wireless, if you're referring to 4G LTE? Agreed. > I don't know what the plan is for the remaining 3G services. I get IPv6 on both 3G and 4GLTE from VZW. > Verizon Enterprise (what used to be UUNET)? Agreed. > Verizon Online (Fios, DSL)? I have to disagree. Lots of foot-dragging here. Similar with AT&T Wireless. If you want to have some fun, open up a ticket with your carrier if you can?t reach http://thegoodlife.delong.com It has an AAAA record, but no A record. In my experience, most carriers will not even figure out the nature of the problem. > Most carriers appear to be making IPv6 capability a requirement for their LTE buildouts. The only major US carrier that I hears was resisting IPv6 was Sprint, and I don't know if their position has changed in the past 12 months. To the best of my knowledge it has not. However, I think a big part of that is that sprint thought they could spell 4GLTE using the letters W-I-M-A-X. Owen From owen at delong.com Tue Mar 25 00:42:23 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:42:23 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140322195704.15285.qmail@joyce.lan> References: <20140322195704.15285.qmail@joyce.lan> Message-ID: IPv4 has already been trading around $10/address. So the prices quoted a while back don?t make much sense to me. Further, could you please quantify ?vast?? How many /8 equivalents in a ?vast number?? Until they ran out, APNIC was issuing approximately 1.5 /8s per month. How long, exactly, do you expect 3.2 billion unicast addresses to provide enough addressing for 6.8+ billion people? Owen On Mar 22, 2014, at 12:57 PM, John Levine wrote: >> In such a case, where you are still pushing the case for >> IPv4, how do you envisage things will look on your side when >> everybody else you want to talk to is either on IPv6, or >> frantically getting it turned up? Do you reckon anyone will >> have time to help you troubleshoot patchy (for example) IPv4 >> connectivity when all the focus is on IPv6? > > I've put that concern on my calendar for sometime around 2025. > > People have been saying switch to IPv6 now Now NOW for about a decade, > and you can only cry wolf so many times. My servers do IPv6 through a > tunnel from HE (thanks!) where the performance is only somewhat worse > than the native v4, and my home cable has v6 that mostly works, but > the key term there is mostly. (The ISP had a fairly bad internal > routing bug which apparently nobody noticed until I tracked down why > my v6 connectivity was flaky, and I happened to know some senior > people at the ISP who could understand what I was telling them about > their internal routers.) > > We've just barely started to move from the era of free IPv4 to the one > where you have to buy it, and from everyhing I see, there is vast > amounts of space that will be available once people realize they can > get real money for it. The prices cited a couple of messages back > seem to be in the ballpark. It will be a long time before the price > of v4 rises high enough to make it worth the risk of going v6 only. > > R's, > John > > From owen at delong.com Tue Mar 25 00:39:09 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:39:09 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: Message-ID: <1DB8B281-9904-4E30-A9CE-9099016E1493@delong.com> On Mar 22, 2014, at 12:36 PM, William Herrin wrote: > On Sat, Mar 22, 2014 at 11:54 AM, Justin M. Streiner > wrote: >> On Sat, 22 Mar 2014, William Herrin wrote: >>> On Sat, Mar 22, 2014 at 10:33 AM, Justin M. Streiner >>> wrote: >>>> >>>> All of these 'Hail Mary' options for 'saving' IPv4 really are pointless. >>> >>> >>> IPv4 is like the U.S. Penny. It'll be useless long before it goes >>> away. And right now it's far from useless. >> >> Interesting analogy, but it misses the larger point. The larger point is >> that the ongoing effort to squeeze more mileage out of IPv4 will soon [1] >> outweigh the mileage we (collectively) get out of it. > > Hi Justin, > > That's what I hear. Interesting thing though: it hasn't happened yet. > IANA ran out of /8's and it didn't happen. The RIRs dropped to > high-conservation mode on their final allocations and it didn't > happen. How could that be? I disagree with your assertion that it hasn?t happened. It _IS_ happening. The cost of maintaining IPv4 is already going up and the increases will continue to become more dramatic over time. Owen From johnl at iecc.com Tue Mar 25 00:47:25 2014 From: johnl at iecc.com (John R. Levine) Date: 24 Mar 2014 20:47:25 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: <20140322195704.15285.qmail@joyce.lan> Message-ID: > How long, exactly, do you expect 3.2 billion unicast addresses to provide > enough addressing for 6.8+ billion people? Oh, I'd say a decade. Like I said, I have IPv6 on my server and my home broadband, which mostly works, with the emphasis on the mostly. >> We've just barely started to move from the era of free IPv4 to the one >> where you have to buy it, and from everyhing I see, there is vast >> amounts of space that will be available once people realize they can >> get real money for it. The prices cited a couple of messages back >> seem to be in the ballpark. It will be a long time before the price >> of v4 rises high enough to make it worth the risk of going v6 only. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From owen at delong.com Tue Mar 25 00:47:28 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:47:28 -0700 Subject: misunderstanding scale In-Reply-To: <532E1384.1010209@foobar.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> Message-ID: On Mar 22, 2014, at 3:49 PM, Nick Hilliard wrote: > On 22/03/2014 19:35, Justin M. Streiner wrote: >> CGN also comes with lots of downside that customers are likely to find >> unpleasant. For some operators, customer (dis)satisfaction might be the >> driver that ultimately forces them to deploy IPv6. > > don't believe for a moment that v6 to v4 protocol translation is any less > ugly than CGN. > > Nick > Well, IMHO, it?s slightly less ugly. CGN will usually be a second layer of NAT imposed on an already NAT?d connection. At least with NAT64, you?re usually dealing with a single layer of translation. Owen From bill at herrin.us Tue Mar 25 00:52:52 2014 From: bill at herrin.us (William Herrin) Date: Mon, 24 Mar 2014 20:52:52 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532DDB79.50808@fud.no> <532DFB1F.7010805@foobar.org> <532E1384.1010209@foobar.org> <53307FD8.3040000@fud.no> Message-ID: On Mon, Mar 24, 2014 at 8:05 PM, Warren Bailey wrote: > FYI He tells everyone they?re cute. Don?t buy his tricks, he doesn?t call > back the next morning. > > Ps. Take it easy on each other. It?s the beginning of spring.. Head > outside.. Spring!? Snow is in tonight's forecast here in Virginia. Ah well. Ultima Online beckons. It's always spring in Sosaria. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Mar 25 00:54:18 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:54:18 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <20140323051037.94159.qmail@joyce.lan> References: <20140323051037.94159.qmail@joyce.lan> Message-ID: <304A1014-D8F8-4403-B832-50A7AFFC8161@delong.com> On Mar 22, 2014, at 10:10 PM, John Levine wrote: >>> It will be a long time >>> before the price of v4 rises high enough to make it >>> worth the risk of going v6 only. >> >> New ISP's are born everyday. >> >> Some of them will be able to have a "Buy an ISP that has >> IPv4" or "Buy IPv4 space from known brokers" line item in >> their budget as part of their launch plans. >> >> Most won't. > > In Africa, I suppose, but here in North America, the few remaining > ISPs that aren't part of giant cable or phone companies are hanging on > by their teeth. > > Also, although it is fashionable to say how awful CGN is, the users > don't seem to mind it at all. > > R's, > John > That depends on the level of service the users are already accustomed to. The generally piss-poor average level of service in the US may not be as noticeably impacted by CGN as better services. It also depends on the class of user. I know that I would pretty much be unable to continue subscribing to any provider that stuck me behind a CGN. It would be interesting to get visibility into the opt-out rate for Verizon?s ?Address Sharing? announcement. Owen From owen at delong.com Tue Mar 25 00:56:44 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:56:44 -0700 Subject: arin representation In-Reply-To: References: Message-ID: <4E18CA32-F51D-4F73-962A-0B45E2D17D79@delong.com> On Mar 23, 2014, at 3:53 AM, Randy Bush wrote: > two questions: > > o of the /24s in the arin region, what percentage are owned by arin > members? > > o of the address holders in the arin region, what percentage are arin > members? > > i understand that the latter will be slightly jittered because of the > database mess with multiple org ids for one entity. but i suspect you > can get close enough for government work. > > randy It?s also impacted by the fact that most end-user resource holders with direct assignments do not choose to pay an extra fee for membership. So, the number that are ARIN members will be very different from the number that are direct assignments/allocations. Owen From owen at delong.com Tue Mar 25 00:56:44 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 17:56:44 -0700 Subject: [ARIN-20140324.341] Re: arin representation In-Reply-To: References: Message-ID: <894665398.120705.1395709151892.JavaMail.undefined> On Mar 23, 2014, at 3:53 AM, Randy Bush wrote: > two questions: > > o of the /24s in the arin region, what percentage are owned by arin > members? > > o of the address holders in the arin region, what percentage are arin > members? > > i understand that the latter will be slightly jittered because of the > database mess with multiple org ids for one entity. but i suspect you > can get close enough for government work. > > randy It?s also impacted by the fact that most end-user resource holders with direct assignments do not choose to pay an extra fee for membership. So, the number that are ARIN members will be very different from the number that are direct assignments/allocations. Owen From owen at delong.com Tue Mar 25 01:05:29 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 18:05:29 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <201403232009.47085.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> Message-ID: <073435F2-E8DE-4AD0-BE44-F9F81B17CAE7@delong.com> On Mar 23, 2014, at 11:09 AM, Mark Tinka wrote: > On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote: > >> ISP's have done a good job of brain washing their >> customers into thinking that they shouldn't be able to >> run services from home. That all their machines >> shouldn't have a globally unique address that is >> theoritically reachable from everywhere. That NAT is >> normal and desiriable. >> >> I was at work last week and because I have IPv6 at both >> ends I could just log into the machines at home as >> easily as if I was there. When I'm stuck using a IPv4 >> only service on the road I have to jump through lots of >> hoops to reach the internal machines. > > I expect this to change little in the enterprise space. I > think use of ULA and NAT66 will be one of the things > enterprises will push for, because how can a printer have a > public IPv6 address that is reachable directly from the > Internet, despite the fact that there is a properly > configured firewall at the perimetre offering half-decent > protection? > > Mark. So ULA the printers (if you must). That doesn?t create a need for ULA on anything that talks to the internet, nor does it create a requirement to do NPT or NAT66. Owen From bob at FiberInternetCenter.com Tue Mar 25 01:12:00 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 24 Mar 2014 18:12:00 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> References: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> Message-ID: <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> I agree with "one" thing herein.... > In order for IPv6 to truly work, everyone needs to be moving towards IPv6. Yep, chicken and the egg. I agree. We built an IPv6 "native" network - no tunneling - no customers to speak of ... didn't even bother to start IPv6 peering on it. > Maintaining dual protocols for the entire internet is problematic, > wasteful, and horribly > inefficient at best. Bottom line, the internet outgrew IPv4 almost 30 > years ago and > we?ve been using various hacks like NAT as a sort of IPv4 life-support > ever since. 30 years - oh, come on now - maybe it outgrown on someone's EBITDA chart they handed an investor. At least a couple of decades of exaggeration in that number. > > Ask any doctor about the prospects for a patient on life support for years > at a time > and they will probably laugh at you. Patients rarely survive more than a > few days > on life support, let alone weeks, months, or even years. > > Yes, we?ve done really well with internet life support. So well that many > have been > lulled into a false sense of safety believing that these extreme measures > can be > continued indefinitely and scaled well beyond their breaking points. > > There is little visibility into the escalating cost and complexity of > these measures > and even less awareness of the relative ease of deploying IPv6 compared to > most > of these mechanisms. Sorry Owen - bad analogy - unlike a person, IPv4 won't die because it can't accommodate more - here's a reality analogy for you. In the Internet Casino, all the Internet black jack tables are full. All seats taken. The players don't want to play with the new blue chip IPv6 currency. So the house simply raises IPv4 green chip minimum limit for a seat. An there you have it, how much is someone willing to pay for space in the Internet casino. Well, it's much more than free and probably close to the dollar level in the presentation by Lee Howard at an ARIN meeting (I think it was in Barbados or maybe I have that meeting place wrong and it was NANOG) ... Well, $40/month per IP address will be the pain level for all customers to finally cash-in the IPv4 chips and move to IPv6. While the world is not capitalistic, the USA is. Just because it works in Sweden doesn't mean it's ready to work here (Health Care). So what percentage of web pages are my USA customers reading in foreign languages ? Gee, the world doesn't need more IPv4 space to make an english page available to reach a US customer. Not much when they move their language base of users to IPv6 they will find they have plenty of IPv4 space left over. And what percentage of my customer base needs to put up IPv6 web pages ? Not many most of the world can't afford our goods - so that leaves a small percentage of US sites that need IPv6 and probably already have begun that in place. Thus far, IPv6 has been the "Field of Dreams" .... those of us who have built it, we know they have not yet come (the IPv6 customers). That's all this discussion is really about is "when will they come". I know the core of the Internet will be IPv4 for many years. All one has to do is talk to a few customer to find out that they are in no hurry. It's a no-brainer, because , none of us charges a customer more than than lunch money for an IPv4 address. Now, if you tell me all the porn site owners were great net citizens, ready to move to IPv6 and shut off IPv4 access, well then I can see things moving along much faster. Bob Evans Founder/CTO Fiber Internet Center > > Owen > > On Mar 22, 2014, at 2:25 AM, Bryan Socha wrote: > >> Fair point. There are some situations that do need more than most, but >> aren't they the ones that should be on ipv6 already??????? >> >> I know a few are shouldn't I be on ipv6 and that's fair too. I'm >> plqnnning some speaking engagements to cover that. Its not blind and >> ignoring. >> On Mar 22, 2014 4:36 AM, "TJ" wrote: >> >>> Millions of IPs don't matter in the face of X billions of people, and >>> XX-XXX billions of devices - and this is just the near term estimate. >>> (And don't forget utilization efficiency - Millions of IPs is not >>> millions of customers served.) >>> >>> Do IPv6. >>> /TJ >>> >>> On Mar 22, 2014 3:09 AM, "Bryan Socha" wrote: >>>> >>>> As someone growing in the end of ipv4, its all fake. Sure, the rirs >>> will >>>> run out, but that's boring. Don't believe the fake auction sites. >>>> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 >>>> for >>> no >>>> spam and $4 for legacy. Stop the inflation. Millions of IPS >>>> exist, >>>> there is no shortage and don't lie for rirs with IPS left. >>> > > > From owen at delong.com Tue Mar 25 01:18:16 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 18:18:16 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <532F55F7.3010802@mykolab.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> Message-ID: On Mar 23, 2014, at 2:45 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 3/23/2014 2:27 PM, Timothy Morizot wrote: > >> >> On Mar 23, 2014 11:27 AM, "Paul Ferguson" >> > >> wrote: >>> Also, IPv6 introduces some serious security concerns, and until >>> they are properly addressed, they will be a serious barrier to >>> even considering it. >> >> And that is pure FUD. The sorts of security risks with IPv6 are >> mostly in the same sorts of categories as those with IPv4 and have >> appropriate mitigations available. Moreover, by not enabling and >> controlling IPv6 on their networks, an operator is actually >> markedly more vulnerable to IPv6 attacks, not less. >> > > Only if end-points are unaware of dual-stack capabilities. > > Also, neighbor discovery, for example, can be dangerous (admittedly, > so can ARP spoofing in IPv4). And aside from the spoofable ability of > ND, robust DHCPv6 is needed for enterprises for sheer operational > continuity. > DHCPv6 is no less robust in my experience than DHCPv4. ARP and ND have mostly equivalent issues. > And that's only a "half" example. > > I haven't even mentioned spam management in v6, which will become a > nightmare if people have been relying on IP BL's or similar. IP reputation didn?t really scale to IPv4 and was only practical because we were willing to toss out vast swaths of hosts just because they were unfortunately behind the same NATed address as some host that did something wrong some time. So far, it?s proven to be the worst possible solution to SPAM except for all the others. Nonetheless, yes, we?re going to have to come up with a better way in IPv6. OTOH, we will also have better end-to-end accountability in IPv6, so that might actually help make new solutions more feasible. Owen From randy at psg.com Tue Mar 25 01:25:21 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 10:25:21 +0900 Subject: arin representation In-Reply-To: <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: john: i appreciate the numbers. thanks! and, btw, it has always been a pleasure to work with arin staff. > Total number of /24s of space directly registered in ARIN's database = > 6,644,175 (101.38 /8 equivalents) > > Of those: 2,808,621 /24s of space (42.3%) are registered to ARIN > members (42.86 /8 equivalents) > > Total number of Org IDs with directly registered IPv4 addresses = 26,148 > > Of those: 4,520 (17%) are ARIN members the arin membership consists of 17% of the address holding organizations in the region (plus a few folk who buy membership), and they hold 42% of the address space. so the 17% (give or take) elect the board [0], and the board, through a complex inside-controlled process [1], sets policy for the other unrepresented 83%. and the board and policy wonks set policy and contracts, among other things the lrsa and rsa, which place serious barriers to becoming a member, such as clauses with arin being able to unilaterally change ts&cs arbitrarily. [2] [3] and i know the "anyone can partiipate" theory. but in fact extremely few participate, and arin pays many of the policy wonks to fly around the world business class and spread the arin regulatory religion. no other rir does this. and this is a representative bottom up organization claiming legitimacy in the global arena? i would be interested in similar numbers for other rirs, and whether their service agreements are similarly onerous. (and i believe that ripe is actively tearing down barriers to participation). randy -- [0] as you know, there has been at least one occasion where the board election has been rigged. at your encouragement, i once submitted the whole nomination rig-a-marole to the nomcom. my name did not appear on the ballot, which i found out only when the ballot came out, and was never even viven a reason. [1] an outsider can not make a proposal that is not modifiably by an 'advisory' committee. and most are revised. [smell same problem as nomcom?] [2] who would sign such an agreement except under threat of not having the resources necessary to run their business? see http://en.wikipedia.org/wiki/Extortion [3] http://en.wikipedia.org/wiki/Barrier_to_entry From owen at delong.com Tue Mar 25 01:30:29 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 18:30:29 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: On Mar 23, 2014, at 5:24 PM, Mike Hale wrote: > "I wasn't aware that calling out FUD was derisive, but whatever." > It's derisive because you completely dismiss a huge security issue > that, given the state of IPv6 adoption, a great majority of companies > are facing. I would say that calling it FUD was fair game in this case. Ferg claimed it was a ?new unrelated attack?. In reality, it?s pretty much the same attack as most ARP attacks that exist in IPv4 and there are well known mitigations just as in IPv4 with similar difficulties and tradeoffs in their deployment. Sure, having 18 quintillion host addresses on a subnet vs. <254 creates some differences in the scale at which some of these attacks can be carried out, but that?s more a matter of scale than a matter of radically different attack surface. > Calling it FUD is completely wrong because it *is* a legitimate > security issue for most businesses. Sure, you've got the few who have > been able to properly plan for and secure their networks against the > increased attack surface of IPv6, but again...most companies haven?t. It?s no more legitimate than the similar issues in IPv4. IPv6 doesn?t actually present a significantly increased attack surface, it presents a very similar attack surface. The shape is a little different in some of the details, but the overall size and shape is pretty similar to IPv4. > Slinging false proclamations of FUD is as harmful as FUD itself. I wouldn?t say that either set of statements was 100% FUD or 100% non-FUD. I will say that vendors making hay out of IPv6 vulnerabilities as if they were novel or different from existing wide-spread IPv4 vulnerabilities in order to increase profits or reduce demands for IPv6 in their products is a fairly common practice that has been far more harmful than any IPv6 attack surface overall. Owen > > On Sun, Mar 23, 2014 at 4:49 PM, Timothy Morizot wrote: >> On Mar 23, 2014 6:21 PM, "Paul Ferguson" wrote: >>> Says you. >> >> And many others. My comments were actually reiterating what I commonly see >> presented today. >> >>> On the other hand, there are beaucoup enterprise networks unwilling to >>> consider to moving to v6 until there are management, control, >>> administrative, and security issues addressed. >> >> Whereas there are other enterprise networks, including mine, who are >> actively deploying IPv6 and have been for a number of years now. So unless >> you can come up with something truly novel that we haven't already dealt >> with, I'll stick by my use of FUD. >> >>> You can continue to deride our issues, and make derisive comments >>> until your heart's content, but it does not change reality. >> >> I wasn't aware that calling out FUD was derisive, but whatever. >> >> Cheers, >> >> Scott > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mike at mtcc.com Tue Mar 25 01:38:44 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 24 Mar 2014 18:38:44 -0700 Subject: misunderstanding scale In-Reply-To: <073435F2-E8DE-4AD0-BE44-F9F81B17CAE7@delong.com> References: <20140323051037.94159.qmail@joyce.lan> <20140323165726.E2A2F11B18F1@rock.dv.isc.org> <201403232009.47085.mark.tinka@seacom.mu> <073435F2-E8DE-4AD0-BE44-F9F81B17CAE7@delong.com> Message-ID: <5330DE24.1010406@mtcc.com> On 03/24/2014 06:05 PM, Owen DeLong wrote: > > So ULA the printers (if you must). > > That doesn?t create a need for ULA on anything that talks to the internet, nor does it create a requirement to do NPT or NAT66. > From a security perspective, I wouldn't trust my printer to not number itself with a GUA. Unlike v4 with DHCP, any kind of glitch causing leakage of RA's-bearing-Global-prefixes (i'm sure there is a Greek Tragedy written about this) will cause it to number the interface with that prefix. You can argue that's misconfiguration and I wouldn't disagree, but it's just way to easy for the (printer) host to do, and it wouldn't be very apparent to anything but the host (printer). I'm not entirely sure what the whole answer is to this. We're still talking about raw ip addresses here, so somebody would have to know the GUA the printer numbered itself to. Naming autodiscovery doesn't currently traverse subnets, though homenet and others are trying to relax that. Some sort of logic like "if I can't add my address to dns then don't listen to incoming requests on my gua" might be helpful, but as I said... people interested in this really should pay attention to the homenet working group which is charged, for better or worse, to sort a lot of this out. Mike From fergdawgster at mykolab.com Tue Mar 25 01:39:16 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 24 Mar 2014 18:39:16 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> Message-ID: <5330DE44.1020506@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It is unsettling to see such dismissive attitudes. I'll leave it as an exercise for the remainder of... everywhere to figure out why there is resistance to v6 migration, and it isn't "just because" people can't be bothered. Your customers are your compasses. And as Randy Bush always like to say (paraphrased), "I encourage my competitors to dismiss customer concerns over IPv6 migration." Cheers, - - ferg On 3/24/2014 6:18 PM, Owen DeLong wrote: > > On Mar 23, 2014, at 2:45 PM, Paul Ferguson > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 3/23/2014 2:27 PM, Timothy Morizot wrote: >> >>> >>> On Mar 23, 2014 11:27 AM, "Paul Ferguson" >>> > >>> wrote: >>>> Also, IPv6 introduces some serious security concerns, and >>>> until they are properly addressed, they will be a serious >>>> barrier to even considering it. >>> >>> And that is pure FUD. The sorts of security risks with IPv6 >>> are mostly in the same sorts of categories as those with IPv4 >>> and have appropriate mitigations available. Moreover, by not >>> enabling and controlling IPv6 on their networks, an operator is >>> actually markedly more vulnerable to IPv6 attacks, not less. >>> >> >> Only if end-points are unaware of dual-stack capabilities. >> >> Also, neighbor discovery, for example, can be dangerous >> (admittedly, so can ARP spoofing in IPv4). And aside from the >> spoofable ability of ND, robust DHCPv6 is needed for enterprises >> for sheer operational continuity. >> > > DHCPv6 is no less robust in my experience than DHCPv4. > > ARP and ND have mostly equivalent issues. > >> And that's only a "half" example. >> >> I haven't even mentioned spam management in v6, which will become >> a nightmare if people have been relying on IP BL's or similar. > > IP reputation didn?t really scale to IPv4 and was only practical > because we were willing to toss out vast swaths of hosts just > because they were unfortunately behind the same NATed address as > some host that did something wrong some time. > > So far, it?s proven to be the worst possible solution to SPAM > except for all the others. Nonetheless, yes, we?re going to have to > come up with a better way in IPv6. > > OTOH, we will also have better end-to-end accountability in IPv6, > so that might actually help make new solutions more feasible. > > Owen > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMw3kQACgkQKJasdVTchbLrmwEAkjajKru+lEgOO1U1i5c/AEQR /r8+H3dzeI+IyAKQAu8A/i0HEds8D3iyFnwKzLrUBwqP+Avt51BMW0+f67E4xmsX =vlZZ -----END PGP SIGNATURE----- From owen at delong.com Tue Mar 25 01:41:03 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 18:41:03 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> Message-ID: <29B7E466-E462-4717-90C9-E3B48F152265@delong.com> > "Your attack surface has already expanded whether or not you deploy IPv6." > Not so. If I don't enable IPv6 on my hosts, the attacker can yammer > away via IPv6 all day long with no result. If that were true, yes. The reality is that to make that a true statement, you would have to modify it to: ?If I specifically disable IPv6 on every single one of my hosts well enough that a compromised host cannot have IPv6 turned back on, the attacker can yammer away via IPv6 all day long with no result.? Best of luck achieving that with any operating system newer than, say, Windows ME. > "And if an enterprise doesn't have firewalls in place, then their > devices are already accessible." > For those devices that have publicly routable IP addresses, sure. Even for those that do not. It?s actually not that hard to craft a sequence of packets that can get past a NAT if you have even one compromised host somewhere behind the NAT. > "I've simply pointed out that it really isn't any harder to plan and > manage for v6 than for v4" > Except it is. I get your point that there aren't any additional > vulnerabilities in v6 than they are in v4. My point is that it's a > lot more work. And as someone who's facing this issue right now, I > promise you...it's a lot more work. I'm not saying it's not worth the > effort nor that it's unnecessary...but to imply that securing v6 is an > easy step up from securing v4 is inaccurate. It?s a little more work, but it doesn?t have to be a lot more work to achieve roughly the same security posture in IPv6 that you have in IPv4. It is, actually, a fairly easy step up in most cases. A little bit of a learning curve, but otherwise, most of the mitigation strategies are very similar and take about the same amount of effort. The difference comes from the fact that you?re facing all of the IPv6 stuff at once where you built the IPv4 mitigations over many years as vulnerabilities were discovered. > "Simply pretending that if you don't enable IPv6, you're somehow > immune from IPv6 threats is na?ve." > No. If I turn off v6 in my kernel, I am absolutely immune from native > v6 threats. I'm happy to be proven wrong if you can show me a case > where this isn't so. Is it so thoroughly turned off that a compromised host can?t modprobe it back on? If not, then absolutely immune is an interesting statement. Are you sure you have done that on every single host that has any ability whatsoever to get onto your network, including whatever laptop a vendor might bring into a wireless network or conference room? Whatever networks service technicians might plug their devices into? etc.? You can?t just not turn on IPv6? You have to actively turn it off on absolutely every single device everywhere in order to achieve what you claim. > Everything you've said is correct. But my point is simply that there > *are* security considerations when deploying v6, and they're bigger > than some rare and esoteric bug that's only exploitable when all the > stars align. With v6, a simple misconfiguration can open up every > single host directly to the outside. The same simply isn't true with > NAT where you have to explicitly define inbound rules. It is, actually? You don?t have to explicitly define inbound rules to open up all the hosts. True, the attacker doesn?t have quite the easy ability to target each host specifically, but there are lots of ways to attack hosts behind a NAT that happen to be kind enough to initiate outbound sessions. With many firewalls, there are even ways to exploit interesting artifacts of the way certain ?savings? are implemented in the NAT table process that allow you to create sessions that don?t exactly match the outbound traffic. Owen From owen at delong.com Tue Mar 25 02:04:45 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 19:04:45 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <001c01cf4710$0441be60$0cc53b20$@iname.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> <001c01cf4710$0441be60$0cc53b20$@iname.com> Message-ID: Since a second build-out is impractical (if not actually impossible) and they don?t sell UNEs, they are, in fact, pretty much exempt from direct competition for the same services. Owen On Mar 23, 2014, at 8:20 PM, Frank Bulk wrote: > I think I understand what you're saying -- you believe that RLECs that don't > have to provide UNE's are exempt from competition. I guess I don't see the > lack of that requirement meaning that there's no competition -- it just > means that the kind of competition is different. > > Frank > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Sunday, March 23, 2014 10:16 PM > To: Frank Bulk > Cc: nanog at nanog.org > Subject: RE: Level 3 blames Internet slowdowns on Technica > > Many rural LECs are not required to provide unbundled network elements. As > a network provider you can resell their service but they are not required to > provide unbundled elements necessary to compete against them as a facilities > based provider. So, for example, in Alamo Tennessee or Northern Wisconsin > you can get a T-1 from a competitive carrier that resells their services but > you cannot get competitive POTS service. You can buy DSL service from > anyone but they are reselling the RLECs DSL access services not just running > on their cable pairs. One of the biggest players that specializes in being > a rural LEC is Frontier Communications. > > Yes, there are wireless carriers and satellite providers but especially in > rural areas they are not a real viable alternative for high speed data since > we know the characteristic of satellite service and WISPs have the same > density problem in providing service in rural areas. It is hard for a WISP > to be profitable when you only have a handful of customers per mile. Same > formula, low density, long distances, high infrastructure per customer cost > for the WISP. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Sunday, March 23, 2014 10:08 PM > To: Naslund, Steve > Cc: nanog at nanog.org > Subject: RE: Level 3 blames Internet slowdowns on Technica > > Not sure which rural LECs are exempt from competition. Some areas are > effectively exempt from facilities-based (i.e. wireline) competition because > it's unaffordable, without subsidy, to build a duplicate wireline > infrastructure. There are also wireless carriers and WISPs the compete > against RLECs, as well as satellite providers. I'm not aware of any > exclusivity. > > Frank > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Sunday, March 23, 2014 9:00 PM > To: Joe Greco > Cc: nanog at nanog.org > Subject: RE: Level 3 blames Internet slowdowns on Technica > > > > In a low density area you can never fund a build out which is where > universal access charges came from and the reason that rural LECs are exempt > from competition. In return for building a network that is not profitable > easily they get exclusive access to sell services on it to give them a > chance. Will your NRC be reasonable anywhere outside a major metro area? > > > > Steven Naslund > Chicago IL > > > > > > From SNaslund at medline.com Tue Mar 25 02:17:02 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 02:17:02 +0000 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <5330DE44.1020506@mykolab.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <5330DE44.1020506@mykolab.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54225A7@MUNPRDMBXA1.medline.com> I can easily answer that one as a holder of v4 space at a commercial entity. The end user does not feel any compelling reason to move to ipv6 if they have enough v4 space. I can't give my employer a solid business case of why they need to make the IPv6 transition. They already hold enough v4 space and are putting more and more servers behind virtual IPs on boxes like the F5 so they are actually gaining on the v4 space issue. They see no economic reason to add an additional layer of complexity to their network where it is already pretty expensive to find savvy staff. Having to find v6 savvy staff is even more challenging. Even if the network guys are up to speed on v6 (admittedly a lot of the junior guys are not) the server and storage guys have a hard time wrapping their minds completely around ipv4. As soon as they see an economic reason to move toward a v6 deployment I am sure they will do so. The major cost is time not money. The engineering staff has quite enough to keep them busy without looking for projects with no ROI for the near future. As soon as ipv6 users cannot reach ipv4 sites, they will need an ipv6 presence. It is very much a chicken and egg problem. Ipv6 users need to reach ipv4 sites and the fact that they can makes it unnecessary for the ipv4 sites move to ipv6. Most commercial entities that are not in the gaming and multimedia do not feel any performance hit on v4 to v6 so there is no current pain point for the current ipv4 holders unless they are experiencing the need for more address space. The commercial users that have been around a long time typically have pretty large allocations (/24 or better) and the majority of them do not need that many public facing addresses. The thing that will push them toward a v6 infrastructure is having most of their customers on ipv6 and their being some performance penalty that they see for being ipv4 only. We are doing some lab testing on v6 and trying to get more experience for the junior guys but there are lots of legacy stuff and lots of old code that is not v6 aware. That stuff is slowly going away but there is no real push for that to happen. Running the v6 infrastructure in parallel with the v4 infrastructure does not gain anyone very much, unfortunately they will have to run in parallel for quite some time. Another issue is having all of their global MPLS carriers and Internet service providers supplying dual stack capability on those circuits. There is just not enough v6 traffic to make the case for dedicated access circuits supporting just ipv6. Steven Naslund Chicago IL >>It is unsettling to see such dismissive attitudes. >>I'll leave it as an exercise for the remainder of... everywhere to figure out why there is resistance to v6 migration, and it isn't "just because" people can't be bothered. >>Your customers are your compasses. And as Randy Bush always like to say (paraphrased), "I encourage my competitors to dismiss customer concerns over IPv6 migration." From owen at delong.com Tue Mar 25 02:15:55 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 19:15:55 -0700 Subject: misunderstanding scale In-Reply-To: <201403240838.27974.mark.tinka@seacom.mu> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> Message-ID: <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> On Mar 23, 2014, at 11:38 PM, Mark Tinka wrote: > On Sunday, March 23, 2014 09:35:31 PM Denis Fondras wrote: > >> When speaking of IPv6 deployment, I routinely hear about >> host security. I feel like it should be stated that this >> is *in no way* an IPv6 issue. May the device be ULA, >> LLA, GUA or RFC1918-addressed, the device is at risk >> anyway. >> >> If this is the only argument for delaying IPv6 >> deployment, this sounds more like FUD to me ;-) > > I guess it's no surprise that host security is not an IPv4 > or IPv6 issue. > > It's just that with IPv4, the majority of unclean and > unupdated hosts have been living behind NAT44. > > In an ideal IPv6 world, all hosts have GUA's, and in this > case, host security becomes a bigger problem, because now > the host is directly accessible without a NAT66 in between > (we hope). > > Mark. Bzzzt? But thanks for playing. An IPv6 host with a GUA behind a stateful firewall with default deny is every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 gateway. Owen From owen at delong.com Tue Mar 25 02:13:54 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 19:13:54 -0700 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: <423543E4-2119-4046-BCE7-8A16031D9E50@delong.com> On Mar 23, 2014, at 9:59 PM, Randy Bush wrote: >> But perhaps Randy is looking for the number of /24 equivalents >> allocated to legacy resource holders who haven't also received an IPv6 >> direct allocation or other IPv4 direct allocation under an RSA? > > what percentage of address space is held by members and what percentage > by non-members (lrsa-only is part of the latter)? > > what percentage of holding organizations are members and what percentage > not members (lrsa-only being part of the latter)? If you intend for RSA assignment holders to also be semi-randomly split between the two categories, then, yes. If not, then, your exact words do not say exactly what you intend. Owen From owen at delong.com Tue Mar 25 02:12:30 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 19:12:30 -0700 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> Message-ID: <4E92ED23-1C1D-429C-9071-BAAED4C5B151@delong.com> Yes and no? Everyone who receives a direct allocation is a member. Those who receive direct assignments from ARIN, OTOH, are not members unless they choose to also pay an additional $500/year for that membership. Owen On Mar 23, 2014, at 9:53 PM, Timothy Morizot wrote: > Unless I misremember, everyone who receives a direct allocation from ARIN > and signs an RSA is automatically a member. It's not clear to me what > "owner of a /24 network" means in that context. (I don't recall if signing > an LRSA in and of itself also makes one a member, since by the time we had > signed an LRSA, we had long since received our direct IPv6 allocation under > an RSA.) > > But perhaps Randy is looking for the number of /24 equivalents allocated to > legacy resource holders who haven't also received an IPv6 direct allocation > or other IPv4 direct allocation under an RSA? > > Scott > > > On Sun, Mar 23, 2014 at 10:46 PM, Naslund, Steve wrote: > >> Exactly right John. I think the term "owned" is a problem here. >> >> It seems to me that the terms would correctly be "holder" or who the >> address space was issued to or "user" being the end user using that space. >> >> Wouldn't all of the holders be ARIN members unless grandfathered in? >> >> Steven Naslund >> Chicago IL >> >> -----Original Message----- >> From: John Curran [mailto:jcurran at arin.net] >> Sent: Sunday, March 23, 2014 10:36 PM >> To: Randy Bush >> Cc: North American Network Operators' Group >> Subject: Re: arin representation >> >> On Mar 23, 2014, at 6:53 PM, Randy Bush wrote: >> >>> two questions: >>> >>> o of the /24s in the arin region, what percentage are owned by arin >>> members? >> >> Randy - >> >> Happy to generate these - two questions for clarity. >> >> 1) Should we expand /16's and /8's into the corresponding number of /24's ? >> (or do you only want those blocks issued originally as /24's to be >> counted) >> >> 2) In terms of categories, we could go strictly with /24's held by ARIN >> members >> versus /24's held by non-members (and resulting percentages); note >> that would >> be predominantly ISPs since end-users assignments from ARIN are >> unlikely to be >> members unless they specifically opted to join. Alternatively, we >> could provide >> counts /24's under RSA, /24's under LRSA, and /24's >> legacy-no-agreement as the >> three categories of counts desired (and each percentage of the total) >> >> So, based on above, would you prefer the /24 space statistics as asked >> (member/non-member) or rsa/lrsa/legacy-no-agreement? >> >>> o of the address holders in the arin region, what percentage are arin >>> members? >> >> Will do. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> >> From SNaslund at medline.com Tue Mar 25 02:24:23 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 02:24:23 +0000 Subject: arin representation In-Reply-To: <4E92ED23-1C1D-429C-9071-BAAED4C5B151@delong.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <4E92ED23-1C1D-429C-9071-BAAED4C5B151@delong.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B54225CE@MUNPRDMBXA1.medline.com> That is correct as long as that direct allocation came from ARIN. A really large chunk of address space was allocated (especially to the government entities) way before ARIN was controlling the space. I think the large percentage of space held by non-ARIN members come from those really large allocations going back to ARPANET and DDN days. AFAIK A lot of those entities are not necessarily members although they could be if they want to be. Steven Naslund >>Yes and no... Everyone who receives a direct allocation is a member. >>Those who receive direct assignments from ARIN, OTOH, are not members unless they choose to also pay an additional $500/year for that membership. >>Owen From jcurran at arin.net Tue Mar 25 02:28:40 2014 From: jcurran at arin.net (John Curran) Date: Tue, 25 Mar 2014 02:28:40 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: <0F69D091-BE68-4A69-8BD5-7E295F0AC27A@arin.net> On Mar 25, 2014, at 9:25 AM, Randy Bush wrote: > john: > > i appreciate the numbers. thanks! and, btw, it has always been a > pleasure to work with arin staff. Thanks (we do work for you, member or not, if you hold resources in the region.) > ... > the arin membership consists of 17% of the address holding organizations > in the region (plus a few folk who buy membership), and they hold 42% of > the address space. Correct. > so the 17% (give or take) elect the board [0], and the board, through a > complex inside-controlled process [1], sets policy for the other > unrepresented 83%. To be perfectly clear, it is even lower in practice... 17% _could_ elect the ARIN Board and the ARIN Advisory Council (ARIN AC), but that would be presuming 100% participation. Actual election participation is actually fairly high for an association; we had approx 15% participation (~ 600 organizations) in 2013 elections - > ...and the board and policy wonks set policy and > contracts, among other things the lrsa and rsa, which place serious > barriers to becoming a member, such as clauses with arin being able to > unilaterally change ts&cs arbitrarily. [2] [3] You might want to tease those two statements apart - The ARIN Board provides organization oversight, and this includes fees, services, contracts and related terms and conditions. The ARIN AC administers the policy process, and this includes incorporating edits to draft policies based on the community discussion. > and i know the "anyone can partiipate" theory. but in fact extremely > few participate, and arin pays many of the policy wonks to fly around > the world business class and spread the arin regulatory religion. no > other rir does this. I do not know if the other RIRs send their equivalent community "policy working group" folks to other RIR meetings; we do - the purpose is not evangelism but to bring back information on ongoing policy developments in other regions. > and this is a representative bottom up organization claiming legitimacy > in the global arena? i would be interested in similar numbers for other > rirs, and whether their service agreements are similarly onerous. (and > i believe that ripe is actively tearing down barriers to participation). It is true that we have an abundance of resource holders who received resources prior to ARIN, and that is going to skew the numbers for this region significantly. I know that you don't believe that we've been tearing down barriers to participation, but one of the reasons that the legacy service agreement was updated (again) recently was specifically to be more explicit about rights for the address holder. We specifically lay these out now, note that revocation will not occur based on utilization, and provide a fee schedule that is favorable compared to those issued resources after ARIN's formation. There does remain one very significant difference between some in the community and ARIN - that is on the applicability of community-developed policy to legacy holders, and this is a fairly fundamental issue that has definitely reduced interest in folks signing an LRSA and participating as members. FYI - I'm going to comment on your footnotes, since you use terminology below which is factually incorrect. > [0] as you know, there has been at least one occasion where the board > election has been rigged. at your encouragement, i once submitted > the whole nomination rig-a-marole to the nomcom. my name did not > appear on the ballot, which i found out only when the ballot came > out, and was never even viven a reason. ARIN has a nomination committee (like many other Internet organizations such as IETF, ISOC, ICANN) and its deliberations are private. I do not sit on it, so there is not much I can add, but I would definitely welcome suggestions for improvements to the nomination and election process. A NomCom (composed of a selection of Board, AC, and at large members) which deliberates privately does not equate to "rigged" by any means, although I will agree it does raise reasonable questions of transparency. Note that anyone can make it onto the ballot via petition, and that is a mechanism that has been used successfully in the past. > [1] an outsider can not make a proposal that is not modifiably by an > 'advisory' committee. and most are revised. [smell same problem > as nomcom?] While the ARIN AC does hold the editors pen (and from what I am told does a good job of reflecting discussions), there has always been (and remains today) a simple petition process available at each stage if you think that they have somehow failed and want your original text to go to the ARIN Public policy meeting and the ARIN Board. > [2] who would sign such an agreement except under threat of not having > the resources necessary to run their business? see http://en.wikipedia.org/wiki/Extortion Membership organizations set terms and conditions for their services, and ARIN is no different. The answer is, of course, to participate in the election process; as you have already noted, if even a fraction of a percent of the community (30 to 50 folks) felt strongly there was a major issue, they could put candidates in each election which were assured of being elected, and could in short order significantly alter practices to better match their expectations. That would be a case of improved community representation, and therefore the most appropriate outcome. I appreciate your note, Randy - far better to express these concerns and get folks thinking about them than to have them go unstated... Thanks! /John John Curran President and CEO ARIN p.s. Discussion of improvements to ARIN election process would probably be best send over to ARIN-discuss or PPML (for sake of those here who lack interest) but I'll leave that to this list to decide. I would also recommend (for folks who have suggestions they'd like to send privately) to send them to me, and I'll get them to the ARIN Board. From SNaslund at medline.com Tue Mar 25 02:47:31 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 02:47:31 +0000 Subject: misunderstanding scale In-Reply-To: <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> Exactly right. In fact that is generous because the v6 host having a stateful firewall has a real protocol aware firewall (and often bundled IDS/IPS capability) not just a NAT to protect him. The NAT provides almost no security once a single host behind the NAT is compromised and makes an outbound connection. Bang, instant VPN connection to the internal network. A perimeter defense relying on NAT is a house of cards that only needs one nick for the whole thing to come down. Lots and lots of enterprises count on a hard perimeter and almost nothing behind it so once I am in behind your NAT, you are unlikely to notice it until something real bad happens. That is the state of most enterprise network security today. C'mon guys how many Botnets and DDoS attacks do we need to see coming from home computers that are almost all behind NATs to realize that NAT is not a security feature. For you service providers out there, how many of your residential customers behind your NAT do you think are compromised in some way. If you can find a large enterprise that has not one piece of malware running on a single workstation, I will be surprised. With so many BYODs and laptops going in and out of your NAT perimeter there is no way you can assert that nothing behind your NAT is compromised. At least with v6 we can have a better idea of where a rogue connection is coming from. Look at it this way. If I see an attack coming from behind your NAT, I'm gonna deny all traffic coming from your NAT block until you assure me you have it fixed because I have no way of knowing which host it is coming from. Now your whole network is unreachable. If you have a compromised GUA host I can block only him. Better for both of us, no? How about a single host spamming behind your NAT blocking your entire corporate public network from email services? Anyone ever see that one. Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to deal with that. Maybe GUAs will convince (scare) more enterprise users to actually treat the internal network as an environment that needs to be secured as well. We can only hope. Steven Naslund >>Bzzzt... But thanks for playing. >>An IPv6 host with a GUA behind a stateful firewall with default deny is every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 gateway. >>Owen From james at freedomnet.co.nz Tue Mar 25 02:56:16 2014 From: james at freedomnet.co.nz (james jones) Date: Mon, 24 Mar 2014 22:56:16 -0400 Subject: ms word In-Reply-To: References: Message-ID: Thanks for the heads up! On Mon, Mar 24, 2014 at 7:07 PM, Randy Bush wrote: > this would be a good time to tll your users not to send or open ms word > documents. active 0day > > > http://arstechnica.com/security/2014/03/zero-day-vulnerability-in-microsoft-word-under-active-attack/ > > randy > > From owen at delong.com Tue Mar 25 03:00:58 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 20:00:58 -0700 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <1395644446.3279.26.camel@karl> Message-ID: On Mar 24, 2014, at 9:20 AM, William Herrin wrote: > On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer wrote: >> Addressable is not the same as >> accessible; routable is not the same as routed. > > Indeed. However, all successful security is about _defense in depth_. > If it is inaccessible, unrouted, unroutable and unaddressable then you > have four layers of security. If it is merely inaccessible and > unrouted you have two. That is, frankly, so gross an oversimplification as to be not only misleading, but outright inaccurate in many cases. When considering defense in depth, layer thickness counts as much or more than number of layers. unroutable and unaddressable (which NAT and RFC-1918 arguably don?t actually provide in reality) are roughly equivalent to a slide-lock on a screen door in front of a stateful inspection bank vault door in front of an unrouted iron-bar day-door inside the vault. I would argue that the value added by the screen door and its associated slide lock is near zero in the total equation. Further, since the reality is that NAT and RFC-1918 can be exploited by the attackers to help hide their identity and obscure their activities, they are actually not added depth, but in fact erode the actual security. Further, since it is such a widely held misperception that they provide security, there?s probably a certain amount of negative impact due to the complacency and lack of vigilance that creates as well. Owen From owen at delong.com Tue Mar 25 03:02:51 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 20:02:51 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> Message-ID: <8B8CEC40-1143-435C-A4C7-AE4DCF6396B6@delong.com> On Mar 24, 2014, at 9:21 AM, William Herrin wrote: > On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: >> I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. > > Hi Steve, > > It is your privilege to believe this and to practice it in the > networks you operate. > > Many of the folks you would have deploy IPv6 do not agree. They take > comfort in the mathematical impossibility of addressing an internal > host from an outside packet that is not part of an ongoing session. > These folks find that address-overloaded NAT provides a valuable > additional layer of security. Which impossibility has been disproven multiple times. > Some folks WANT to segregate their networks from the Internet via a > general-protocol transparent proxy. They've had this capability with > IPv4 for 20 years. IPv6 poorly addresses their requirement. Actually, there are multiple implementations of transparent proxies available for IPv6. NAT isn?t the same thing at all. If you want to make your life difficult in IPv6, you can. Nobody prevents you from doing so. It is discouraged and non-sensical, but quite possible at this point. Owen From Valdis.Kletnieks at vt.edu Tue Mar 25 03:13:00 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 Mar 2014 23:13:00 -0400 Subject: misunderstanding scale In-Reply-To: Your message of "Tue, 25 Mar 2014 02:47:31 -0000." <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> Message-ID: <12103.1395717180@turing-police.cc.vt.edu> On Tue, 25 Mar 2014 02:47:31 -0000, "Naslund, Steve" said: > Lots and lots of enterprises count on a hard perimeter and almost nothing > behind it so once I am in behind your NAT, you are unlikely to notice it until > something real bad happens. That is the state of most enterprise network > security today. "All of ARPA's protection has, by design, left the internal AT&T machines untested--a sort of crunchy shell around a soft, chewy center. We run security scans..." ches Fri Apr 20 07:46:11 EDT 1990 http://www.cheswick.com/ches/papers/gateway.pdf For the Beloit College class of 2014, the Internet has always had a soft chewy center.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From owen at delong.com Tue Mar 25 03:13:04 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 20:13:04 -0700 Subject: misunderstanding scale In-Reply-To: <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com>, <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> Message-ID: <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> On Mar 24, 2014, at 9:36 AM, Alexander Lopez wrote: > not to mention the cost in readdressing your entire network when you change an upstream provider. > > Nat was a fix to a problem of lack of addresses, however, the use of private address space 10/8, 192.168/16 has allowed many to enjoy a simple network addressing scheme. This is easily and better solved in IPv6 using provider independent addressing which is readily available. > Ipv6 requires a complete reeducation of they way we look at routing and the core of the network. I wouldn?t say complete, but significant. Owen From lou at metron.com Tue Mar 25 03:18:21 2014 From: lou at metron.com (Lou Katz) Date: Mon, 24 Mar 2014 20:18:21 -0700 Subject: Anyone from megapth networks? Message-ID: <20140325031821.GA85010@metron.com> Please contact me offlist about an NTP attack. -- -=[L]=- Composed on an ASR33 Linux? Is that an OS, like Pentium? From SNaslund at medline.com Tue Mar 25 03:19:56 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 03:19:56 +0000 Subject: arin representation In-Reply-To: <0F69D091-BE68-4A69-8BD5-7E295F0AC27A@arin.net> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> <0F69D091-BE68-4A69-8BD5-7E295F0AC27A@arin.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542263E@MUNPRDMBXA1.medline.com> Randy, I am not sure I understand the argument here. If you think that ARIN is not representing the address space holders in proper fashion, how would we suggest correcting that? If an address holder does not become a member (which is fairly easy to do if you care enough) how would we even know what their concerns or feelings are? It is like any electoral process, if you choose not to represent yourself it is hard to complain about the outcomes. ARIN does work under a contract so I would assume if there were serious concerns about their structure or conduct, there is some oversight being conducted. My earlier comments regarding legacy space holders and the number of address space holders goes to the heart of using those stats to make your assertion. First of all, the number of /24s is not proportional to the total number of members Whether I hold 50 or 1000 /24s, I am still one member. I would assumes that holders of large amounts of space (like service providers) are more likely to be members than the entity that holds one smaller allocation for their business purposes. Given that the US Gov't holds a vast amount of the legacy space skews the results a lot. They might or might not be a "member" but they certainly hold a lot of influence in ARINs operation as the one who controls the contract. If ARIN was to cross them the wrong way, they might not be holding that contract very long. The reality of the Internet is that much of the policy and standard making comes from a small very technical minority of its users like us. Most users of the Internet could care less about numbering policy and RFCs because they don't feel the impact of it, they just use and enjoy the technology. They just don't care about the wizards behind the curtain. Issues that look important inside our fishbowl do not mean much to the outside world. Just ask every person that uses an IP address where they came from an see how many know or care. If the general public was to feel much pain in the process they might ask more questions but it seems that in general they are sufficiently happy not to worry about the details. As a service provider I was more concerned with ARIN policy than I am now as a commercial entity holding a couple of blocks. When I was a provider I cared about allocation and process more because I had a continuous need for more space for growth. Back then ARIN was new and the process changes were very fluid and hard to keep up with. As a commercial entity with enough space for the future and no major expansion plans I am less concerned about ARIN policy short of them trying to pull back my space (which they seem to be doing everything possible to avoid). John may be too polite to say so but I think asking him for information publicly on NANOG (which he very promptly responded to) and then publicly slamming ARINs process does not seem very fair to me. ARIN has a process for having views like this to be heard and a process for taking the helm (or at least some of it) if you think enough people agree. If John cares enough to monitor and respond to the community here on NANOG, I find it hard to believe that they don't care about our concerns. Steven Naslund Chicago IL From owen at delong.com Tue Mar 25 03:22:10 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 20:22:10 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <7053AFC7-45DB-4361-B201-906308B34224@ianai.net> Message-ID: On Mar 24, 2014, at 10:35 AM, Laszlo Hanyecz wrote: > > On Mar 24, 2014, at 5:05 PM, "Patrick W. Gilmore" wrote: > >> On Mar 24, 2014, at 12:21, William Herrin wrote: >>> On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: >> >>>> I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. >> >>> Many of the folks you would have deploy IPv6 do not agree. They take >>> comfort in the mathematical impossibility of addressing an internal >>> host from an outside packet that is not part of an ongoing session. >>> These folks find that address-overloaded NAT provides a valuable >>> additional layer of security. >>> >>> Some folks WANT to segregate their networks from the Internet via a >>> general-protocol transparent proxy. They've had this capability with >>> IPv4 for 20 years. IPv6 poorly addresses their requirement. >> > > It's unfortunate that it is the way it is, but many enterprise people have this ingrained in them - they don't want to be connected to the internet except for a few exceptions. Just the fact that they can't ping their machines gives them a warm and fuzzy. In a run-of-the-mill default NAT setup, you can deploy a network printer with no security and nobody from the internet can print to it. It's default deny, even without setting anything else up, by virtue of not being on the internet and not having an address. I know there are ways to subvert a NAT but that applies to perimeter and host firewalls too. IPv6 global numbers are great for those of us that actually want to connect to the internet, but enterprise people with rfc1918 numbering have gotten used to being disconnected, and while most of us know that it's trivial to firewall IPv6, it's still a big jump from using a NAT/proxy to being 'on the internet'. It's even more complex if it's only halfway and there are two different protocols to manage. This mindset is why so many printers are delivering copies of everything printed to $badguy without the knowledge of many IT departments. You may not be able to print to it, but really, if you had access to a random printer somewhere, how many people would really want to print to it? In my experience, having had such a device on line as an experiment for several years, it?s a very small number. In more than 5 years with such a device on line with no NAT, no packet filter, nothing, only 3 print jobs came in from unauthorized users. Lots of other things were done to the printer to try and get it to do various things a printer just shouldn?t do. Now, just having the printer behind NAT doesn?t prevent that, because likely someone who has access to the printer inside the organization will download some piece of malware that reprograms the printer as desired, eliminating the need to compromise the printer through the NAT. > People will always resist change, and in this case, why should they change when it's only going to make their job harder? Makes sense to me, but I wish it weren't that way. They will probably just find ways to proxy and NAT IPv6 too, so that it fits the IPv4 model with 'private' addresses. I suppose it?s possible, but I think, so far, education actually seems to be making progress. Please don?t give up hope yet. Owen From SNaslund at medline.com Tue Mar 25 03:35:15 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 03:35:15 +0000 Subject: How robust is the V6 to V4 infrastructure? Message-ID: <9578293AE169674F9A048B2BC9A081B4B5422674@MUNPRDMBXA1.medline.com> A question came to mind with all the discussion of ipv6 vulnerabilities. I am wondering for those with a lot of real world pure IPv6 connectivity, how robust have been the V6 to V4 gateways necessary for intercommunication between native IPv6 hosts and the IPv4 world? I was thinking that going to native ipv6 depends heavily on these gateways being reachable and having fairly high performance characteristics. How are the service providers doing providing these services? Steven Naslund Chicago IL From owen at delong.com Tue Mar 25 03:32:35 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 20:32:35 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54222B9@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> <9578293AE169674F9A048B2BC9A081B4B54221F9@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B54222B9@MUNPRDMBXA1.medline.com> Message-ID: <52CB56AB-6E46-4C1D-A2E0-3ED4154E2916@delong.com> This assumes installing a single home on demand. In reality, if you?re going to implement what Jay and I are suggesting, then you dig up a neighborhood at a time and drop a bunch of strands of fiber (I?d guess 8 or 16 as likely numbers) per household. Owen On Mar 24, 2014, at 11:57 AM, Naslund, Steve wrote: > Thinking about this again, let's take Jay at his word that he can make a "passing" for $700-800. Unfortunately, the ISP or service provider does not pay for a passing, they pay for an entry. After all we can't let them make their own entry or we will have everyone and their brother in our splice case. We will also have third world aerial spaghetti as they all run their own drop cables using God knows who as "skilled labor". I will take my home here in residential Chicago as a best case example because the neighborhood is dense. All of our utilities here are aerial so there are no underground conduits available to you. I assume to keep costs down you are going to try to use what's there and go aerial. If you are in the suburbs that cable is all underground so at a minimum you will need a directional boring machine and put in the necessary pedestals and hand holes. In this county you are required to use conduit every time you go under a public street as well. I digress though, let's take the easy case. > > 1. You need to decide how many strands you are going to drop to my home. You could drop a single fiber or pair but then you have to put mux equipment on the end of it. After all I want choice and that might include TV from provider X, phone from provider Y, and high speed data from provider Z. > > 2. Since you are the sole provider of the physical layer, you now have to roll a two man crew with a bucket truck and an experienced splicer. By the way, this is Chicago so we have to have a two man crew at a minimum and they are both IBEW union contractors since this city will NEVER hire non-union labor. Figure they might have a 20-30 minute drive here is traffic cooperates. They get paid hourly so they don't much care how long it takes but let's say they are feeling frisky today and only take about two hours on the job itself plus the hour of travel. > > 3. Let's assume that the best case exists and the splice case is directly in my alley behind my house. Your crew needs to splice a drop cable in at the splice case (you did pay to install the splice cases right?) and run it about 100 ft to the back of my house and anchor it to my brick home at the prescribed height above ground. You can't get the bucket truck in my yard so they break out the extension ladder. In most case though the splice case will not be that close and certainly can't afford to put a case at every home at $700 per passing. So in reality that cable probably runs to the alley and several poles down the block, they have to anchor that cable at every poll so Tarzan can't use your fiber for fun. > > 4. Now that they have the cable at my house you have to place a MPOE (minimum point of entry) device on my house. That box probably costs a couple bucks and has to be anchored into brick. > > Are we getting closer to that $2,400 per home yet? What if this is the suburbs and you have to direct bury enough cable to reach the pedestal on the corner and cross my one acre lot with it? > > Steven Naslund > Chicago IL > > > > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Monday, March 24, 2014 12:25 PM > To: NANOG > Subject: Re: Level 3 blames Internet slowdowns on Technica > > ----- Original Message ----- >>> From: "Steve Naslund" > >>> What do you mean by average monthly bill? That is the issue here. The >>> average monthly bill includes the services you are getting. In the >>> Chicago area a fiber optic access circuit unbundled from the >>> imcumbent carrier to a competitive carrier is something like $10 a month or so. >>> How could you possibly think you can fund a build out in a new area >>> for that price? It may be possible to pay for that over 20 years. The >> problem is that no one goes into business to break even over 20 years. > >> Well, Steve, happens we had this conversation in some detail last year when I was up for a City IT director position, and contemplating fibering >> 12,000 passings. > >> The magic number is apparently $700-800 per passing, not the $2400 you seem to suggest... > From george.herbert at gmail.com Tue Mar 25 03:52:48 2014 From: george.herbert at gmail.com (George Herbert) Date: Mon, 24 Mar 2014 20:52:48 -0700 Subject: misunderstanding scale In-Reply-To: <8B8CEC40-1143-435C-A4C7-AE4DCF6396B6@delong.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <8B8CEC40-1143-435C-A4C7-AE4DCF6396B6@delong.com> Message-ID: On Mon, Mar 24, 2014 at 8:02 PM, Owen DeLong wrote: > > On Mar 24, 2014, at 9:21 AM, William Herrin wrote: > > > On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve > wrote: > >> I am not sure I agree with the basic premise here. NAT or Private > addressing does not equal security. > > > > Hi Steve, > > > > It is your privilege to believe this and to practice it in the > > networks you operate. > > > > Many of the folks you would have deploy IPv6 do not agree. They take > > comfort in the mathematical impossibility of addressing an internal > > host from an outside packet that is not part of an ongoing session. > > These folks find that address-overloaded NAT provides a valuable > > additional layer of security. > > Which impossibility has been disproven multiple times. > > > Some folks WANT to segregate their networks from the Internet via a > > general-protocol transparent proxy. They've had this capability with > > IPv4 for 20 years. IPv6 poorly addresses their requirement. > > Actually, there are multiple implementations of transparent proxies > available > for IPv6. NAT isn't the same thing at all. > > If you want to make your life difficult in IPv6, you can. Nobody prevents > you from > doing so. It is discouraged and non-sensical, but quite possible at this > point. > > Owen > > > Right. fc00::/7 exists. If you want to emulate your internal use of 10.0.0.0/8 plus NAT (or, proxies or load balancers or whatever) in your IPv6 implementation go ahead. Putting in some robust filtering that if the fc00::/7 ever appears outside the internal gateway the traffic goes poof should be as easy as the equivalents for 10, 172.16, 192.168 ... -- -george william herbert george.herbert at gmail.com From SNaslund at medline.com Tue Mar 25 03:56:14 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 03:56:14 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <52CB56AB-6E46-4C1D-A2E0-3ED4154E2916@delong.com> References: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> <9578293AE169674F9A048B2BC9A081B4B54221F9@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B54222B9@MUNPRDMBXA1.medline.com> <52CB56AB-6E46-4C1D-A2E0-3ED4154E2916@delong.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542269D@MUNPRDMBXA1.medline.com> You are right but that is usually how it works with fiber because that last drop to the home is a pretty expensive piece that you don't usually want installed until it is needed. The LECS usually don't even light a building unless there is a service that requires it. I was trying to make the point that $700 - 800 per premise as quoted seems extremely low to me. The cost of the cable, splices, cases, MPOEs, and especially labor make that number unbelievable to me. I am coming at this as someone who was in charge of a similar project that connected every building on US Air Force bases to a fiber backbone. An Air Force base is very similar to a suburb in a lot of respects in terms of density and utilities structure. I was responsible for the design, pricing, procurement, and contractor management on that project. We had 3,000 buildings in approximately a eight square mile area and the total project cost was in excess of $12 million dollars which equates to something like $4000 per building. Granted we were doing 12 strands per building but cable costs have fallen since this project so they should be pretty close. That project included the backbone and the drops into each building. Between those two, the drops into each building was the biggest challenge for underground deployments since no underground conduits were usually available and there was a lot of existing infrastructure to be avoided. I would imagine that if it was a new subdivision it would be much easier but in a 50 plus year old neighborhood there are tons of unknown obstacles and challenges. The labor for splicing and cable pulling itself was provided by Air Force cable technicians so did not factor into the costs. The costs were mostly civil construction under streets where duct were full and the addition of many manholes and handholes because original manholes were not in the right positions to support the infrastructure or were decayed from being in ground for 50 plus years. I would say that about half of the money went for civil construction of duct infrastructure and the remainder went to cable and various hardware items. Yes, you could go all direct burial but under streets, that is a maintenance nightmare that you are going to pay for someday. The Air Force required manholes and conduit under streets to allow for future serviceability and it was probably a good move since we did use a lot of pre-existing conduit going from copper to fiber. Steven Naslund >>This assumes installing a single home on demand. >>In reality, if you're going to implement what Jay and I are suggesting, then you dig up a neighborhood at a time and drop a bunch of strands of fiber (I'd guess 8 or 16 as likely numbers) per >>household. >>Owen From owen at delong.com Tue Mar 25 04:03:17 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 21:03:17 -0700 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: On Mar 24, 2014, at 6:25 PM, Randy Bush wrote: > john: > > i appreciate the numbers. thanks! and, btw, it has always been a > pleasure to work with arin staff. > >> Total number of /24s of space directly registered in ARIN's database = >> 6,644,175 (101.38 /8 equivalents) >> >> Of those: 2,808,621 /24s of space (42.3%) are registered to ARIN >> members (42.86 /8 equivalents) >> >> Total number of Org IDs with directly registered IPv4 addresses = 26,148 >> >> Of those: 4,520 (17%) are ARIN members > > the arin membership consists of 17% of the address holding organizations > in the region (plus a few folk who buy membership), and they hold 42% of > the address space. > > so the 17% (give or take) elect the board [0], and the board, through a > complex inside-controlled process [1], sets policy for the other > unrepresented 83%. and the board and policy wonks set policy and > contracts, among other things the lrsa and rsa, which place serious > barriers to becoming a member, such as clauses with arin being able to > unilaterally change ts&cs arbitrarily. [2] [3] Many facts not in evidence in that paragraph some of which are outright wrong. [0] As a member of the nominating committee in question, I will disagree with your claim that our declining to nominate you constitutes rigging the election. While I can?t disclose the details due to NDA restrictions on the NomCom, I will say that in my experience having served on the NomCom several times, they consider each potential nominee and do not take their duties lightly. [1] Anyone can make a proposal. If the outsider?s proposal is modified by the AC, and the proposer does not like the modifications, the proposer has an available petition process by which they can, if successful, get the original proposal directly to the community for consideration. IIRC, this petition process requires 10 or fewer people to support the proposer?s position in order to succeed. As to the LRSA/RSA, in fact, the policies cannot be changed unilaterally, they must be changed by a community driven consensus process except in the case of emergency policy action by the board. To the best of my knowledge, the board has only used that emergency authority twice. Any emergency action is subject to review by the AC within 1 month and by the community within 6 months. > and i know the "anyone can partiipate" theory. but in fact extremely > few participate, and arin pays many of the policy wonks to fly around > the world business class and spread the arin regulatory religion. no > other rir does this. Anyone with an email address who chooses to make the effort can easily participate. The barrier to participation is close to zero. If you have constructive suggestions on ways to increase participation, they are welcome. The other RIRs do, in fact, send representatives to all of the RIR meetings, so I?m not sure how you can make the above claim, unless your real concern is the fact issue of the business class travel. Owen From gary.buhrmaster at gmail.com Tue Mar 25 04:47:17 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 25 Mar 2014 04:47:17 +0000 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542269D@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4B5420BFF@MUNPRDMBXA1.medline.com> <21134426.12495.1395681907873.JavaMail.root@benjamin.baylink.com> <9578293AE169674F9A048B2BC9A081B4B54221F9@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4B54222B9@MUNPRDMBXA1.medline.com> <52CB56AB-6E46-4C1D-A2E0-3ED4154E2916@delong.com> <9578293AE169674F9A048B2BC9A081B4B542269D@MUNPRDMBXA1.medline.com> Message-ID: On Tue, Mar 25, 2014 at 3:56 AM, Naslund, Steve wrote: > You are right but that is usually how it works with fiber because that last drop to the home is a pretty expensive piece that you don't usually want installed until it is needed. The LECS usually don't even light a building unless there is a service that requires it. I was trying to make the point that $700 - 800 per premise as quoted seems extremely low to me. If one believes the estimates from the Google Fibre rollout in Kansas City (and I suspect they are all wrong, but they probably have the magnitude right) the cost was (about) $600/premise passed. As you point out, the passed part is important, and did not include that last 100 yards of install and equipment. But that last 100 yards (and equipment) does not need to be spent until a subscriber signs on the dotted line. So the order of magnitude to pass a premise is roughly consistent between this known example of a recent build-out, and Jay's numbers, with all the right stars in alignment (I believe Google Fibre got agreements in advance regarding abbreviated and expedited zoning and permitting, which would likely have substantially decreased their costs (having seen how long/expensive that can take, I can understand why they wanted those agreements in place up front)). Now, whether a city would want to float a 30 year bond for city fibre, or for a new ballpark, or a new pier (or do all three and increase taxes by maybe 10%) and trust that "if you build it, they will come" is a different question. From randy at psg.com Tue Mar 25 05:07:38 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 14:07:38 +0900 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: ok, let me also try to be constructive. how the heck do we get ourselves out of a hole where we are ruled by self-perptuating monopolies which lack oversight and accountability. and it ain't just arin. look at the big [cc]tlds, the horror of icann, ... i believe the only real solution is to open the game as wide as possible. for arin, remove the onerous ts&cs and the rights issues from the lrsa so that we can all go out and get everyone to join and participate. change the governance. term limits for board members and AC are critical. i see little value in the AC except to create further blockage and diversion. require that 25% of the board have enable and get some social blood in there, e.g. a librarian, susan crawford (a real internet policy person, not a damned wannabe weenie), or whatever. and stop flying baby policy weenies around the world in business class to stand up in meetings and say they are from arin. if you want arin represented, send staff. if arin wants input from foonog or barnic, send staff. arin has some good staff. the policy wannabes not so much. create artifical competition by allowing rir venue shopping. these geographic monopolies were a mistake. randy, who really needs to go back to work From alex.lopez at opsys.com Tue Mar 25 05:12:09 2014 From: alex.lopez at opsys.com (Alexander Lopez) Date: Tue, 25 Mar 2014 05:12:09 +0000 Subject: misunderstanding scale In-Reply-To: <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com>, <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> Message-ID: > On Mar 24, 2014, at 9:36 AM, Alexander Lopez > wrote: > > > not to mention the cost in readdressing your entire network when you > change an upstream provider. > > > > Nat was a fix to a problem of lack of addresses, however, the use of > private address space 10/8, 192.168/16 has allowed many to enjoy a simple > network addressing scheme. > > This is easily and better solved in IPv6 using provider independent addressing > which is readily available. Yes but the number of people needing just a /64 will far outnumber the one requesting a /48. I would say that the majority of users today and for the future will not require a /48, but will simply use the allocation given to them by their upstream. Many today do not multi-home and how many SMB customers just use a single Public IP behind a NAT device? It is easy for us on this list to use or request PIA, but what about the 10 person office? It is late and I am just rambling, but even with DHCP(4and6) changing IP networks is not a trivial thing. Not hard, but it will require a lot more planning than what many do today of simply changing the WAN IP address and some records in the DNS (if needed) I am not saying anything that is new to members of this group, I guess I am just venting a bit of frustration. > > > Ipv6 requires a complete reeducation of they way we look at routing and > the core of the network. > > I wouldn't say complete, but significant. > > Owen From randy at psg.com Tue Mar 25 05:23:30 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 14:23:30 +0900 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: omg! a friend just sent this great example of how far down we have gone https://www.arin.net/about_us/committeecharters.html#governance there is a governance committee. guess the composition. "The Committee shall consist of three elected members from the Board of Trustees." how wonderfully corrupt. and this is the self same board which could not agree to limit their own terms, . "The Board discussed term limits for its members and members of the ARIN AC. No consensus was reached." my youngest granddaughter's kindergarten has better governance. and they're not even embarrassed. sheesh! randy From alex.lopez at opsys.com Tue Mar 25 05:25:31 2014 From: alex.lopez at opsys.com (Alexander Lopez) Date: Tue, 25 Mar 2014 05:25:31 +0000 Subject: misunderstanding scale In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> Message-ID: <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Monday, March 24, 2014 10:48 PM > To: Owen DeLong; mark.tinka at seacom.mu > Cc: nanog at nanog.org > Subject: RE: misunderstanding scale > > Look at it this way. If I see an attack coming from behind your NAT, I'm gonna > deny all traffic coming from your NAT block until you assure me you have it > fixed because I have no way of knowing which host it is coming from. Now > your whole network is unreachable. If you have a compromised GUA host I > can block only him. Better for both of us, no? That is assuming that the infected piece does not request another address in the /64, and that the person blocking at the target end blocks a /128 instead of the /64. > > How about a single host spamming behind your NAT blocking your entire > corporate public network from email services? Anyone ever see that one. > Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to deal > with that. I don't want to try to even think about SMTP on IPv6. Reputation of email servers as well as the whole thought process of spam control rely on a list of IP address. IPv6 adds an entirely new aspect to it. > > Maybe GUAs will convince (scare) more enterprise users to actually treat the > internal network as an environment that needs to be secured as well. We > can only hope. > Most enterprise admins, segment their BYOD (wifi) network from the production network. Some will even use a different WAN ip for the wifi network or in the minimum block outbound request to well known services ports. I generally see where the only outbound connections allowed are http and https. All other ports are blocked. > Steven Naslund > > > >>Bzzzt... But thanks for playing. > > >>An IPv6 host with a GUA behind a stateful firewall with default deny is > every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 > gateway. I can't argue there..... > > >>Owen > > From marka at isc.org Tue Mar 25 05:31:17 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Mar 2014 16:31:17 +1100 Subject: misunderstanding scale In-Reply-To: Your message of "Tue, 25 Mar 2014 05:12:09 -0000." References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com>, <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> Message-ID: <20140325053117.9A41011C5724@rock.dv.isc.org> In message , Alexander Lopez writes: > > On Mar 24, 2014, at 9:36 AM, Alexander Lopez > > wrote: > > > > > not to mention the cost in readdressing your entire network when you > > > change an upstream provider. > > > > > > Nat was a fix to a problem of lack of addresses, however, the use of > > > private address space 10/8, 192.168/16 has allowed many to enjoy a > > > simple network addressing scheme. > > > > This is easily and better solved in IPv6 using provider independent > > addressing which is readily available. > > Yes but the number of people needing just a /64 will far outnumber the > one requesting a /48. My bet is the number needing more that a single /64 will exceed the number needing just a /64. Most phones really need two /64 for tethering and currently there are lots of kludges to work around only one being available. > I would say that the majority of users today and for the future will not > require a /48, but will simply use the allocation given to them by their > upstream. > > Many today do not multi-home and how many SMB customers just use a single > Public IP behind a NAT device? How many would multi-home if it was a standard feature built into all CPE devices? Cable + DSL? Homenet is designing for all home CPE devices to support multi-homing. Plug in CPE from ISP 1 and CPE from ISP 2 and it will just work. How many don't get a realistic choice of multiple addresses? > It is easy for us on this list to use or request PIA, but what about the > 10 person office? > > It is late and I am just rambling, but even with DHCP(4and6) changing IP > networks is not a trivial thing. Not hard, but it will require a lot more > planning than what many do today of simply changing the WAN IP address > and some records in the DNS (if needed) > > > I am not saying anything that is new to members of this group, I guess I > am just venting a bit of frustration. > > > > > > > > Ipv6 requires a complete reeducation of they way we look at routing > > > and the core of the network. > > > > I wouldn't say complete, but significant. > > > > Owen > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hslabbert at stargate.ca Tue Mar 25 05:53:13 2014 From: hslabbert at stargate.ca (hslabbert at stargate.ca) Date: Mon, 24 Mar 2014 22:53:13 -0700 Subject: misunderstanding scale In-Reply-To: <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> Message-ID: <20140325055313.GC14377@stargate.ca> >I don't want to try to even think about SMTP on IPv6. Reputation of email >servers as well as the whole thought process of spam control rely on a list of >IP address. > >IPv6 adds an entirely new aspect to it. Really? It ain't that hard. Who in this list is going to set up generic PTRs for all your v6 space? Good luck shoving 2^64 addresses in a zone file, so you're doing it programmatically; quick show up of hands for anybody actually doing generic v6 PTRs? So, we're doing PTRs on an as-needed basis, e.g. router interface primary addresses (for traceroute prettiness), mail servers, etc. You try sending me email on v6 without a PTR, you're going to have to make a pretty damned convincing case for why I should accept mail from you. If you want to do address-based reputations for v6 similar to v4, my guess is that it will start to aggregate to at least the /64 boundary (i.e. if you have a spambot in your /64, that block starts to get a bad reputation and any other hosts in that block are less likely to have their mail accepted). So, there's risk of collateral damage, but no more (and probably less) than the v4 equivalent where any hosts sitting NAT'd behind a single IP are blacklisted. In this v6 equivalent, you could probably even get away with whitelisting a single, trusted IP in that /64 while the remainder of the /64 has a bad rep. If you mean that e.g. you have a spambot that's using SLAAC and so can/will bounce around to different GUAs all over the place and so get around blacklisting, I would venture aggregating at the /64 level should take care of that; each additional IP within that block that's found to be spamming adds another hit to the block's reputation. IP addresses and sender reputation do form a part of spam identification, but TBH so far I'm only seeing ways in which GUA helps *improve* the granularity at which those tools can be applied in order to reduce false positives. Granted, I haven't yet considered IP-based RBLs in v6 extensively, so I'm open to insights on this. -- Hugo On 2014-03-25, Alexander Lopez wrote: > > >> -----Original Message----- >> From: Naslund, Steve [mailto:SNaslund at medline.com] >> Sent: Monday, March 24, 2014 10:48 PM >> To: Owen DeLong; mark.tinka at seacom.mu >> Cc: nanog at nanog.org >> Subject: RE: misunderstanding scale >> >> Look at it this way. If I see an attack coming from behind your NAT, I'm gonna >> deny all traffic coming from your NAT block until you assure me you have it >> fixed because I have no way of knowing which host it is coming from. Now >> your whole network is unreachable. If you have a compromised GUA host I >> can block only him. Better for both of us, no? > >That is assuming that the infected piece does not request another address in the /64, and that the person blocking at the target end blocks a /128 instead of the /64. > >> >> How about a single host spamming behind your NAT blocking your entire >> corporate public network from email services? Anyone ever see that one. >> Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to deal >> with that. > >I don't want to try to even think about SMTP on IPv6. Reputation of email servers as well as the whole thought process of spam control rely on a list of IP address. > >IPv6 adds an entirely new aspect to it. > >> >> Maybe GUAs will convince (scare) more enterprise users to actually treat the >> internal network as an environment that needs to be secured as well. We >> can only hope. >> >Most enterprise admins, segment their BYOD (wifi) network from the production network. Some will even use a different WAN ip for the wifi network or in the minimum block outbound request to well known services ports. > >I generally see where the only outbound connections allowed are http and https. All other ports are blocked. > >> Steven Naslund >> >> >> >>Bzzzt... But thanks for playing. >> >> >>An IPv6 host with a GUA behind a stateful firewall with default deny is >> every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 >> gateway. > >I can't argue there..... > > >> >> >>Owen >> >> > > From owen at delong.com Tue Mar 25 06:02:16 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 23:02:16 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <8B8CEC40-1143-435C-A4C7-AE4DCF6396B6@delong.com> Message-ID: <7B6AF6E9-905A-4D14-B54F-8F244AFCFCEE@delong.com> On Mar 24, 2014, at 8:52 PM, George Herbert wrote: > > > > On Mon, Mar 24, 2014 at 8:02 PM, Owen DeLong wrote: > > On Mar 24, 2014, at 9:21 AM, William Herrin wrote: > > > On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve wrote: > >> I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. > > > > Hi Steve, > > > > It is your privilege to believe this and to practice it in the > > networks you operate. > > > > Many of the folks you would have deploy IPv6 do not agree. They take > > comfort in the mathematical impossibility of addressing an internal > > host from an outside packet that is not part of an ongoing session. > > These folks find that address-overloaded NAT provides a valuable > > additional layer of security. > > Which impossibility has been disproven multiple times. > > > Some folks WANT to segregate their networks from the Internet via a > > general-protocol transparent proxy. They've had this capability with > > IPv4 for 20 years. IPv6 poorly addresses their requirement. > > Actually, there are multiple implementations of transparent proxies available > for IPv6. NAT isn?t the same thing at all. > > If you want to make your life difficult in IPv6, you can. Nobody prevents you from > doing so. It is discouraged and non-sensical, but quite possible at this point. > > Owen > > > > Right. fc00::/7 exists. If you want to emulate your internal use of 10.0.0.0/8 plus NAT (or, proxies or load balancers or whatever) in your IPv6 implementation go ahead. Putting in some robust filtering that if the fc00::/7 ever appears outside the internal gateway the traffic goes poof should be as easy as the equivalents for 10, 172.16, 192.168 ? More accurately fd00::/8. fc00::/8 was reserved for ULA coordinated which failed to gain consensus. While IETF did set aside the /7, only fd00::/8 has a legitimate documented purpose. Owen From marka at isc.org Tue Mar 25 06:10:57 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Mar 2014 17:10:57 +1100 Subject: misunderstanding scale In-Reply-To: Your message of "Mon, 24 Mar 2014 23:02:16 -0700." <7B6AF6E9-905A-4D14-B54F-8F244AFCFCEE@delong.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <8B8CEC40-1143-435C-A4C7-AE4DCF6396B6@delong.com> <7B6AF6E9-905A-4D14-B54F-8F244AFCFCEE@delong.com> Message-ID: <20140325061057.9552911C73C3@rock.dv.isc.org> In message <7B6AF6E9-905A-4D14-B54F-8F244AFCFCEE at delong.com>, Owen DeLong write s: > > On Mar 24, 2014, at 8:52 PM, George Herbert > wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 8:02 PM, Owen DeLong wrote: > > > > On Mar 24, 2014, at 9:21 AM, William Herrin wrote: > > > > > On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve > wrote: > > >> I am not sure I agree with the basic premise here. NAT or Private > > >> addressing does not equal security. > > > > > > Hi Steve, > > > > > > It is your privilege to believe this and to practice it in the > > > networks you operate. > > > > > > Many of the folks you would have deploy IPv6 do not agree. They take > > > comfort in the mathematical impossibility of addressing an internal > > > host from an outside packet that is not part of an ongoing session. > > > These folks find that address-overloaded NAT provides a valuable > > > additional layer of security. > > > > Which impossibility has been disproven multiple times. > > > > > Some folks WANT to segregate their networks from the Internet via a > > > general-protocol transparent proxy. They've had this capability with > > > IPv4 for 20 years. IPv6 poorly addresses their requirement. > > > > Actually, there are multiple implementations of transparent proxies > > available for IPv6. NAT isn't the same thing at all. > > > > If you want to make your life difficult in IPv6, you can. Nobody > > prevents you from doing so. It is discouraged and non-sensical, > > but quite possible at this point. > > > > Owen > > > > > > > > Right. fc00::/7 exists. If you want to emulate your internal use of > > 10.0.0.0/8 plus NAT (or, proxies or load balancers or whatever) in your > > IPv6 implementation go ahead. Putting in some robust filtering that if > > the fc00::/7 ever appears outside the internal gateway the traffic goes > > poof should be as easy as the equivalents for 10, 172.16, 192.168 ... > > > More accurately fd00::/8. fc00::/8 was reserved for ULA coordinated which > failed to gain consensus. While IETF did set aside the /7, only fd00::/8 > has a legitimate documented purpose. And if you are going to filter fc00::/7 is more future proof. > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Tue Mar 25 06:32:11 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Mar 2014 23:32:11 -0700 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com>, <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> Message-ID: <33C107DD-F6F6-460E-A23A-F2C256D74848@delong.com> On Mar 24, 2014, at 10:12 PM, Alexander Lopez wrote: >> On Mar 24, 2014, at 9:36 AM, Alexander Lopez >> wrote: >> >>> not to mention the cost in readdressing your entire network when you >> change an upstream provider. >>> >>> Nat was a fix to a problem of lack of addresses, however, the use of >> private address space 10/8, 192.168/16 has allowed many to enjoy a simple >> network addressing scheme. >> >> This is easily and better solved in IPv6 using provider independent addressing >> which is readily available. > > Yes but the number of people needing just a /64 will far outnumber the one requesting a /48. Businesses? I doubt it. > I would say that the majority of users today and for the future will not require a /48, but will simply use the allocation given to them by their upstream. Perhaps, but I don?t see that being just one subnet for anyone at all likely to have a concern about renumbering. > Many today do not multi-home and how many SMB customers just use a single Public IP behind a NAT device? Those wouldn?t really have a problem renumbering their network. > It is easy for us on this list to use or request PIA, but what about the 10 person office? I?ve done so for several. It?s not hard or expensive. Owen From randy at psg.com Tue Mar 25 06:46:03 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 15:46:03 +0900 Subject: arin representation In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542263E@MUNPRDMBXA1.medline.com> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> <0F69D091-BE68-4A69-8BD5-7E295F0AC27A@arin.net> <9578293AE169674F9A048B2BC9A081B4B542263E@MUNPRDMBXA1.medline.com> Message-ID: > I am not sure I understand the argument here. If you think that ARIN > is not representing the address space holders in proper fashion, how > would we suggest correcting that? i have made off the cuff suggestions. but seriously, i would seek real external governance counsel. > If an address holder does not become a member (which is fairly easy to > do if you care enough) how would we even know what their concerns or > feelings are? read my lips > the number of /24s is not proportional to the total number of members which is why i asked both questions > Given that the US Gov't holds a vast amount of the legacy space skews > the results a lot. They might or might not be a "member" but they > certainly hold a lot of influence in ARINs operation as the one who > controls the contract. If ARIN was to cross them the wrong way, they > might not be holding that contract very long. there is no such contract. arin is not the icann or iana. randy From nanog+mailinglists at paul.ca Tue Mar 25 07:20:24 2014 From: nanog+mailinglists at paul.ca (Paul Andersen) Date: Tue, 25 Mar 2014 15:20:24 +0800 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: Randy, Thanks for giving me a lead in! ARIN has been gradually evolving and tweaking the governance over the past fifteen years. Given it?s a small board it?s been generally done at the full Board historically. We?ve recently started to take a long look at a variety of issues to see if there is a better way to structure ourselves to deliver the mission and stay accountable to the community. We do have a small sub-set working given there is a lot of things to go through and I am leading the charge on that issue for the ARIN Board. Over the coming months we'll be more formally looking for community input on a variety of governance and accountability issues. In the interim we're happy to take any informal input directly. The specific point you mention in regards to term limits has been taken out of context in that the thought was that as part of a larger process we should likely go ask our various communities their thoughts on this and other issues which seems to be in line with what your asking. And no - not embarrassed? However the always colourful feedback is appreciated and will be taken into account. Cheers, -p ? Paul Andersen EGATE Networks Inc. e: paul at egate.net On Mar 25, 2014, at 1:23 PM, Randy Bush wrote: > omg! a friend just sent this great example of how far down we have gone > > https://www.arin.net/about_us/committeecharters.html#governance > > there is a governance committee. guess the composition. "The Committee > shall consist of three elected members from the Board of Trustees." how > wonderfully corrupt. > > and this is the self same board which could not agree to limit their own > terms, . "The Board > discussed term limits for its members and members of the ARIN AC. No > consensus was reached." > > my youngest granddaughter's kindergarten has better governance. > > and they're not even embarrassed. sheesh! > > From nanog+mailinglists at paul.ca Tue Mar 25 07:21:01 2014 From: nanog+mailinglists at paul.ca (Paul Andersen) Date: Tue, 25 Mar 2014 15:21:01 +0800 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: Randy, Thanks for giving me a lead in! ARIN has been gradually evolving and tweaking the governance over the past fifteen years. Given it?s a small board it?s been generally done at the full Board historically. We?ve recently started to take a long look at a variety of issues to see if there is a better way to structure ourselves to deliver the mission and stay accountable to the community. We do have a small sub-set working given there is a lot of things to go through and I am leading the charge on that issue for the ARIN Board. Over the coming months we'll be more formally looking for community input on a variety of governance and accountability issues. In the interim we're happy to take any informal input directly. The specific point you mention in regards to term limits has been taken out of context in that the thought was that as part of a larger process we should likely go ask our various communities their thoughts on this and other issues which seems to be in line with what your asking. And no - not embarrassed? However the always colourful feedback is appreciated and will be taken into account. Cheers, -p ? Paul Andersen EGATE Networks Inc. e: paul at egate.net On Mar 25, 2014, at 1:23 PM, Randy Bush wrote: > omg! a friend just sent this great example of how far down we have gone > > https://www.arin.net/about_us/committeecharters.html#governance > > there is a governance committee. guess the composition. "The Committee > shall consist of three elected members from the Board of Trustees." how > wonderfully corrupt. > > and this is the self same board which could not agree to limit their own > terms, . "The Board > discussed term limits for its members and members of the ARIN AC. No > consensus was reached." > > my youngest granddaughter's kindergarten has better governance. > > and they're not even embarrassed. sheesh! > > From jcurran at arin.net Tue Mar 25 07:25:42 2014 From: jcurran at arin.net (John Curran) Date: Tue, 25 Mar 2014 07:25:42 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: On Mar 25, 2014, at 1:07 PM, Randy Bush wrote: > ok, let me also try to be constructive. how the heck do we get > ourselves out of a hole where we are ruled by self-perptuating > monopolies which lack oversight and accountability. and it ain't > just arin. look at the big [cc]tlds, the horror of icann, ... Randy - The ARIN Board has a governance committee, and so I'll leave responding to your ARIN specific governance points to the Chair of that committee (Paul Andersen)... With respect to entire Internet name and number ecosystem, I do not agree with the characterization that "... we are ruled by self-perptuating monopolies which lack oversight and accountability", but also in the spirit of being constructive, let me agree that: 1) It is a very strange family of organizations with rather uneven governance practices. 2) There is a real risk that one or more of these organizations could evolve into "self-perptuating monopolies which lack oversight and accountability", and this risk is definitely worthy of folks attention considering NTIA's IANA announcement. In particular, it would be wise idea to folks to think about the what should be the underlying principles for the governance of all of these organizations... The IANA transition announcement that I forwarded earlier is about building a plan which meets the NTIA's requirements for transiting its oversight role - "... NTIA has communicated to ICANN that the transition proposal must have broad community support and address the following four principles: ? Support and enhance the multistakeholder model; ? Maintain the security, stability, and resiliency of the Internet DNS; ? Meet the needs and expectation of the global customers and partners of the IANA services; and, ? Maintain the openness of the Internet." That third requirement (meet the needs and expectations of the global customers) is going to be hard to satisfy without really good governance practices - it would be good if folks who feel like you do take a moment to remind NTIA what exactly you think good governance practices are; paraphrasing your points, that might be elements such as: - Simple terms and conditions for contracts with registries - Membership organizations for registries with term limits for Board and advisory bodies - Board diversity (meaning real world users) - Competitive registries - ... There will shortly be a process to share such input into the transition plan; I will make sure its well known on this list and the ARIN lists. Folks should begin thinking so that they can provide insight into what they expect from the Internet name and number registry system as conditions necessary for USG/NTIA to effect a transition of its stewardship role to these organizations collectively. Thanks! /John John Curran President and CEO ARIN From randy at psg.com Tue Mar 25 08:52:00 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 17:52:00 +0900 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: paul, > ARIN has been gradually evolving and tweaking the governance over the > past fifteen years. and there has been microscopic change > Given it?s a small board it?s been generally done at the full Board > historically. i think there is some idiom about the fox guarding the hen house. it should be done by a group of grownups from the outside. a subcommittee of the current governance discussing change in governance would be a great joke if you did not seem to take it seriously. > We?ve recently started to take a long look at a variety of issues to > see if there is a better way to structure ourselves to deliver the > mission and stay accountable to the community. s/stay/become/ 83% of the community is not even in the room! and that is only considering address holders as the community. we are actually responsible to a much larger society. when we were forming arin, then then chair of the fcc explained to me why the fcc had commissioners who were from the general consumer public. i tried to get a librarian and a 15 year old with a modem on the original icann board, but no one took me seriously. > We do have a small sub-set working given there is a lot of things to > go through and I am leading the charge on that issue for the ARIN > Board. once upon a time early in the icann debacle, i was dragged on to some high-falootin' committee. at a meeting (in sjc, i think), an outspoken audience member asked what the hell i was doing on the committee. i got out of my chair and asked him to please take it and replace me. it had the added feature of getting me out of that committee. :) now, i have zero desire to be on the arin board again. but you and the self appointed internal governance committee need to get out of your chairs. we need real governance folk to form a group to figure out how the heck to get out of the mud. i did not mention susan crawford idly. outsiders! and, btw, it's not just arin. in general, our internet administrative groups have classic but quite astonishing governance processes. while icann is quite competitive, arin does kinda take the cake. randy From randy at psg.com Tue Mar 25 09:04:09 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 18:04:09 +0900 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: > I do not agree with the characterization that "... we are ruled by > self-perptuating monopolies which lack oversight and accountability", when you have a governance committee which is composed of the governing, not outsiders and governance experts, with no term limits, it would seem hard to support that argument. > - Simple terms and conditions for contracts with registries > - Membership organizations for registries with term limits > for Board and advisory bodies > - Board diversity (meaning real world users) > - Competitive registries > - ... i pretty much agree that arin should do these. except ... iff we could get reasonable governance, i am not sure we need multiple rirs. after all, the registries were just supposed to be bookkeepers. but i agree that competition is a good method of injecting some reality into the physics in the absense of other means. but i eagerly await the simplification of arin's ts&cs. and get rid of being able to change them unilateraly and arbitrarily, and get rid the silly game about legacy rights, and a whole bunch of us might join. randy From jcurran at arin.net Tue Mar 25 10:03:39 2014 From: jcurran at arin.net (John Curran) Date: Tue, 25 Mar 2014 10:03:39 +0000 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: <492E412F-FDB3-41DB-8323-0EE1159BEABC@arin.net> On Mar 25, 2014, at 5:04 PM, Randy Bush wrote: >> I do not agree with the characterization that "... we are ruled by >> self-perptuating monopolies which lack oversight and accountability", > > when you have a governance committee which is composed of the governing, > not outsiders and governance experts, with no term limits, it would seem > hard to support that argument. Acknowledged, and I will provide that feedback to the Board. I have nothing against term limits (but I also did not champion them back when I was an elected member of the Board of Trustees.) Many cite risk of losing well-qualified and experienced Board members right when they are most productive as the counter-argument. This is probably a fairly prolonged discussion, and the ARIN membership also needs to weigh in... >> - Simple terms and conditions for contracts with registries >> - Membership organizations for registries with term limits >> for Board and advisory bodies >> - Board diversity (meaning real world users) >> - Competitive registries >> - ... > > i pretty much agree that arin should do these. except ... > > iff we could get reasonable governance, i am not sure we need multiple > rirs. after all, the registries were just supposed to be bookkeepers. > but i agree that competition is a good method of injecting some reality > into the physics in the absense of other means. > > but i eagerly await the simplification of arin's ts&cs. and get rid of > being able to change them unilateraly and arbitrarily, and get rid the > silly game about legacy rights, and a whole bunch of us might join. I will note that this discussion is presently on nanog, and I am not certain that all of the ARIN Board members subscribe... I will forward your message to the Board, but would you prefer to take this to one of the ARIN lists, or have a us setup a distinct list for this purpose, or something else? Thanks! /John John Curran President and CEO ARIN From randy at psg.com Tue Mar 25 10:35:53 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 19:35:53 +0900 Subject: arin representation In-Reply-To: <492E412F-FDB3-41DB-8323-0EE1159BEABC@arin.net> References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> <492E412F-FDB3-41DB-8323-0EE1159BEABC@arin.net> Message-ID: [ you're cheating, you're in an asian time zone! ] > I have nothing against term limits (but I also did not champion them back > when I was an elected member of the Board of Trustees.) Many cite risk > of losing well-qualified and experienced Board members right when they > are most productive as the counter-argument. that is always the argument. the benefits of openness and new blood far outweigh the 'benefit' of rule by old dogs who appoint committees of themselves. > I will note that this discussion is presently on nanog, and I am not > certain that all of the ARIN Board members subscribe. an interesting point in itself, as north american operators are the smallest description of the arin constituency. a new ietf ops area director once asked me to monitor the nanog list for them and tell them if anything passed that was important. i told them that they should resign immediately. > I will forward your message to the Board thanks > but would you prefer to take this to one of the ARIN lists my experience is that ppml, the only one i remember, is far too toxic for me to last more than a day. and this is about the whole bleeping internet community. arin is far too closed and inward facing, breathing its own smoke. > or have a us setup a distinct list for this purpose, or something > else? how about forming an *outside* arin governance brainstorming committee? not binding. but a fresh, outside, wide-ranging, expert view. as i just said to someone privately, scan the entire array of internet administrative/infrastructural organizations. show me one that has a good, responsive, representative, open, ... governance structure. the ietf is interesting except it's a technocratic meritocracy. and i certainly would not call its governance open. i would make it clear that things such as policy, personalities, ... are out of scope. and i would beg to get some heavy hitters to help, which is why i keep plugging susan crawford as an example. there are others. i'd also suggest one non-board insider such as cja, so that questions about internals can be answered. yes, opening up the game is scary. it darned well should be. it could change the status quo. but that might be good for arin, good for the community, and good for the internet. randy From trejrco at gmail.com Tue Mar 25 11:43:56 2014 From: trejrco at gmail.com (TJ) Date: Tue, 25 Mar 2014 07:43:56 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> References: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> Message-ID: On Mon, Mar 24, 2014 at 9:12 PM, Bob Evans wrote: > > Thus far, IPv6 has been the "Field of Dreams" .... those of us who have > built it, we know they have not yet come (the IPv6 customers). That's > all this discussion is really about is "when will they come". > > I know the core of the Internet will be IPv4 for many years. All one has > to do is talk to a few customer to find out that they are in no hurry. > It's a no-brainer, because , none of us charges a customer more than than > lunch money for an IPv4 address. > > While I will agree that it has taken longer than some of us thought / expected I don't believe you can say no-one is coming. My home (Comcast) & my phone (T-Mo) get native IPv6, automatically, no extra charge - no special request - no special equipment. Our "4g" hotspots are all dual-stack. We recently got a new Verizon (landline) circuit for a job-site - came with a /48 automatically. The carriers drive this part of the boat - and some of them are doing so quite nicely (finally). Not all, but some of the biggest have done the most work == more eyeballs. The content side is doing better as well; again - not all, but the big ones are good wins. The customers, the normal people that is, don't know or care. We know that. On the "enterprise side" there is of course the cost & burden of dealing with the "legacy" network that still, largely, works as they expect. And in the govt it is even worse, despite some "mandates" to the contrary. But that too will shift over time - and needn't hold up anyone else's plans. And when people who do care have IPv6 at home/on their phone they will start to push that into said enterprises ... like I am doing :). /TJ From mysidia at gmail.com Tue Mar 25 13:00:08 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Mar 2014 08:00:08 -0500 Subject: misunderstanding scale In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> Message-ID: On Sun, Mar 23, 2014 at 10:07 PM, Naslund, Steve wrote: > As far as printers being a more dangerous attack vector than computers, I > definitely don't buy that argument. It does not change in v4 or v6. Printers are not merely "attack vectors"; they are targets. It only makes sense to describe them solely as potential vectors, if the printer is connected to the LAN the real target is connected to. In which situation: they are equally dangerous. But: there are more hackers that can leverage a computer using generic scripts than can mess with a vulnerable printer, using specialized attacks. Assuming that both stacks are vulnerable to attack I would be less worried > about the printer because I am not aware of any of my printers running > malware in v4. I think the PC platform being much more This is what makes printers more dangerous. Users have no idea what code is running on their printer. It is the perfect place for an attacker to patch the firmware: hole up, and setup their backdoor VPN, proxy, or tunnel, because it's on 24x7 -- rarely replaced, almost never updated --- no antimalware software. > complex and having many more interfaces for active programming like DLLs, > Java, ActiveX, etc, are much more the threat. I personally have The complexity of the available middleware and 3rd party APIs has little to do with what kinds of attacks can be launched from a compromised printer being used to stage attacks; once the device is compromised, the intruder will bring the minimal software they need. You're talking about APIs that greatly expand the attack surface of some computer software. But it does not matter; if the socket protocol used by the printer was not designed with security in mind. One good vulnerability is enough. More known vulnerabilities doesn't make it more dangerous after it is compromised, it just makes it that much more impossible to harden. With the printer --- there is little attention to vulnerabilities, so chances are patches are not even available. > not seen a DDoS attack launched by printers (they may exist but I am You haven't seen any chargen or snmp activity at all?? DDoS reflection using clumsy appliance defaults is among the most popular attacks to be facilitated by printers. > not aware of them). If I was going to design an attack for a printer, I > would think that data theft would be the most dangerous. I have The most likely use of compromising a printer (following DDoS -- which doesn't require breaking in) is to provide a covert backdoor for staging further compromise attempts or man-in-the-middle attacks. The computer has more data storage, so it is privvy to more confidential information and contents of network traffic from the computer is likely to be the ultimate target. But it just takes one Man-in-the-middle against a LAN computer, with malware covertly injected to a webpage, for a compromised printer to breach a computer. > wondered about multifunction printers emailing print data to someone but I > have never seen that yet. > Maybe. Is an intruder going to go through the trouble to compromise a printer -- just to misdirect printouts? Probably not. But this requires profiling the intruder versus information at risk -- They want computing power, banking information, SSNs: usernames/passwords. Typically stuff you will never find on printouts --- particularly within an org whose staff are aware that documents sent to network printers go over the LAN unencrypted, and therefore: your printouts should never contain that kind of information. > Steven Naslund > Chicago IL > From Lee at asgard.org Tue Mar 25 13:36:36 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 25 Mar 2014 09:36:36 -0400 Subject: misunderstanding scale In-Reply-To: References: <201403241325.s2ODPg35059533@aurora.sol.net> Message-ID: On 3/24/14 2:38 PM, "William Herrin" wrote: >On Mon, Mar 24, 2014 at 2:23 PM, Lee Howard wrote: >> On 3/24/14 1:37 PM, "William Herrin" wrote: >>>That would be one of those "details" on which smart people disagree. >>>In this case, I think you're wrong. Modern NAT superseded the >>>transparent proxies and bastion hosts of the '90s because it does the >>>same security job a little more smoothly. And proxies WERE designed to >>>act as a security feature. >> >> What kinds of devices are we talking about here? Are we talking about >>the >> default NAT on a home network router, or an enterprise-level NAT >>operating >> on a firewall? > >Hi Lee, > >I don't see NAT as a deployment issue for residential networks. Most >folks just hook their computer up to whatever CPE the vendor sends >them without any further attention. > > >> If we're talking about an enterprise firewall, then I don't >> understand--we're talking about a firewall. If it implements a >>symmetric >> NAT in addition to a stateful firewall, then it's implementing the same >> function twice. But, hey, it's your network, if >> security-through-obscurity is one of your defense in depth layers, >>that's >> fine. > >"Obscurity" offers one or more defense layers. If you disagree, post >your passwords here. One that is largely mocked by security professionals. However, ULA can do this. > >Unaddressibility is a second defense layer. I offered ULA+NPT66. I don't recommend it, but it has been described as working, and provides addresses which are not globally reachable. > >Stateful firewalling is a third. We agree. Lee From Valdis.Kletnieks at vt.edu Tue Mar 25 13:52:01 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Mar 2014 09:52:01 -0400 Subject: misunderstanding scale In-Reply-To: Your message of "Tue, 25 Mar 2014 16:31:17 +1100." <20140325053117.9A41011C5724@rock.dv.isc.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com>, <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> <20140325053117.9A41011C5724@rock.dv.isc.org> Message-ID: <41184.1395755521@turing-police.cc.vt.edu> On Tue, 25 Mar 2014 16:31:17 +1100, Mark Andrews said: > My bet is the number needing more that a single /64 will exceed the number > needing just a /64. Most phones really need two /64 for tethering and > currently there are lots of kludges to work around only one being available. As a data point, cerowrt (an openwrt fork) will ask upstream for a /60 or /56 via dhcp-pd, and then burn a /64 for each logical subnet. On a WNDR3800, it can burn 9 /64s out of the box, and more if you start doing VLAN stuff... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Lee at asgard.org Tue Mar 25 13:55:21 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 25 Mar 2014 09:55:21 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> References: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> Message-ID: On 3/24/14 9:12 PM, "Bob Evans" wrote: > >I agree with "one" thing herein.... > >> In order for IPv6 to truly work, everyone needs to be moving towards >>IPv6. > >Yep, chicken and the egg. I agree. We built an IPv6 "native" network - no >tunneling - no customers to speak of ... didn't even bother to start IPv6 >peering on it. How would there be traffic if you have no peering? > >An there you have it, how much is someone willing to pay for space in the >Internet casino. Well, it's much more than free and probably close to the >dollar level in the presentation by Lee Howard at an ARIN meeting (I think >it was in Barbados or maybe I have that meeting place wrong and it was >NANOG) ... Well, $40/month per IP address will be the pain level for all >customers to finally cash-in the IPv4 chips and move to IPv6. I wish it was Barbados! NANOG56. http://www.nanog.org/meetings/nanog56/presentations/Wednesday/wed.general.h oward.24.wmv > >Thus far, IPv6 has been the "Field of Dreams" .... those of us who have >built it, we know they have not yet come (the IPv6 customers). That's >all this discussion is really about is "when will they come". Some of us have quite a few IPv6 customers: http://www.worldipv6launch.org/measurements/ And we see significant traffic from those users. :-) > >I know the core of the Internet will be IPv4 for many years. All one has >to do is talk to a few customer to find out that they are in no hurry. >It's a no-brainer, because , none of us charges a customer more than than >lunch money for an IPv4 address. Depends on what you mean by "core." For some values of "core," the Internet is already dual-stack. > >Now, if you tell me all the porn site owners were great net citizens, >ready to move to IPv6 and shut off IPv4 access, well then I can see things >moving along much faster. Feel free to offer them a discount for dual-stack, and a deeper discount for IPv6-only. Unfortunately, I don't know any porn site operators, so I haven't been able to have conversations with them about the economics of IPv6. Lee From Lee at asgard.org Tue Mar 25 14:02:59 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 25 Mar 2014 10:02:59 -0400 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B54225A7@MUNPRDMBXA1.medline.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <5330DE44.1020506@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B54225A7@MUNPRDMBXA1.medline.com> Message-ID: On 3/24/14 10:17 PM, "Naslund, Steve" wrote: >I can easily answer that one as a holder of v4 space at a commercial >entity. The end user does not feel any compelling reason to move to ipv6 >if they have enough v4 space. > >I can't give my employer a solid business case of why they need to make >the IPv6 transition. You may not need to yet. But it would be a good idea to know how long it would take you to deploy IPv6. Then think about when IPv6 will be cheaper than IPv4. (See the poll from NANOG60 for what others think about this: http://www.wleecoyote.com/blog/lightningpoll.htm Hint: 2017-2018) It might be a good idea to finish in time to save money. Oh, and if the enterprise cares about latency, IPv6 is better. (NANOG60: https://www.nanog.org/meetings/abstract?id=2281) >They already hold enough v4 space and are putting more and more servers >behind virtual IPs on boxes like the F5 so they are actually gaining on >the v4 space issue. They see no economic reason to add an additional >layer of complexity to their network where it is already pretty expensive >to find savvy staff. Having to find v6 savvy staff is even more >challenging. Even if the network guys are up to speed on v6 (admittedly >a lot of the junior guys are not) the server and storage guys have a hard >time wrapping their minds completely around ipv4. I bet your staff isn't savvy on lots of things they have to do. I don't know why IPv6 scares people so much. Story: "So, will you be providing training on IS-IS?" "You'll get exactly the same training you got on OSPF when you started." ". . ." Lee From Lee at asgard.org Tue Mar 25 14:05:11 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 25 Mar 2014 10:05:11 -0400 Subject: misunderstanding scale In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <20140323214550.GB29152@vacation.karoshi.com> <532F6C8E.9040705@mykolab.com> <9578293AE169674F9A048B2BC9A081B4B542184F@MUNPRDMBXA1.medline.com> <44boqytu56vgfwcy1mu10vfu.1395678995630@email.android.com> <8914278D-7490-47FF-AF84-D82CF92DB7AE@delong.com> Message-ID: > >It is late and I am just rambling, but even with DHCP(4and6) changing IP >networks is not a trivial thing. Not hard, but it will require a lot more >planning than what many do today of simply changing the WAN IP address >and some records in the DNS (if needed) We tried: http://tools.ietf.org/wg/6renum In particular, you may want to read http://tools.ietf.org/html/rfc6879 when planning and renumbering IPv6; it's intended to save you pain later. Lee From bob at FiberInternetCenter.com Tue Mar 25 14:05:46 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 25 Mar 2014 07:05:46 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: References: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> Message-ID: <63e1934fa178cd323f44911f34681039.squirrel@66.201.44.180> Bob Evans CTO > > > On 3/24/14 9:12 PM, "Bob Evans" wrote: > >> >>I agree with "one" thing herein.... >> >>> In order for IPv6 to truly work, everyone needs to be moving towards >>>IPv6. >> >>Yep, chicken and the egg. I agree. We built an IPv6 "native" network - no >>tunneling - no customers to speak of ... didn't even bother to start IPv6 >>peering on it. > > How would there be traffic if you have no peering? 4 IPv6 transits and a handful of customers. Today, we only provide fiber service to businesses. Tiny traffic - no IPv6 peering at IX locations. > > >> >>An there you have it, how much is someone willing to pay for space in the >>Internet casino. Well, it's much more than free and probably close to the >>dollar level in the presentation by Lee Howard at an ARIN meeting (I >> think >>it was in Barbados or maybe I have that meeting place wrong and it was >>NANOG) ... Well, $40/month per IP address will be the pain level for all >>customers to finally cash-in the IPv4 chips and move to IPv6. > > I wish it was Barbados! > NANOG56. > http://www.nanog.org/meetings/nanog56/presentations/Wednesday/wed.general.h > oward.24.wmv > > Thanks Lee, I was hunting for that link. > >> >>Thus far, IPv6 has been the "Field of Dreams" .... those of us who have >>built it, we know they have not yet come (the IPv6 customers). That's >>all this discussion is really about is "when will they come". > > Some of us have quite a few IPv6 customers: > http://www.worldipv6launch.org/measurements/ > And we see significant traffic from those users. :-) > Maybe my isolation in silicon valley causes me to have a different IPv6 experience. Not much IPv6 happening here. I heard Google my have topped over 2% traffic that is IPv6. Significant ? Not from where I am sitting. > >> >>I know the core of the Internet will be IPv4 for many years. All one has >>to do is talk to a few customer to find out that they are in no hurry. >>It's a no-brainer, because , none of us charges a customer more than than >>lunch money for an IPv4 address. > > Depends on what you mean by "core." For some values of "core," the > Internet is already dual-stack. > >> >>Now, if you tell me all the porn site owners were great net citizens, >>ready to move to IPv6 and shut off IPv4 access, well then I can see >> things >>moving along much faster. > > Feel free to offer them a discount for dual-stack, and a deeper discount > for IPv6-only. > Unfortunately, I don't know any porn site operators, so I haven't been > able to have conversations with them about the economics of IPv6. > We give away the IPv6 to every business on a second port - to make their life easy and encourage them to play with it. Unfortunately, few try it at all. Bob > Lee > > > From SNaslund at medline.com Tue Mar 25 14:17:28 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 25 Mar 2014 14:17:28 +0000 Subject: misunderstanding scale In-Reply-To: <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> >> >> Look at it this way. If I see an attack coming from behind your NAT, >> I'm gonna deny all traffic coming from your NAT block until you assure >> me you have it fixed because I have no way of knowing which host it is >> coming from. Now your whole network is unreachable. If you have a >> compromised GUA host I can block only him. Better for both of us, no? >That is assuming that the infected piece does not request another address in the /64, and that the person blocking at the target end blocks a /128 instead of the /64. I suppose that's possible and you could respond to that by blocking more addresses or the entire /64 if you want. The difference is that by seeing the actual address of the remote system you get to decide rather than blocking an entire corporate network. It would be trivial to program a rule that if multiple addresses in the block are offending we escalate to a bigger block. >> >> How about a single host spamming behind your NAT blocking your entire >> corporate public network from email services? Anyone ever see that one. >> Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to >> deal with that. >I don't want to try to even think about SMTP on IPv6. Reputation of email servers as well as the whole thought process of spam control rely on a list of IP address. Yes, addresses that do not accurately represent the single system causing the problem. >IPv6 adds an entirely new aspect to it. Well, if you mean the entirely new aspect is a list of hex addresses instead of dotted decimal addresses I guess so. I personally would rather have a list of actual end system addresses than a list of addresses that represent a mail server and several thousand other innocent devices behind a NAT. Might be easier to tell the system owner which system is compromised than to call a large company and tell them one of their systems is compromised. It would also be nice to be able to allow legitimate email to a business partner while blocking his compromised system only. >> >> Maybe GUAs will convince (scare) more enterprise users to actually >> treat the internal network as an environment that needs to be secured >> as well. We can only hope. >> >Most enterprise admins, segment their BYOD (wifi) network from the production network. Some will even use a different WAN ip for the wifi network or in the minimum block outbound request to well known services ports. If they knew anything about security they would but I thought we were talking about the same guys that use NAT to secure their networks. >I generally see where the only outbound connections allowed are http and https. All other ports are blocked. Maybe on the BYOD only networks but very few companies actually segregate the BYOD devices from the general wifi access in a sophisticated way. Just look at how many wifi vendors actually support that well and how many companies can actually tell a corporate owned wifi device from a BYOD device. To do that correctly requires something like a good machine certificate process and complex stuff like 802.1x and TLS, most don't have it. Good luck with allowing only http and https and nothing else. My wifi users happen to like to be able to use IP softphones, have web conferences, and do lots of other stuff that uses more than those two protocols. Steven Naslund Chicago IL From jra at baylink.com Tue Mar 25 14:34:50 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 25 Mar 2014 10:34:50 -0400 (EDT) Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B542269D@MUNPRDMBXA1.medline.com> Message-ID: <16865938.12575.1395758090936.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Steve Naslund" > You are right but that is usually how it works with fiber because that > last drop to the home is a pretty expensive piece that you don't > usually want installed until it is needed. The LECS usually don't even > light a building unless there is a service that requires it. I was > trying to make the point that $700 - 800 per premise as quoted seems > extremely low to me. The cost of the cable, splices, cases, MPOEs, and > especially labor make that number unbelievable to me. I am coming at > this as someone who was in charge of a similar project that connected > every building on US Air Force bases to a fiber backbone. An Air Force > base is very similar to a suburb in a lot of respects in terms of > density and utilities structure. I was responsible for the design, > pricing, procurement, and contractor management on that project. We > had 3,000 buildings in approximately a eight square mile area and the > total project cost was in excess of $12 million dollars which equates > to something like $4000 per building. Granted we were doing 12 strands > per building but cable costs have fallen since this project so they > should be pretty close. "Marine, Aviation, Mil-Spec, Aerospace, Man-Rated": The five most expensive adjectives in the English language, in ascending order. (When I need rule-of-thumb multipliers, I use 5, 10, 20, 400, and 5000, resp.) For the record, I don't recall whether $800 was all-in -- inclusive of all the central building equipment and labor -- or not. Time to exhume the thread from the archives. It was quite informative. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From lowen at pari.edu Tue Mar 25 14:46:17 2014 From: lowen at pari.edu (Lamar Owen) Date: Tue, 25 Mar 2014 10:46:17 -0400 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <5330DE44.1020506@mykolab.com> References: Message-ID: <533196B9.2030407@pari.edu> On 03/24/2014 09:39 PM, Paul Ferguson wrote: > I'll leave it as an exercise for the remainder of... everywhere to > figure out why there is resistance to v6 migration, and it isn't "just > because" people can't be bothered. I'm sure there are numerous enterprises in the same shape I am in, with significant equipment investment in non-quite-ipv6-ready gear, and insufficient technology refresh capex monies to get ipv6-ready capacity-equivalent replacements. Cisco 6500/7600 even with Sup720 has issues, and I know of a number of networks still running Sup2 on 6500/7600 or even older (including some gear in my own network, where I still have old gear, older even than I'm willing to admit publicly, serving in core roles; I just decommissioned a failing Extreme Summit 1i this past Saturday, and still have two more in core roles, doing Layer 3 IPv4 in one case). I know I'm not alone. While much of this gear may be fully depreciated, the cost of the forklift upgrade is major, and the gear is not the biggest part of the cost. Repairs are not anywhere near as draining on the capex budget as complete chassis upgrades are, and so we keep old gear running because it's what we can afford to do. So capex is a big part of it; but then there's training costs and the opex of dealing with a new-to-us technology. Just my very-late-to-the-party opinion, and not likely to change anything at all, but in hindsight it seems we might have been better off with ipv4.1 instead of ipv6, which, IMO, just simply bit off too much in one bite. Much like how the Fountainhead project at DG got eclipsed by the much less ambitious Eagle, and never really went anywhere due to its pie-in-the-sky goals, when all the customers really wanted was a 32-bit Eclipse, which Eagle provided. (Tracy Kidder, "The Soul of a New Machine" which should be on every tech's must-read list). Yeah, I know, too late to matter, as ipv6 is here and here to stay. But the transition could have been smoother and less traumatic to equipment vendors' customers. At least that's my opinion and experience, your mileage may vary. From Valdis.Kletnieks at vt.edu Tue Mar 25 15:41:29 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Mar 2014 11:41:29 -0400 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: Your message of "Tue, 25 Mar 2014 09:55:21 -0400." References: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> Message-ID: <3841.1395762089@turing-police.cc.vt.edu> On Tue, 25 Mar 2014 09:55:21 -0400, Lee Howard said: > Some of us have quite a few IPv6 customers: > http://www.worldipv6launch.org/measurements/ > And we see significant traffic from those users. :-) I'm actually glad to see that we're no longer on the first page of that list. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bob at FiberInternetCenter.com Tue Mar 25 16:53:09 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 25 Mar 2014 09:53:09 -0700 Subject: arin representation Message-ID: <965c5c80351802153e9cbed38e5e0d2f.squirrel@66.201.44.180> I have just as many issues getting ARIN IP space as the next guy and companies like Verizon. I do vote - yes half the time I am not sure, exactly who I am voting for from just a bio and candidate paragraph. As a result, I decided to attend ARIN meetings. I have been to about six ARIN meetings in the last 24 months. Many coordinated with NANOG events. Makes it convenient for ARIN to obtain more input. What I thought was an isolated boondoggle meeting in Barbados turned out not to be. I went to see if the discussion changed at all there or only one side was pushed by big companies that can afford a boondoggle. It didn't change. I saw representation on both sides of a discussion, sometimes they turned in to arguments. I was really surprised to see the ARIN staff work so much. I thought they would waste time enjoying the island. I was surprised that I had arrived before most of the staff. After the meeting almost everyone I knew on the staff or elected left within 24 hours. I thought that was a little to short for all the travel time and hours they put in for the meeting to take place. Like every governing body, it's easy to criticize it. However, if it were some big monopoly with giant hidden agendas accomplished behind closed doors, I wouldn't see networks like Verizon disappointed at an ARIN meeting as their perspective was being over ruled by the majority. I have seen this at a meeting when Verizon decided to go purchase IPv4 space in the marketplace as they could not obtain what they tried to justify. It would have been a huge chunk of what remained. The IPv4 marketplace grew even more that week. I like term limits for every governing body - except when it's a company I built with my money. :-) Bob Evans CTO Fiber Internet Center > On Mar 25, 2014, at 5:04 PM, Randy Bush wrote: > >>> I do not agree with the characterization that "... we are ruled by >>> self-perptuating monopolies which lack oversight and accountability", >> >> when you have a governance committee which is composed of the governing, >> not outsiders and governance experts, with no term limits, it would seem >> hard to support that argument. > > Acknowledged, and I will provide that feedback to the Board. > > I have nothing against term limits (but I also did not champion them back > when I was an elected member of the Board of Trustees.) Many cite risk > of losing well-qualified and experienced Board members right when they > are most productive as the counter-argument. This is probably a fairly > prolonged discussion, and the ARIN membership also needs to weigh in... > >>> - Simple terms and conditions for contracts with registries >>> - Membership organizations for registries with term limits >>> for Board and advisory bodies >>> - Board diversity (meaning real world users) >>> - Competitive registries >>> - ... >> >> i pretty much agree that arin should do these. except ... >> >> iff we could get reasonable governance, i am not sure we need multiple >> rirs. after all, the registries were just supposed to be bookkeepers. >> but i agree that competition is a good method of injecting some reality >> into the physics in the absense of other means. >> >> but i eagerly await the simplification of arin's ts&cs. and get rid of >> being able to change them unilateraly and arbitrarily, and get rid the >> silly game about legacy rights, and a whole bunch of us might join. > > I will note that this discussion is presently on nanog, and I am not > certain that all of the ARIN Board members subscribe... I will forward > your message to the Board, but would you prefer to take this to one of > the ARIN lists, or have a us setup a distinct list for this purpose, > or something else? > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > > From johnl at iecc.com Tue Mar 25 17:23:28 2014 From: johnl at iecc.com (John Levine) Date: 25 Mar 2014 17:23:28 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325055313.GC14377@stargate.ca> Message-ID: <20140325172328.5224.qmail@joyce.lan> >If you want to do address-based reputations for v6 similar to v4, my guess is >that it will start to aggregate to at least the /64 boundary ... It says a lot about the state of the art that people are still making uninformed guesses like this, non ironically. On the one hand /64 is too coarse, because there are hosting providers that put multiple customers in a single /64. If you filter at that granularity, you'll get a lot of false positives and collateral damage. (When asked why they did something that dumb, they've tended to blame equipment vendors.) On the other hand, /64 is much too fine. Roadrunner assigns my cable connection a /50*, so even if you're aggregating at /64, there are now 16K different incarnations of me to block, instead of the one in IPv4. Businesses typically get a /48 so they have 64K incarnations. It would be nice if there were an efficient and reliable way to ask networks what their customer suballocation size is, but there isn't, so you have to hope rwhois will work and be fast enough, or guess, often guessing wrong. There also isn't any agreed way to publish DNSBLs with variable size ranges other than rsync'ing the whole file. IANA has handed out /12s to the RIRs, so each of those is 2^52 /64s, a number that's way out in the absurd-o-sphere. Large mail providers all agree that v6 senders need to follow good mail discipline, but are far from agreeing what that means. It certainly means proper rDNS, but does it mean SPF? DKIM on all the mail? TLS on the connections? At this point, I don't know and neither does anyone else. Fortunately we have at least another decade of full IPv4 mail connectivity to figure it out. For anyone who points out that v6 mail works now, you're right, it does, but that's only because botnets don't use it yet other than occasionally by accident on dual stacked hosts so the amount of spam is much lower than on ipv4 and there isn't much address hopping. With any luck they never will, since bot mail still works OK for them on v4, but if they do, and they start doing address hopping, it'll be really ugly. R's, John * - yes, it's a /50, their rwhois says so. And I know because whenever my modem reboots, it assigns me a /64 more or less at random from that /50 even though they tell me it's supposed to keep giving me the same one. See prior comments about mostly working. From bruns at 2mbit.com Tue Mar 25 17:43:48 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 11:43:48 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325172328.5224.qmail@joyce.lan> References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <5331C054.8040801@2mbit.com> On 3/25/14, 11:23 AM, John Levine wrote: > Large mail providers all agree that v6 senders need to follow good > mail discipline, but are far from agreeing what that means. It > certainly means proper rDNS, but does it mean SPF? DKIM on all the > mail? TLS on the connections? At this point, I don't know and > neither does anyone else. Fortunately we have at least another decade > of full IPv4 mail connectivity to figure it out. So, what's everyone's feelings about a rather large provider who blocks IPv6 e-mail that has no RDNS, even though the sending domain has SPF records allowing the block, and proper DKIM set up? *looks directly at Google* Nothing like poorly thought out policy to break a rather successful IPv6 roll-out for multiple customers. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From swmike at swm.pp.se Tue Mar 25 17:51:12 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 25 Mar 2014 18:51:12 +0100 (CET) Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325172328.5224.qmail@joyce.lan> References: <20140325172328.5224.qmail@joyce.lan> Message-ID: On Tue, 25 Mar 2014, John Levine wrote: > It says a lot about the state of the art that people are still making > uninformed guesses like this, non ironically. Yep, SMTP and the whole spam fighting part of the Internet, isn't ready for IPv6. This is not IPv6 fault. I have repeatedly tried to get people interested in methods of making it possible for ISPs to publish their "per-customer" allocation size, so far without any success. Most of the time I seem to get "we did it a certain way for IPv4, it works, we don't want to change it" from people. IPv6 changes things. Lots of things. There will be a lot of work to catch up. It's too bad that the part of the ecosystem that fights spam have woken up so late. -- Mikael Abrahamsson email: swmike at swm.pp.se From jimpop at gmail.com Tue Mar 25 17:55:11 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 25 Mar 2014 13:55:11 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331C054.8040801@2mbit.com> References: <20140325172328.5224.qmail@joyce.lan> <5331C054.8040801@2mbit.com> Message-ID: On Tue, Mar 25, 2014 at 1:43 PM, Brielle Bruns wrote: > On 3/25/14, 11:23 AM, John Levine wrote: >> >> Large mail providers all agree that v6 senders need to follow good >> mail discipline, but are far from agreeing what that means. It >> certainly means proper rDNS, but does it mean SPF? DKIM on all the >> mail? TLS on the connections? At this point, I don't know and >> neither does anyone else. Fortunately we have at least another decade >> of full IPv4 mail connectivity to figure it out. > > > So, what's everyone's feelings about a rather large provider who blocks IPv6 > e-mail that has no RDNS, even though the sending domain has SPF records > allowing the block, and proper DKIM set up? > > *looks directly at Google* > > Nothing like poorly thought out policy to break a rather successful IPv6 > roll-out for multiple customers. Just an anecdotal observation.... what G appears to be doing is flagging emails, received over IPv6, that are below a certain size threshold. I have zero problems sending bulk emails (discussions lists), over IPv6, to G end users, but I do see consistent problems sending small mgmt alerts (i.e. monit/munin) over IPv6 to G. -Jim P. From johnl at iecc.com Tue Mar 25 17:56:03 2014 From: johnl at iecc.com (John Levine) Date: 25 Mar 2014 17:56:03 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331C054.8040801@2mbit.com> Message-ID: <20140325175603.5423.qmail@joyce.lan> In article <5331C054.8040801 at 2mbit.com> you write: >On 3/25/14, 11:23 AM, John Levine wrote: >> Large mail providers all agree that v6 senders need to follow good >> mail discipline, but are far from agreeing what that means. It >> certainly means proper rDNS, but does it mean SPF? DKIM on all the >> mail? TLS on the connections? At this point, I don't know and >> neither does anyone else. Fortunately we have at least another decade >> of full IPv4 mail connectivity to figure it out. > >So, what's everyone's feelings about a rather large provider who blocks >IPv6 e-mail that has no RDNS, even though the sending domain has SPF >records allowing the block, and proper DKIM set up? > >*looks directly at Google* I think this would be a good time to fix your mail server setup. You're never going to get much v6 mail delivered without rDNS, because receivers won't even look at your mail to see if it's authenticated. CenturyLink is reasonably technically clued so it shouldn't be impossible to get them to fix it. R's, John From chip at 2bithacker.net Tue Mar 25 18:16:42 2014 From: chip at 2bithacker.net (Chip Marshall) Date: Tue, 25 Mar 2014 14:16:42 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <20140325181642.GB17019@2bithacker.net> On 2014-03-25, Mikael Abrahamsson sent: > I have repeatedly tried to get people interested in methods of > making it possible for ISPs to publish their "per-customer" > allocation size, so far without any success. Most of the time I > seem to get "we did it a certain way for IPv4, it works, we > don't want to change it" from people. So it's yet another chicken-and-egg problem to add to the pile for IPv6. Mail ops don't care because IPv6 isn't here, net ops delay IPv6 because mail isn't ready for it? This seems like to sort of problem that Mailops or MAAWG should be hammering out. There's a great opportunity to get some good BCP documents out there on "Here's how to do email in IPv6" before deployment goes past the point of no return. Spamhaus has had a fair amount of success with getting ISPs to participate in things like the PBL. Why not establish something similar for allocation sizes in IPv6? -- Chip Marshall http://2bithacker.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From paul at egate.net Tue Mar 25 05:55:06 2014 From: paul at egate.net (Paul Andersen) Date: Tue, 25 Mar 2014 13:55:06 +0800 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: <164D9C8E-7D54-46A6-A228-72BD362BABDF@egate.net> Randy, Thanks for giving me a lead in! ARIN has been gradually evolving and tweaking the governance over the past fifteen years. Given it?s a small board it?s been generally done at the full Board historically. We?ve recently started to take a long look at a variety of issues to see if there is a better way to structure ourselves to deliver the mission and stay accountable to the community. We do have a small sub-set working given there is a lot of things to go through and I am leading the charge on that issue for the ARIN Board. Over the coming months we'll be more formally looking for community input on a variety of governance and accountability issues. In the interim we're happy to take any informal input directly. The specific point you mention in regards to term limits has been taken out of context in that the thought was that as part of a larger process we should likely go ask our various communities their thoughts on this and other issues which seems to be in line with what your asking. And no - not embarrassed? However the always colourful feedback is appreciated and will be taken into account. Cheers, -p On Mar 25, 2014, at 1:23 PM, Randy Bush wrote: > omg! a friend just sent this great example of how far down we have gone > > https://www.arin.net/about_us/committeecharters.html#governance > > there is a governance committee. guess the composition. "The Committee > shall consist of three elected members from the Board of Trustees." how > wonderfully corrupt. > > and this is the self same board which could not agree to limit their own > terms, < > >. "The Board > discussed term limits for its members and members of the ARIN AC. No > consensus was reached." > > my youngest granddaughter's kindergarten has better governance. > > and they're not even embarrassed. sheesh! > > randy > From akaradag at NETAS.com.tr Tue Mar 25 06:46:39 2014 From: akaradag at NETAS.com.tr (Anil KARADAG) Date: Tue, 25 Mar 2014 06:46:39 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer Message-ID: Hi, I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. thanks Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From paul at bertain.net Tue Mar 25 20:46:38 2014 From: paul at bertain.net (Paul Bertain) Date: Tue, 25 Mar 2014 13:46:38 -0700 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: Message-ID: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> Hi Anil, Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. Paul > On Mar 24, 2014, at 11:46 PM, Anil KARADAG wrote: > > Hi, > > I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. > > I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. > > thanks > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From bruns at 2mbit.com Tue Mar 25 20:57:15 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 14:57:15 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325175603.5423.qmail@joyce.lan> References: <20140325175603.5423.qmail@joyce.lan> Message-ID: <5331EDAB.8000303@2mbit.com> On 3/25/14, 11:56 AM, John Levine wrote: > I think this would be a good time to fix your mail server setup. > You're never going to get much v6 mail delivered without rDNS, because > receivers won't even look at your mail to see if it's authenticated. > > CenturyLink is reasonably technically clued so it shouldn't be > impossible to get them to fix it. Nothing wrong with my mail server setup, except the lack of RDNS. Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition. That would be like outright refusing mail unless it had both SPF and DKIM on every single message. Sure, great in theory, does not work in reality and will result in lost mail from legit sources. Already spoken to CenturyLink about RDNS for ipv6 - won't have rdns until native IPv6. Currently, IPv6 seems to be delivered for those who want it, via 6rd. And, frankly, I'm not going to get in a fight with CenturyLink over IPv6 RDNS, considering that I am thankful that they are even offering IPv6 when other large providers aren't even trying to do so to their residential and small business customers. It is very easy for some to forget that not everyone has a gigabit fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks announced over BGP. Some of us actually have to make do with (sometimes very) limited budgets and what the market is offering us and has made available. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bzs at world.std.com Tue Mar 25 20:57:48 2014 From: bzs at world.std.com (Barry Shein) Date: Tue, 25 Mar 2014 16:57:48 -0400 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: <21297.60876.738653.301480@world.std.com> Randy (et al): Included below is the response by Joe Sims (Jones Day) to Professor Froomkin's similar arguments in 1999. I include it because it's not that long but the link is: http://archive.icann.org/en/comments-mail/comment-bylaws/msg00025.html I found it interesting and very readable. Not necessarily authoritative, but interesting. If nothing else it covers much of the ground being re-hashed here and seems thoughtful even if one doesn't agree. -Barry Shein --- Professor Froomkin's literary skills are fine, but his analysis leaves a lot to be desired. Since his views might be taken by a reader who is unfamiliar with the subject as having some particular validity, given his academic credentials, it is probably necessary to provide at least some context, something that Froomkin ignores. Froomkin says that "one of the things that ICANN needs to enhance its rather tenuous legitimacy is members." This single statement reveals the "complete disconnect," to use another Froomkin phrase, between his view of what ICANN is and should be, and the real world. In the real world -- the world of the technical people who created the Internet, the infrastructure providers who make it work, the businesses (large and small) who increasingly depend on it for commercial activity, the more than one hundred million individual users who benefit from the incredible increase in access to communication and information that the Internet provides, and the national governments around the world that view this global resource as an important global asset -- in that real world, ICANN's mission is extremely limited: to maintain the stability of the DNS. Or, to put it more simply, to not screw it up. This is the prime objective, the overriding core task, the critical job. Everything else is secondary, or even lower than that, in importance and priority, and that includes anything that can remotely be described as governance. Given this real world fact, ICANN has been constructed to maximize its potential to maintain stability, and to minimize the possibility that it could do something that would increase the risk of instability. Now, of course, global and national politics, and the honest search for the broadest possible consensus of all interested stakeholders, have combined to produce an ICANN drafted by committee. As could be expected, the result is not a perfect instrument for anything, including its prime objective. But the fact that there has always been a prime objective -- and that no responsible participant in this effort has ever disagreed that this was and should be the prime objective guiding the creation of ICANN -- has allowed there to be a common definition of progress that has led to where we are. And, I might add, that has led to broad -- essentially unanimous -- support for where we are from those real world entities I listed above. None of them think we got it exactly right, but almost all of them think we got it acceptably right. The principal exception to this rule is a class of critics, of whom Froomkin is one, that believe that ICANN has been constructed with insufficient attention to the needs, desires and inputs of the little guy -- the individual user, the individual domain name holder, the small entrepreneur. They believe that, since ICANN will (they assert) have control over an important global resource, it must itself be controlled, or at least significantly influenced, by some form of global democracy -- if not one person, one vote, then as close as they can get to that. This is not a frivolous position, but it is a fundamentally wrong-headed one, because it is clearly not consistent with the principal objective of ICANN: create a vehicle for consensus development of policies that will promote the continued stable operation of the DNS. This objective requires slower, not faster, decision-making and incremental change; consideration of technical issues that are generally not accessible to the population as a whole, or even the user community as a whole; and the continued support of the business community, the infrastructure providers and other important political forces in this space. The more direct influence that the general population -- even the general user population -- is given over the actual decision-making processes of ICANN, the more risk to the prime objective of continued stability, and the more pressure there will be for the only realistic alternative: control of ICANN by some form of multi-national body, where we would likely get stability all right, but combined with more control. less freedom and less innovation. The fact that the global community of national governments has so far allowed and even encouraged this private sector approach is quite remarkable, and owes great credit to the United States government for its leadership in this regard, but this forebearance is neither pre-ordained nor guaranteed. Froomkin says that the proposed At Large Membership structure "disenfranchise[s] the public." Pardon me, but exactly when was "the public," whoever that is, in charge of the Internet? The Internet was in the beginning a US government research project, which has long since become a global resource managed and made to function in large part by volunteers, and now that it has become an increasingly important asset for commercial transactions, is financed largely by private businesses, either through the creation of infrastructure or of applications designed to make use of that infrastructure. Where exactly in this process was "the public" enfranchised? What has "the public" been voting on? And is Froomkin's "public" just the United States "public," or does it extend to a global "public." Finally, to the extent that there is or should be a "public" role in this effort, why is that not already accomplished by the extensive involvement and control by the United States and many other national governments throughout this process -- and continuing, I might add, for the foreseeable future? Where is it written that for ICANN, unlike the ITU or United Nations, for example, there needs to be direct involvement by individuals in making policy decisions, rather than have those made by representative bodies? Finally, let's deal with his specific point, such as there is one: that the proposed At Large bylaws "remove direct end-user input into the management of ICANN." If by "direct end-user" he means to exclude all those involved in the other three Supporting Organizations, and thus limit the term to individuals that have no other connection to the DNS than as an individual user of the Internet, he is correct -- and not only correct, but that is the objective of the policy that the ICANN Board adopted in Santiago that these bylaw amendments are designed to implement. Keeping in mind the prime objective of continued stability, the notion that half the ICANN Board could theoretically be elected, especially in this first election cycle when all nine will be up for election, by a determined minority -- whether commercial, religious, ethnic, regional or otherwise -- is anathema. In addition, since this particular portion of the Board is supposed to be representative -- not simply the product of who can marshall the most votes for a seat on a Board of an entity that the vast majority of the "public" that Froomkin is so worried about has never even heard about -- we have to be worried about how this clearly subsidiary goal of having a membership can be met without interfering with our basic objective. And finally, while the indirect approach that is set forth in the Board's policy that these bylaws implement does have the added benefit of eliminating the concept of derivative actions -- another potential source of instability -- that is certainly not the only reason it was adopted. Froomkin's legal work on this point is interesting, but I suspect even he would not want to guarantee that the arguments he presents will be consistently successful, or that even if they are, an organization with billions of potential members will not be constantly fighting some very small subset of them -- which could quite easily amount to many hundreds or thousands of individual matters. In the end, I guess it is easy -- and maybe desirable -- for academics to constantly seek a better world; after all, they have less real-world responsibilities and thus fewer constraints on imaginative thinking. Over time, good ideas will gain support and bad ones will not. And I would certainly not want to discourage Professor Froomkin or anyone else from continuing to advocate a change in focus or objectives for ICANN; after all, if they don't speak out for what they see as the underrepresented, who will? Maybe at some time in the future there will be a consensus for a globally-democratic ICANN, or some similar body; maybe at some point down the road the Internet will be so stable that no one will worry about that anymore. But today, at least my perspective is that almost everyone involved in this process is worried about stability, and that almost everyone wants to avoid doing things in the creation of ICANN that would risk continued stability of the DNS. Indeed, one could make a reasonable argument that, if stability is our objective, we should postpone any movement to an At Large membership or Directors until ICANN is up and running successfully; after all, we have had enough trouble getting consensus out of those who make up the Supporting Organizations -- a much more homogenous group than the population of the world. But the ICANN bylaws call for an At Large membership, and the Initial Board feels bound by that call, and so it has sought to carry out that responsibility in the best way it could -- consistent with what it (and virtually all, if not all, of the other participants) see as its principal goal of creating an organization and a structure that would enhance, not risk, the continued stability of the DNS. I think its efforts so far have the support of -- dare I say it? -- a consensus, even a strong consensus, of the Internet community, Professor Froomkin's views to the contrary notwithstanding. From fergdawgster at mykolab.com Tue Mar 25 21:12:52 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 25 Mar 2014 14:12:52 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331EDAB.8000303@2mbit.com> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> Message-ID: <5331F154.8050105@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Isn't this just a local policy issue with handling DMARC? I know for sure at least one other (very large) organization that (also) rejects messages which do not have an rDNS entry, and it is a local DMARC policy. - - ferg On 3/25/2014 1:57 PM, Brielle Bruns wrote: > On 3/25/14, 11:56 AM, John Levine wrote: >> I think this would be a good time to fix your mail server setup. >> You're never going to get much v6 mail delivered without rDNS, >> because receivers won't even look at your mail to see if it's >> authenticated. >> >> CenturyLink is reasonably technically clued so it shouldn't be >> impossible to get them to fix it. > > > Nothing wrong with my mail server setup, except the lack of RDNS. > Lacking reverse should be one of many things to consider with > rejecting e-mails, but should not be the only condition. > > That would be like outright refusing mail unless it had both SPF > and DKIM on every single message. > > Sure, great in theory, does not work in reality and will result in > lost mail from legit sources. > > Already spoken to CenturyLink about RDNS for ipv6 - won't have > rdns until native IPv6. Currently, IPv6 seems to be delivered for > those who want it, via 6rd. > > And, frankly, I'm not going to get in a fight with CenturyLink over > IPv6 RDNS, considering that I am thankful that they are even > offering IPv6 when other large providers aren't even trying to do > so to their residential and small business customers. > > It is very easy for some to forget that not everyone has a gigabit > fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks > announced over BGP. Some of us actually have to make do with > (sometimes very) limited budgets and what the market is offering us > and has made available. > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMx8VQACgkQKJasdVTchbJkBgD+PeCiFIefgXhmcsyIiqHAdiNX slrBbBk3/edq9yiAsPAA/0zwEwPqfFTyjYvChdgMyC09aSDOFeGT8vf6HZzMCPDt =OHTl -----END PGP SIGNATURE----- From LarrySheldon at cox.net Tue Mar 25 21:23:53 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 25 Mar 2014 16:23:53 -0500 Subject: arin representation In-Reply-To: References: Message-ID: <5331F3E9.6080504@cox.net> On 3/25/2014 11:53 AM, Bob Evans wrote: > I like term limits for every governing body - except when it's a company I > built with my money. :-) I have absolutely no business jumping into this discussion, but it keeps hammering on a topic that interests me in other venues: "term limits". I am opposed to them, assuming that the election process is open and honest and the voters have an opportunity to be informed. (And if it is not, THAT is what needs to be fixed.) It is my opinion that every discussion of the "need" for term limits involves a person or group of people who have these important characteristics: They propose and vote in favor of legislation or do something else the term-limiters don't like. Their constituency DOES like what they do and signal that by re-electing them. State Senator Ernie Chambers here in Nebraska should be the text-book example of the evils of term limits. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From laszlo at heliacal.net Tue Mar 25 21:33:41 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 25 Mar 2014 21:33:41 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331EDAB.8000303@2mbit.com> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> Message-ID: <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> The usefulness of reverse DNS in IPv6 is dubious. Maybe the idea is to cause enough pain that eventually you fold and get them to host your email too. -Laszlo On Mar 25, 2014, at 8:57 PM, Brielle Bruns wrote: > On 3/25/14, 11:56 AM, John Levine wrote: >> I think this would be a good time to fix your mail server setup. >> You're never going to get much v6 mail delivered without rDNS, because >> receivers won't even look at your mail to see if it's authenticated. >> >> CenturyLink is reasonably technically clued so it shouldn't be >> impossible to get them to fix it. > > > Nothing wrong with my mail server setup, except the lack of RDNS. Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition. > > That would be like outright refusing mail unless it had both SPF and DKIM on every single message. > > Sure, great in theory, does not work in reality and will result in lost mail from legit sources. > > Already spoken to CenturyLink about RDNS for ipv6 - won't have rdns until native IPv6. Currently, IPv6 seems to be delivered for those who want it, via 6rd. > > And, frankly, I'm not going to get in a fight with CenturyLink over IPv6 RDNS, considering that I am thankful that they are even offering IPv6 when other large providers aren't even trying to do so to their residential and small business customers. > > It is very easy for some to forget that not everyone has a gigabit fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks announced over BGP. Some of us actually have to make do with (sometimes very) limited budgets and what the market is offering us and has made available. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From zwicky at yahoo-inc.com Tue Mar 25 21:38:19 2014 From: zwicky at yahoo-inc.com (Elizabeth Zwicky) Date: Tue, 25 Mar 2014 21:38:19 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331F154.8050105@mykolab.com> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <5331F154.8050105@mykolab.com> Message-ID: DMARC says nothing about rDNS, and given how late in the game DMARC comes, it seems like an odd place to enforce rDNS. Local policy, sure; local DMARC policy, wait what? Elizabeth On 3/25/14, 2:12 PM, "Paul Ferguson" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Isn't this just a local policy issue with handling DMARC? I know for >sure at least one other (very large) organization that (also) rejects >messages which do not have an rDNS entry, and it is a local DMARC policy. > >- - ferg > >On 3/25/2014 1:57 PM, Brielle Bruns wrote: > >> On 3/25/14, 11:56 AM, John Levine wrote: >>> I think this would be a good time to fix your mail server setup. >>> You're never going to get much v6 mail delivered without rDNS, >>> because receivers won't even look at your mail to see if it's >>> authenticated. >>> >>> CenturyLink is reasonably technically clued so it shouldn't be >>> impossible to get them to fix it. >> >> >> Nothing wrong with my mail server setup, except the lack of RDNS. >> Lacking reverse should be one of many things to consider with >> rejecting e-mails, but should not be the only condition. >> >> That would be like outright refusing mail unless it had both SPF >> and DKIM on every single message. >> >> Sure, great in theory, does not work in reality and will result in >> lost mail from legit sources. >> >> Already spoken to CenturyLink about RDNS for ipv6 - won't have >> rdns until native IPv6. Currently, IPv6 seems to be delivered for >> those who want it, via 6rd. >> >> And, frankly, I'm not going to get in a fight with CenturyLink over >> IPv6 RDNS, considering that I am thankful that they are even >> offering IPv6 when other large providers aren't even trying to do >> so to their residential and small business customers. >> >> It is very easy for some to forget that not everyone has a gigabit >> fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks >> announced over BGP. Some of us actually have to make do with >> (sometimes very) limited budgets and what the market is offering us >> and has made available. >> >> > > >- -- >Paul Ferguson >VP Threat Intelligence, IID >PGP Public Key ID: 0x54DC85B2 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.22 (MingW32) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iF4EAREIAAYFAlMx8VQACgkQKJasdVTchbJkBgD+PeCiFIefgXhmcsyIiqHAdiNX >slrBbBk3/edq9yiAsPAA/0zwEwPqfFTyjYvChdgMyC09aSDOFeGT8vf6HZzMCPDt >=OHTl >-----END PGP SIGNATURE----- > From jimpop at gmail.com Tue Mar 25 21:39:48 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 25 Mar 2014 17:39:48 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> Message-ID: On Tue, Mar 25, 2014 at 5:33 PM, Laszlo Hanyecz wrote: > The usefulness of reverse DNS in IPv6 is dubious. Maybe the idea is to > cause enough pain that eventually you fold and get them to host your email too. Heh, I say the same things about DMARC where a lot of the major proponents offer alternative messaging capabilities. -Jim P. From bruns at 2mbit.com Tue Mar 25 22:06:54 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 16:06:54 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> Message-ID: <5331FDFE.8060209@2mbit.com> On 3/25/14, 3:33 PM, Laszlo Hanyecz wrote: > The usefulness of reverse DNS in IPv6 is dubious. Maybe the idea is > to cause enough pain that eventually you fold and get them to host > your email too. Well, like I said, there is nothing wrong with using rdns as part of a score in how legit a message is. Knock off a point or two in Spamassassin, add a few points back because there is SPF records, and another one or two for DKIM... Google is obviously doing some intelligent filtering on their end to handle incoming spam - why take such a drastic move against rdns when you already do heuristics that can factor it in without risking losing legit mail? I just finished moving two customers from Google hosted mail to Office 365 hosted Exchange. Even with all the odd quirks and issues that 365 has from time to time, I'm still getting better feedback from my customers. So... no, I'd sooner shut down my mail services then go with Google mail hosting for my primary e-mail address. But, that's just my opinion. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From johnl at iecc.com Tue Mar 25 22:17:29 2014 From: johnl at iecc.com (John Levine) Date: 25 Mar 2014 22:17:29 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325181642.GB17019@2bithacker.net> Message-ID: <20140325221729.5955.qmail@joyce.lan> >This seems like to sort of problem that Mailops or MAAWG should >be hammering out. Of course MAAWG is working on it. But don't hold your breath. R's, John From johnl at iecc.com Tue Mar 25 22:19:39 2014 From: johnl at iecc.com (John Levine) Date: 25 Mar 2014 22:19:39 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331EDAB.8000303@2mbit.com> Message-ID: <20140325221939.6001.qmail@joyce.lan> In article <5331EDAB.8000303 at 2mbit.com> you write: >On 3/25/14, 11:56 AM, John Levine wrote: >> I think this would be a good time to fix your mail server setup. >> You're never going to get much v6 mail delivered without rDNS, because >> receivers won't even look at your mail to see if it's authenticated. >> >> CenturyLink is reasonably technically clued so it shouldn't be >> impossible to get them to fix it. > > >Nothing wrong with my mail server setup, except the lack of RDNS. >Lacking reverse should be one of many things to consider with rejecting >e-mails, but should not be the only condition. "It would be inconvenient for me to make this change, therefore everyone else should change instead." Don't hold your breath. R's, John From rsk at gsp.org Tue Mar 25 22:38:58 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 25 Mar 2014 18:38:58 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331EDAB.8000303@2mbit.com> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> Message-ID: <20140325223858.GA25217@gsp.org> On Tue, Mar 25, 2014 at 02:57:15PM -0600, Brielle Bruns wrote: > Nothing wrong with my mail server setup, except the lack of RDNS. > Lacking reverse should be one of many things to consider with > rejecting e-mails, but should not be the only condition. Lack of rDNS means either (a) there is something temporarily wrong with rDNS/DNS or (b) it's a spam source or (c) someone doesn't know how to set up rDNS/DNS for a mail server. Over the past decade, (b) has been the answer to about five or six 9's (depending on how I crunch the numbers), so deferring on that alone is not only sensible, but quite clearly a best practice. If it turns out that it looks like (b) but is actually (a), then as long as the DNS issue clears up before SMTP retries stop, mail is merely delayed, not rejected. And although *sometimes* it's (c), why would I want to accept mail from a server run by people who don't grasp basic email server operation best practices? (Doubly so since long experience strongly suggests people that botch this will very likely botch other things as well, some of which can result in negative outcomes *for me* if I accomodate them.) Of all the things that we need to do in order to make our mail servers play nice with the rest of the world, DNS/rDNS (and HELO) are among the simplest and easiest. ---rsk p.s. I also reject on mismatched and generic rDNS. Real mail servers have real names, so if [generic] you insist on making yours look like a bot, I'll believe you and treat it like one. From laszlo at heliacal.net Tue Mar 25 23:07:16 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 25 Mar 2014 23:07:16 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325223858.GA25217@gsp.org> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <20140325223858.GA25217@gsp.org> Message-ID: <3D7D0845-CB25-4C05-8FAB-F5728C8602DD@heliacal.net> The OP doesn't have control over the reverse DNS on the AT&T 6rd. Spam crusades aside, it can be seen as just another case of 'putting people in their place', reinforcing that your end user connection is lesser and doesn't entitle to you to participate in the internet with the big boys. How does one dare run a 'server' without being a member of a RIR? One would hope that with IPv6 this would change, but the attitude of looking down on end subscribers has been around forever. As seen in the other thread being discussed here, people are already looking for ways to block end users from participating. -Laszlo On Mar 25, 2014, at 10:38 PM, Rich Kulawiec wrote: > On Tue, Mar 25, 2014 at 02:57:15PM -0600, Brielle Bruns wrote: >> Nothing wrong with my mail server setup, except the lack of RDNS. >> Lacking reverse should be one of many things to consider with >> rejecting e-mails, but should not be the only condition. > > Lack of rDNS means either (a) there is something temporarily wrong with > rDNS/DNS or (b) it's a spam source or (c) someone doesn't know how to set > up rDNS/DNS for a mail server. Over the past decade, (b) has been the > answer to about five or six 9's (depending on how I crunch the numbers), > so deferring on that alone is not only sensible, but quite clearly a > best practice. If it turns out that it looks like (b) but is actually > (a), then as long as the DNS issue clears up before SMTP retries stop, > mail is merely delayed, not rejected. And although *sometimes* it's > (c), why would I want to accept mail from a server run by people who > don't grasp basic email server operation best practices? (Doubly so > since long experience strongly suggests people that botch this will very > likely botch other things as well, some of which can result in negative > outcomes *for me* if I accomodate them.) > > Of all the things that we need to do in order to make our mail servers > play nice with the rest of the world, DNS/rDNS (and HELO) are among > the simplest and easiest. > > ---rsk > > p.s. I also reject on mismatched and generic rDNS. Real mail servers have > real names, so if [generic] you insist on making yours look like a bot, > I'll believe you and treat it like one. > From fergdawgster at mykolab.com Tue Mar 25 23:15:22 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 25 Mar 2014 16:15:22 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <5331F154.8050105@mykolab.com> Message-ID: <53320E0A.6040202@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/25/2014 2:38 PM, Elizabeth Zwicky wrote: > Local policy, sure; local DMARC policy, wait what? My goof. Apparently just local policy sans DMARC. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMyDgoACgkQKJasdVTchbL+RAD+K6ERAs2vZQjhgaa+1qsOKtdS aTJsVwQZxfgKsC32c7kA/iGuDoLnN4bZAXkls/Jx+jhTFtoBKD3yZsM6zBzKmw6v =HwGn -----END PGP SIGNATURE----- From jfbeam at gmail.com Tue Mar 25 23:25:21 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 25 Mar 2014 19:25:21 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <3D7D0845-CB25-4C05-8FAB-F5728C8602DD@heliacal.net> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <20140325223858.GA25217@gsp.org> <3D7D0845-CB25-4C05-8FAB-F5728C8602DD@heliacal.net> Message-ID: On Tue, 25 Mar 2014 19:07:16 -0400, Laszlo Hanyecz wrote: > One would hope that with IPv6 this would change, but the attitude of > looking down on end subscribers has been around forever. And for damn good reasons (read: foolish and easy to trick into becoming a spam source.) Granted, "enterprise" players are only slightly less foolish and easy to hack. My inbox being proof hosting providers cannot police their idiot users. ISPs will need to continue the "evil" practice of blocking outbound port 25. --Ricky From johnl at iecc.com Tue Mar 25 23:35:57 2014 From: johnl at iecc.com (John Levine) Date: 25 Mar 2014 23:35:57 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <3D7D0845-CB25-4C05-8FAB-F5728C8602DD@heliacal.net> Message-ID: <20140325233557.6311.qmail@joyce.lan> In article <3D7D0845-CB25-4C05-8FAB-F5728C8602DD at heliacal.net> you write: >The OP doesn't have control over the reverse DNS on the AT&T 6rd. Ah, OK, you're saying that their IPv6 isn't ready for prime time. >One would hope that with IPv6 this would change, but the attitude of looking down on end subscribers has been around >forever. It has nothing to do with looking down on "subscribers" and everything to do with practicality. When 99,9% of mail sent directly from consumer IP ranges is botnet spam, and I think that's a reasonable estimate, we have better things to do than to spend a lot of our money expensively filtering that spam for the benefit of the GWL who is too cool to relay through a mail server with a real name. R's, John From marka at isc.org Tue Mar 25 23:48:13 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 26 Mar 2014 10:48:13 +1100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "25 Mar 2014 23:35:57 -0000." <20140325233557.6311.qmail@joyce.lan> References: <20140325233557.6311.qmail@joyce.lan> Message-ID: <20140325234813.41B5511CD233@rock.dv.isc.org> In message <20140325233557.6311.qmail at joyce.lan>, "John Levine" writes: > In article <3D7D0845-CB25-4C05-8FAB-F5728C8602DD at heliacal.net> you write: > >The OP doesn't have control over the reverse DNS on the AT&T 6rd. > > Ah, OK, you're saying that their IPv6 isn't ready for prime time. > > >One would hope that with IPv6 this would change, but the attitude of looking > down on end subscribers has been around > >forever. > > It has nothing to do with looking down on "subscribers" and everything > to do with practicality. When 99,9% of mail sent directly from > consumer IP ranges is botnet spam, and I think that's a reasonable > estimate, we have better things to do than to spend a lot of our money > expensively filtering that spam for the benefit of the GWL who is too > cool to relay through a mail server with a real name. Or he could just not like NSL and the fact the ISP's are required to abide by them. If people want their email going through where it can be snooped apon that is their perogative. Just don't force people to have to use I-WILL-SNOOP-ISP!!! > > R's, > John > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From johnl at iecc.com Wed Mar 26 00:17:35 2014 From: johnl at iecc.com (John R. Levine) Date: 25 Mar 2014 20:17:35 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325234813.41B5511CD233@rock.dv.isc.org> References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> Message-ID: > Or he could just not like NSL and the fact the ISP's are required > to abide by them. If people want their email going through where > it can be snooped apon that is their perogative. Just don't force > people to have to use I-WILL-SNOOP-ISP!!! Who said anything about being required to use your ISP's mail server? I don't think I have, ever. You need to use one with a static IP and reasonable rDNS, which could be anywhere. Also, if the snoops are interested enough in you to drop an NSL on your ISP, you have worse problems than running your own mail server will solve. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From marka at isc.org Wed Mar 26 00:45:46 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 26 Mar 2014 11:45:46 +1100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "25 Mar 2014 20:17:35 -0400." References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> Message-ID: <20140326004546.825AD11CD8C8@rock.dv.isc.org> In message , "John R. Levine" writes: > > Or he could just not like NSL and the fact the ISP's are required > > to abide by them. If people want their email going through where > > it can be snooped apon that is their perogative. Just don't force > > people to have to use I-WILL-SNOOP-ISP!!! > > Who said anything about being required to use your ISP's mail server? I > don't think I have, ever. You need to use one with a static IP and > reasonable rDNS, which could be anywhere. There you go forcing people to jump through unnecessary hoops to send email. No you do not need a static address to send email. No you do not need a PTR record to send email. None of this is REQUIRED. It is forced on people by a cartel of email providers. > Also, if the snoops are interested enough in you to drop an NSL on your > ISP, you have worse problems than running your own mail server will solve. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From adam.king at auda.org.au Tue Mar 25 23:19:09 2014 From: adam.king at auda.org.au (Adam King) Date: Wed, 26 Mar 2014 10:19:09 +1100 Subject: DNSSEC in .au Message-ID: <233E95DA-CC52-4CAF-8F5D-92023EAEB164@auda.org.au> auDA has announced it will be introducing DNSSEC into the .au domain space in an experimental capacity. Deployment on production servers will commence during April and will be trialled for 4 months. The .au DS records will_not be added to the root zone during this period. Operators should_not create or implement trust anchors for .au in their production environments during this experimental phase. A mailing list has been created for all future announcements related to DNSSEC in .au, if you wish to subscribe to this mailing list please visit http://www.lists.auda.org.au/mailman/listinfo/dnssec-announce For further information about the implementation of DNSSEC in .au please see http://www.auda.org.au/industry-information/au-domains/dnssec/. Kind Regards, Adam King | CTO .au Domain Administration Ltd T: +61 3 8341 4111 | F: +61 3 8341 4112 E: adam.king at auda.org.au | W:www.auda.org.au Twitter: @auda | Blog: www.auda.org.au/blog/ auDA - Australia's Domain Name Administrator Important Notice This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. From mehmet at akcin.net Wed Mar 26 01:01:58 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 26 Mar 2014 09:01:58 +0800 Subject: DNSSEC in .au In-Reply-To: <233E95DA-CC52-4CAF-8F5D-92023EAEB164@auda.org.au> References: <233E95DA-CC52-4CAF-8F5D-92023EAEB164@auda.org.au> Message-ID: <330FC317-2707-44FD-8BFA-2887681AA71A@akcin.net> Congratulations Adam. Mehmet > On Mar 26, 2014, at 7:19, Adam King wrote: > > auDA has announced it will be introducing DNSSEC into the .au domain space in an experimental capacity. Deployment on production servers will commence during April and will be trialled for 4 months. The .au DS records will_not be added to the root zone during this period. > > Operators should_not create or implement trust anchors for .au in their production environments during this experimental phase. > > A mailing list has been created for all future announcements related to DNSSEC in .au, if you wish to subscribe to this mailing list please visit http://www.lists.auda.org.au/mailman/listinfo/dnssec-announce > > For further information about the implementation of DNSSEC in .au please see http://www.auda.org.au/industry-information/au-domains/dnssec/. > > > Kind Regards, > Adam King | CTO > .au Domain Administration Ltd > T: +61 3 8341 4111 | F: +61 3 8341 4112 > E: adam.king at auda.org.au | W:www.auda.org.au > Twitter: @auda | Blog: www.auda.org.au/blog/ > auDA - Australia's Domain Name Administrator > Important Notice > This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. > From bruns at 2mbit.com Wed Mar 26 01:24:58 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 19:24:58 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325233557.6311.qmail@joyce.lan> References: <20140325233557.6311.qmail@joyce.lan> Message-ID: <53322C6A.70400@2mbit.com> On 3/25/14, 5:35 PM, John Levine wrote: > In article<3D7D0845-CB25-4C05-8FAB-F5728C8602DD at heliacal.net> you write: >> >The OP doesn't have control over the reverse DNS on the AT&T 6rd. > Ah, OK, you're saying that their IPv6 isn't ready for prime time. > >> >One would hope that with IPv6 this would change, but the attitude of looking down on end subscribers has been around >> >forever. > It has nothing to do with looking down on "subscribers" and everything > to do with practicality. When 99,9% of mail sent directly from > consumer IP ranges is botnet spam, and I think that's a reasonable > estimate, we have better things to do than to spend a lot of our money > expensively filtering that spam for the benefit of the GWL who is too > cool to relay through a mail server with a real name. I'm sure you are as vocal about outright rejecting messages for lack of SPF (even if softfail) and lack of DKIM as you are about requiring rDNS? Or perhaps making TLS mandatory, outright rejecting cleartext. Seems like the logical next step... Maybe too much overkill though, right? Hard to define when you cross over that line. Last time I checked, there is no RFC that states that using SMTP transport is mandatory with the originator having rDNS (ipv4/ipv6). It may be SUGGESTED or RECOMMENDED, but not MANDATORY or REQUIRED. It is an arbitrary decision made by each mail provider. Obviously, Google will do whatever they want, which is within their right. Doesn't mean though, that I can't express my disgust/annoyance in them doing it and for the added hassle it causes me. ------- I hope you understand where I'm coming from, John. I'm a huge supporter of IPv6 deployment - and have been using every opportunity I have had at my disposal to bring it to my end users, and make them excited about it too. The problem is, it blows my cred and rep with my end users when on day one of getting them set up and fully running on IPv6, they can't e-mail the local school district, or their business partners, because the other end uses Google mail. It makes me look like an idiot, and they start questioning why should they waste time/money on getting to be IPv6 ready. These kind of issues are things we are trying to avoid, but seem to be shooting ourselves in the foot on, even if unintentionally. Everything is a tradeoff, and in this case, I don't believe the tradeoff is worth the hassle it can cause. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From trejrco at gmail.com Wed Mar 26 01:58:40 2014 From: trejrco at gmail.com (TJ) Date: Tue, 25 Mar 2014 21:58:40 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53322C6A.70400@2mbit.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> Message-ID: In an attempt to get this thread back on topic: * Does Google require rDNS for IPv4 mail sources? If so, doing so for IPv6 shouldn't be a surprise. Your current provider's inability to support rDNS for IPv6 is not a protocol failure, it is a provider failure. If not, is there an additional operational reason for them to do so in IPv6? ... and in that case, I'd come to the same end result, provider-failure. ... ? /TJ From lists at tigertech.com Wed Mar 26 02:03:44 2014 From: lists at tigertech.com (Robert L Mathews) Date: Tue, 25 Mar 2014 19:03:44 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53322C6A.70400@2mbit.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> Message-ID: <53323580.2080108@tigertech.com> On 3/25/14, 6:24 PM, Brielle Bruns wrote: > The problem is, it blows my cred and rep with my end users when on day > one of getting them set up and fully running on IPv6, they can't e-mail > the local school district, or their business partners, because the other > end uses Google mail. It makes me look like an idiot, and they start > questioning why should they waste time/money on getting to be IPv6 ready. I don't quite see how this is anything to do with IPv6. If you set up an IPv4 mail server with no reverse DNS, your mail would be rejected by many servers, too. And there are certainly plenty of providers who won't let you configure the reverse DNS of an IPv4 address. Your provider assigned you an IP address with no reverse DNS, and you set up a mail server on that IP address. Most people would say that was unreliable even before knowing you're talking about IPv6 instead of IPv4. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ From fergdawgster at mykolab.com Wed Mar 26 02:08:41 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 25 Mar 2014 19:08:41 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53323580.2080108@tigertech.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> <53323580.2080108@tigertech.com> Message-ID: <533236A9.3000104@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/25/2014 7:03 PM, Robert L Mathews wrote: > On 3/25/14, 6:24 PM, Brielle Bruns wrote: >> The problem is, it blows my cred and rep with my end users when >> on day one of getting them set up and fully running on IPv6, they >> can't e-mail the local school district, or their business >> partners, because the other end uses Google mail. It makes me >> look like an idiot, and they start questioning why should they >> waste time/money on getting to be IPv6 ready. > > I don't quite see how this is anything to do with IPv6. > > If you set up an IPv4 mail server with no reverse DNS, your mail > would be rejected by many servers, too. And there are certainly > plenty of providers who won't let you configure the reverse DNS of > an IPv4 address. > > Your provider assigned you an IP address with no reverse DNS, and > you set up a mail server on that IP address. Most people would say > that was unreliable even before knowing you're talking about IPv6 > instead of IPv4. > Also, please do *not* expect folks to toss anti-spam measures out the window just because they might move to v6. That would be naive. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMyNqkACgkQKJasdVTchbLmvgEA14CAn9T40qTwPwWMksDxMptb tROSknvz1UftBJNZqrsA+wfqdNtseWZinWAlGIs7AnaIsWb+A21iQovv0rRW1Nny =Wdwe -----END PGP SIGNATURE----- From rob at invaluement.com Wed Mar 26 02:14:17 2014 From: rob at invaluement.com (Rob McEwen) Date: Tue, 25 Mar 2014 22:14:17 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53322C6A.70400@2mbit.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> Message-ID: <533237F9.5020607@invaluement.com> On 3/25/2014 9:24 PM, Brielle Bruns wrote: > Last time I checked, there is no RFC that states that using SMTP > transport is mandatory with the originator having rDNS (ipv4/ipv6). > It may be SUGGESTED or RECOMMENDED, but not MANDATORY or REQUIRED. It > is an arbitrary decision made by each mail provider. For IPv6, FCrDNS... using NOT "dynamic formatted" host names... and with the host name ending in the sender's main domain... *should* be mandatory. And +1 THOUSAND for everything that John Levine said in his last few messages! Additionally... [addressing this topic in general from here on, not talking specifically to Brielle...] I have a unique perspective on this... as I manage an anti-spam blacklist which blacklists many of the snowshoe spammers and "can-spam complient" spammers whose practices are 100% legal, and who are not sending to a single caught-you-red-handed honeypot trap. Many of them abuse blackhat and grayhat ESPs. Unfortunately, in some instanaces, that "abuse" is symbiotic ("wink wink"), where the blackhat ESP will know that a sender's practices are extremly suspect (or worse), but will look the other way in exchange for much needed revenue. In fact, with the worldwide economy still in somewhat of a drag for about the 6th year in the row, I'm seeing evidences that *some* ESPs are lowering their standards a little to even more accommodate this crap. Some once-proud ESP who claimed they never do this, are in fact doing it. Still, a HUGE deterrent is getting their IP reputation "soiled"up on senderbase.org and getting on many blacklists. That becomes a "safety net" that keeps some of these ESPs from going off the deep end. And, again, I'm on the front lines dealing with this everyday. Therefore, SCARCITY of IPv4 IPs... is a FEATURE.. NOT a bug when it comes to keeping ESPs under control. And it also gives hosters/datacenters motivation to likewise "police" potential customers because the hoster or datacenter is left with the damage long after they've kicked a spammer off of their network. ALL of that would "unravel"... ALL OF IT!!!!! ... if we all started using IPv6 for sending authenticated mail. (workstations sending mail to their own mail server could send via IPv6 all they wanted to.. that wouldn't be a problem at all) But if all or most MTAs switched to IPv6, it would be a nightmare and what is sad is that MANY people reading this message are STILL going to GREATLY underestimate my warning after reading this. There are, unfortunately, many poeple who won't listen to reason and logic and require a real world nightmare before they "believe"... much like a 2-year-old who doesn't believe his parents' warning to not touch a hot stove... until AFTER he touches it. But we don't all have that luxury, do we? IPv6 is a spammer's dream! But REQUIRING FCrDNS for IPv6 ... using a NOT "dynamic formatted" host name... and with the host name ending in the sender's main domain... would go a long way towards mitigating these problems as then there would be more "truth in sending" as the rDNS would then properly convey both reputation and identity to the sender. I wish that could becomes a universal IPv6 SMTP standard... yesterday! PS - but even then, I'm told that there may be issues with overrunning DNS caches should spammers send each spam from a unique IP.... and slowing down of processing of mail when rDNS lookups happen on each individual IP. To go back over the "root problem" that I never mentioned, a spammer would send out a million spams, each from a unique IP address, without even having that large of an IPv6 allocation. IPv6 MTAs is NOT something to be "rushed into". Anyone promoting rushing into that... is not very well informed. (to put it nicely).. or they are a spammer who can't wait for all the fun to commence. -- Rob McEwen From bruns at 2mbit.com Wed Mar 26 02:25:57 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 20:25:57 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> Message-ID: <53323AB5.4050808@2mbit.com> On 3/25/14, 7:58 PM, TJ wrote: > In an attempt to get this thread back on topic: > * Does Google require rDNS for IPv4 mail sources? After a quick test here, Google did not reject the mail from an IPv4 address that did not have rDNS. > If so, doing so for IPv6 shouldn't be a surprise. Your current provider's > inability to support rDNS for IPv6 is not a protocol failure, it is a > provider failure. > > If not, is there an additional operational reason for them to do so in > IPv6? ... and in that case, I'd come to the same end result, > provider-failure. > > ... ? Google willing to accept collateral damage for IPv6 mailing hosts, but too severe of collateral damage for IPv4 ones that would affect too many customers? Like I said in a previous response, if you are going to make rdns a requirement, why not make SPF and DKIM mandatory as well? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Wed Mar 26 02:31:15 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 20:31:15 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53323580.2080108@tigertech.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> <53323580.2080108@tigertech.com> Message-ID: <53323BF3.8050505@2mbit.com> On 3/25/14, 8:03 PM, Robert L Mathews wrote: > I don't quite see how this is anything to do with IPv6. > It does when you've got the job of trying to convince people who know nothing about how the internet works why they should invest time in something new. Unless, I'm wrong in that we're trying to encourage people to go dual stacked and not be solely dependent on IPv4... > If you set up an IPv4 mail server with no reverse DNS, your mail would > be rejected by many servers, too. And there are certainly plenty of > providers who won't let you configure the reverse DNS of an IPv4 address. > Yup, there are, and i've been on those providers in the past that did not consider IPv4 rdns important either. Google does not outright reject mail from hosts with no IPv4 rdns, from what my quick test a moment ago showed. > Your provider assigned you an IP address with no reverse DNS, and you > set up a mail server on that IP address. Most people would say that was > unreliable even before knowing you're talking about IPv6 instead of > IPv4. Considering at the time of the deployment, I had no inclination that Google had enacted this policy, you can imagine my surprise, esp. after having said customer on an IPv4 addr previously that had no rdns either, and was sending mail to gmail fine. Call it unreliable all you want, there's more then a few mail servers out there with no rdns on both IPv4 and IPv6. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Wed Mar 26 02:33:01 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 25 Mar 2014 20:33:01 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <533236A9.3000104@mykolab.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> <53323580.2080108@tigertech.com> <533236A9.3000104@mykolab.com> Message-ID: <53323C5D.4080401@2mbit.com> On 3/25/14, 8:08 PM, Paul Ferguson wrote: > Also, please do*not* expect folks to toss anti-spam measures out the > window just because they might move to v6. > > That would be naive. > Of course not, been spending the last few months trying to adapt my own anti-spam measures to work properly for IPv6, as well as trying to figure out how to handle IPv6 listings in the AHBL's DNSbl. Its frustrating, but a necessity. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From johnl at iecc.com Wed Mar 26 02:45:00 2014 From: johnl at iecc.com (John R. Levine) Date: 25 Mar 2014 22:45:00 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140326004546.825AD11CD8C8@rock.dv.isc.org> References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> Message-ID: > None of this is REQUIRED. It is forced on people by a cartel of > email providers. It must be nice to live in world where there is so little spam and other mail abuse that you don't have to do any of the anti-abuse things that real providers in the real world have to do. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From rob at invaluement.com Wed Mar 26 02:51:11 2014 From: rob at invaluement.com (Rob McEwen) Date: Tue, 25 Mar 2014 22:51:11 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53323AB5.4050808@2mbit.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> <53323AB5.4050808@2mbit.com> Message-ID: <5332409F.1060109@invaluement.com> On 3/25/2014 10:25 PM, Brielle Bruns wrote: > > Like I said in a previous response, if you are going to make rdns a > requirement, why not make SPF and DKIM mandatory as well? many ISPs ALREADY require rDNS. So making that standard official for IPv6 is isn't asking for much! It is a NATURAL progression. As I mentioned in a previous message, i think IPv6 should go farther and require FCrDNS, with the host name ending with the sender's actual real domain so that proper identity is conveyed. (then when a spammer uses a "throwaway domain" or known spammy domain... as the domain at the end of the rDNS, they have only themselves to blame when the message is rejected!) SPF is somewhat "dead"... because it breaks e-mail forwarding situations. Anyone who blocks on a bad SFP is going to have significant FPs. And by the time you've dialed down the importance of SPF to prevent FPs (either by the receiver not making too big of a deal about ir, or the sender using a NOT strict SFP), it then becomes impotent. About the only good usage of SPF is to change a domain's record to "strict" in situations where some e-mail on that domain is being "picked on" by a "joe job" where their address is forged into MANY spams over a period of time. (not just the occasional hit that everyone gets). otherwise, SPF is worthless. Maybe we should require DKIM for IPv6, too? But what I suggested about FCrDNS seems like a 1st step to me. -- Rob McEwen +1 (478) 475-9032 From mysidia at gmail.com Wed Mar 26 02:51:29 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Mar 2014 21:51:29 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: On Tue, Mar 25, 2014 at 12:51 PM, Mikael Abrahamsson wrote: > On Tue, 25 Mar 2014, John Levine wrote: > >> It says a lot about the state of the art that people are still making >> uninformed guesses like this, non ironically. > > I have repeatedly tried to get people interested in methods of making it > possible for ISPs to publish their "per-customer" allocation size, so far > without any success. Most of the time I seem to get "we did it a certain > way for IPv4, it works, we don't want to change it" from people. > [snip] I would suggest the formation of an "IPv6 SMTP Server operator's club," with a system for enrolling certain IP address source ranges as "Active mail servers", active IP addresses and SMTP domain names under the authority of a member. And certain internet domain names as "Active SMTP domains" authorized to originate mail for specific SMTP servers. And some agreed upon operational policies, such as implementation of TLS using a certificate signed by the CA or a recognized SMTP club.... appropriate processing of abuse requests, and prompt administrator attention in the event of an abuse complaint or other mail issue. With replacement of de-facto default accept with de-facto default deny. E.g. If you didn't bother joining one of the whitelisting clubs we subscribe to and enrolling your mail server. The expectation should become "Nobody on the internet is going to accept mail from you" Spam was a major problem with IPv4..... With IPv6 we have an opportunity to set expectations that allow us to eliminate ad-hoc dedicated SMTP servers friendly to spammers, as an internet phenomenon. > IPv6 changes things. Lots of things. There will be a lot of work to catch > up. It's too bad that the part of the ecosystem that fights spam have woken > up so late. > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- -JH From johnl at iecc.com Wed Mar 26 02:55:19 2014 From: johnl at iecc.com (John R. Levine) Date: 25 Mar 2014 22:55:19 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: > I would suggest the formation of an "IPv6 SMTP Server operator's club," > with a system for enrolling certain IP address source ranges as "Active > mail servers", active IP addresses and SMTP domain names under the > authority of a member. Surely you don't think this is a new idea. R's, John From johnl at iecc.com Wed Mar 26 03:01:52 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 03:01:52 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53322C6A.70400@2mbit.com> Message-ID: <20140326030152.7118.qmail@joyce.lan> >I'm sure you are as vocal about outright rejecting messages for lack of >SPF (even if softfail) and lack of DKIM as you are about requiring rDNS? Interesting guess, but completely wrong. >Or perhaps making TLS mandatory, outright rejecting cleartext. Not until we have SMTP DANE. >Seems like the logical next step... Maybe too much overkill though, >right? Hard to define when you cross over that line. It's up to you. If you want people to accept your mail, you can send it the way they tell you to send it, since they are doing you a favor by accepting it all. If you just want to complain, I guess you post to nanog instead. R's, John From rob at invaluement.com Wed Mar 26 03:08:43 2014 From: rob at invaluement.com (Rob McEwen) Date: Tue, 25 Mar 2014 23:08:43 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <533244BB.1060308@invaluement.com> On 3/25/2014 10:51 PM, Jimmy Hess wrote: > I would suggest the formation of an "IPv6 SMTP Server operator's club," That comes across too much like the failed FUSSP ideas. What happens when spammers try to get onboard? Who is the arbitrator? How fast could they react? And then you have legit senders who get infections or compromised accounts? Or what about a hoster who gets one bad-apple customer. This isn't so simple! Not so black & white. Yet if we instead focus on "truthful labeling of identity", then established e-mail reputation systems and established blacklists which have spent YEARS fine tuning these things... can be best prepared to sort these things about based on the reputation of the domain at the end of a sender's FCrDNS. Then the free market will properly choose the best blacklists that block the most spam with the least FPs... and the "politics" of some club won't be a negative factor. NOTE: antispam blacklists don't effectively work like men with their feet on a desk smoking cigars asking, 'should we block this sender'... 'should we whitelist this sender'... the spammers are ORDER OF MAGNITUDES faster than that! And then you'd have too many legit orgs that happen to be small.. that would be effectively blacklisted by not being able to get "into the club". i would be a nightmare! -- Rob McEwen +1 (478) 475-9032 From Valdis.Kletnieks at vt.edu Wed Mar 26 03:09:02 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Mar 2014 23:09:02 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "Tue, 25 Mar 2014 22:51:11 -0400." <5332409F.1060109@invaluement.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> <53323AB5.4050808@2mbit.com> <5332409F.1060109@invaluement.com> Message-ID: <4688.1395803342@turing-police.cc.vt.edu> On Tue, 25 Mar 2014 22:51:11 -0400, Rob McEwen said: > On 3/25/2014 10:25 PM, Brielle Bruns wrote: > > > > Like I said in a previous response, if you are going to make rdns a > > requirement, why not make SPF and DKIM mandatory as well? > > many ISPs ALREADY require rDNS. So making that standard official for > IPv6 is isn't asking for much! It is a NATURAL progression. There's still a lot of ancient mail servers out there in v4 land, that were set up before PTRs were pseudo-required by most places, so we end up cutting them some slack under a grandfather clause. There's probably less than a dozen ASNs that have mailservers that speak IPv6 that were deployed before requring PTRs became common, so they have much less of an excuse not to do so.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Mar 26 03:12:04 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Mar 2014 23:12:04 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "25 Mar 2014 22:55:19 -0400." References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <4819.1395803524@turing-police.cc.vt.edu> On 25 Mar 2014 22:55:19 -0400, "John R. Levine" said: > > I would suggest the formation of an "IPv6 SMTP Server operator's club," > > with a system for enrolling certain IP address source ranges as "Active > > mail servers", active IP addresses and SMTP domain names under the > > authority of a member. > > Surely you don't think this is a new idea. It can't be - it's listed on this very old page: http://www.rhyolite.com/anti-spam/you-might-be.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From laszlo at heliacal.net Wed Mar 26 03:15:56 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 26 Mar 2014 03:15:56 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5332409F.1060109@invaluement.com> References: <20140325233557.6311.qmail@joyce.lan> <53322C6A.70400@2mbit.com> <53323AB5.4050808@2mbit.com> <5332409F.1060109@invaluement.com> Message-ID: Maybe we could give everyone globally unique numbers and end to end connectivity. Then maybe the users themselves can send email directly to each other without going through this ESP cartel. -Laszlo On Mar 26, 2014, at 2:51 AM, Rob McEwen wrote: > On 3/25/2014 10:25 PM, Brielle Bruns wrote: >> >> Like I said in a previous response, if you are going to make rdns a >> requirement, why not make SPF and DKIM mandatory as well? > > many ISPs ALREADY require rDNS. So making that standard official for > IPv6 is isn't asking for much! It is a NATURAL progression. As I > mentioned in a previous message, i think IPv6 should go farther and > require FCrDNS, with the host name ending with the sender's actual real > domain so that proper identity is conveyed. (then when a spammer uses a > "throwaway domain" or known spammy domain... as the domain at the end of > the rDNS, they have only themselves to blame when the message is rejected!) > > SPF is somewhat "dead"... because it breaks e-mail forwarding > situations. Anyone who blocks on a bad SFP is going to have significant > FPs. And by the time you've dialed down the importance of SPF to prevent > FPs (either by the receiver not making too big of a deal about ir, or > the sender using a NOT strict SFP), it then becomes impotent. About the > only good usage of SPF is to change a domain's record to "strict" in > situations where some e-mail on that domain is being "picked on" by a > "joe job" where their address is forged into MANY spams over a period of > time. (not just the occasional hit that everyone gets). otherwise, SPF > is worthless. > > Maybe we should require DKIM for IPv6, too? But what I suggested about > FCrDNS seems like a 1st step to me. > > -- > Rob McEwen > +1 (478) 475-9032 > > From mysidia at gmail.com Wed Mar 26 03:16:37 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Mar 2014 22:16:37 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: On Tue, Mar 25, 2014 at 9:55 PM, John R. Levine wrote: > I would suggest the formation of an "IPv6 SMTP Server operator's club," >> with a system for enrolling certain IP address source ranges as "Active > > Surely you don't think this is a new idea. > Would it make it more unique; if I suggested creation of a new distributed Cryptocurrency something like 'MAILCoin' to track the memberships in the club and handle voting out of abusive mail servers: in a distributed manner, to ensure that no court could ever mandate that a certain IP address be accepted into the club? Not necessarily. But I haven't yet heard of any meaningful attempt to implement something like that. Obviously with IPv4; way too many "legacy" mail servers exist that will never bother to implement new protocols and practice improvements ---- even basic things, such as SMTP rejecting invalid recipients instead of sending unsolicited bounce replies to senders (forged by spammers). > R's, > John -- -JH From james.cutler at consultant.com Wed Mar 26 03:31:04 2014 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 25 Mar 2014 23:31:04 -0400 Subject: IPv6 isn't SMTP Message-ID: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP! Please explain my misunderstanding on the following: 1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like). 2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations] 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one?s own combat boots. And not particularly productive. I look forward to furthering my education. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mysidia at gmail.com Wed Mar 26 03:29:32 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Mar 2014 22:29:32 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <533244BB.1060308@invaluement.com> References: <20140325172328.5224.qmail@joyce.lan> <533244BB.1060308@invaluement.com> Message-ID: On Tue, Mar 25, 2014 at 10:08 PM, Rob McEwen wrote: > On 3/25/2014 10:51 PM, Jimmy Hess wrote: > > I would suggest the formation of an "IPv6 SMTP Server operator's club," > > That comes across too much like the failed FUSSP ideas. What happens > when spammers try to get onboard? Who is the arbitrator? How fast could > This is when you fall to other mechanisms, BUT you still raised the bar -- even if the spammers could get onboard -- your first choice of deny-by-default did have to fail first for that specific spammer. > they react? And then you have legit senders who get infections or > compromised accounts? Or what about a hoster who gets one bad-apple > Again. Perfection not claimed. There is no one cure. > reputation systems and established blacklists which have spent YEARS > fine tuning these things... can be best prepared to sort these things > about based on the reputation of the domain at the end of a sender's > So-called fine-tuned reputation systems and established blacklists seriously need help. They spent years fine-tuning those things, BUT none of them work that well, either, well; they mostly work --- except on occasion when they do not. > > 'should we whitelist this sender'... the spammers are ORDER OF > MAGNITUDES faster than that! And then you'd have too many legit orgs > that happen to be small.. that would be effectively blacklisted by not > being able to get "into the club". i would be a nightmare! > Organization size not a criteria. Only agreeing to follow whatever basic rules would be agreed upon, inclusive of mutual support and cooperation to address spam issues... Small legit orgs need the support more than anyone! Remember why FcRDNS works so well in the first place? Many spamming IPs are not intended to be mail servers in the first place. If the spammer was not running malicious code; there would be no SMTP client on that server. On the other hand... FcRDNS includes additional IPs that are also not intended to be mail servers. Requiring a Declarative assertion "This server IP address is definitely intended to originate messages to remote sites" Effectively limits spammers from just setting up a mail server on any random IP, by adding another pre-requisite on top of rDNS settings. -- -JH From contact at winterei.se Wed Mar 26 04:04:32 2014 From: contact at winterei.se (Paul S.) Date: Wed, 26 Mar 2014 13:04:32 +0900 Subject: IPv6 isn't SMTP In-Reply-To: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> Message-ID: <533251D0.2050400@winterei.se> On 3/26/2014 ?? 12:31, Cutler James R wrote: > Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP! > > Please explain my misunderstanding on the following: > > 1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like). > > 2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations] > > 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one?s own combat boots. And not particularly productive. > > I look forward to furthering my education. > > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > > > +1, very well put. From LarrySheldon at cox.net Wed Mar 26 04:07:28 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 25 Mar 2014 23:07:28 -0500 Subject: IPv6 isn't SMTP In-Reply-To: References: Message-ID: <53325280.9070806@cox.net> On 3/25/2014 10:31 PM, Cutler James R wrote: > Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP! > > Please explain my misunderstanding on the following: > > 1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like). > > 2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations] > > 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one?s own combat boots. And not particularly productive. > > I look forward to furthering my education. [applause] -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From johnl at iecc.com Wed Mar 26 04:18:58 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 04:18:58 -0000 Subject: IPv6 isn't SMTP In-Reply-To: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> Message-ID: <20140326041858.7576.qmail@joyce.lan> >3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with >one?s own combat boots. And not particularly productive. If you can figure out how to do effective spam filtering without looking at the IP addresses from which mail arrives, you will be in a position to make a whole lot of money. But, as always, I'm not holding my breath. R's, John PS: Note the word "effective". From LarrySheldon at cox.net Wed Mar 26 04:28:04 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 25 Mar 2014 23:28:04 -0500 Subject: A little silly for IPv6 Message-ID: <53325754.9040609@cox.net> According to the Ace of Spades HQ blog: > IPv6 would allow every atom on the surface of the earth to have its > own IP address, with enough spare to do Earth 100+ times. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Wed Mar 26 04:33:22 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 25 Mar 2014 23:33:22 -0500 Subject: IPv6 isn't SMTP In-Reply-To: References: Message-ID: <53325892.2070801@cox.net> On 3/25/2014 11:18 PM, John Levine wrote: >> 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with >> one?s own combat boots. And not particularly productive. > > If you can figure out how to do effective spam filtering without > looking at the IP addresses from which mail arrives, you will be in a > position to make a whole lot of money. > > But, as always, I'm not holding my breath. Is spam fighting really about SMTP? Or is it about abuse of the transport layer by (among other things) the SMTP? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jeff-kell at utc.edu Wed Mar 26 04:40:21 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 26 Mar 2014 00:40:21 -0400 Subject: A little silly for IPv6 In-Reply-To: <53325754.9040609@cox.net> References: <53325754.9040609@cox.net> Message-ID: <53325A35.8050603@utc.edu> On 3/26/2014 12:28 AM, Larry Sheldon wrote: > According to the Ace of Spades HQ blog: > >> IPv6 would allow every atom on the surface of the earth to have its >> own IP address, with enough spare to do Earth 100+ times. Not with a /64 minimum allocation per customer :) Jeff From jeff-kell at utc.edu Wed Mar 26 04:42:05 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 26 Mar 2014 00:42:05 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <53325892.2070801@cox.net> References: <53325892.2070801@cox.net> Message-ID: <53325A9D.50902@utc.edu> On 3/26/2014 12:33 AM, Larry Sheldon wrote: > On 3/25/2014 11:18 PM, John Levine wrote: >>> 3. Arguing about IPv6 in the context of requirements upon SMTP >>> connections is playing that uncomfortable game with >>> one?s own combat boots. And not particularly productive. >> >> If you can figure out how to do effective spam filtering without >> looking at the IP addresses from which mail arrives, you will be in a >> position to make a whole lot of money. > Is spam fighting really about SMTP? Or is it about abuse of the > transport layer by (among other things) the SMTP? Well, with current spam, the transport layer is irrelevant, given the proper phished credentials :( Jeff From johnl at iecc.com Wed Mar 26 04:50:29 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 04:50:29 -0000 Subject: IPv6 isn't SMTP In-Reply-To: <53325892.2070801@cox.net> Message-ID: <20140326045029.7847.qmail@joyce.lan> >> But, as always, I'm not holding my breath. > >Is spam fighting really about SMTP? Or is it about abuse of the >transport layer by (among other things) the SMTP? I don't think that your typical spam recipient cares how the spam got into her inbox. Anyone who has any familiarity with large scale mail systems knows that the only way to have any hope of effective spam filtering, in any medium, is to combine all the clues you can get. For mail, the source of the message is a highly useful clue. R's, John From owen at delong.com Wed Mar 26 05:31:25 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Mar 2014 22:31:25 -0700 Subject: misunderstanding scale In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> Message-ID: <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> >> IPv6 adds an entirely new aspect to it. > > Well, if you mean the entirely new aspect is a list of hex addresses instead of dotted decimal addresses I guess so. I personally would rather have a list of actual end system addresses than a list of addresses that represent a mail server and several thousand other innocent devices behind a NAT. Might be easier to tell the system owner which system is compromised than to call a large company and tell them one of their systems is compromised. It would also be nice to be able to allow legitimate email to a business partner while blocking his compromised system only. > I thin the new dimension is that a spammer today who manages to snag a /8 has 16.7 million addresses to play with. Even if he forces you to add each and every one to your list, that?s a few megabytes for a VERY large IPv4 block. OTOH, a spammer with a single /64, pretty much the absolute minimum IPv6 block, has more than 18 quintillion addresses and there?s not a computer on the planet with enough memory (or probably not even enough disk space) to store that block list. Sometimes scale is everything. host-based reputation lists scale easily to 3.2 billion host addresses. IPv6, not so easily. Owen From owen at delong.com Wed Mar 26 05:27:57 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Mar 2014 22:27:57 -0700 Subject: misunderstanding scale (was: Ipv4 end, its fake.) In-Reply-To: <63e1934fa178cd323f44911f34681039.squirrel@66.201.44.180> References: <6350F5CB-23E2-4D99-9D06-4617A3F99601@delong.com> <52f9cc4869bbbbf212b4b4fd525ef7b5.squirrel@66.201.44.180> <63e1934fa178cd323f44911f34681039.squirrel@66.201.44.180> Message-ID: >>> >>> Thus far, IPv6 has been the "Field of Dreams" .... those of us who have >>> built it, we know they have not yet come (the IPv6 customers). That's >>> all this discussion is really about is "when will they come". >> >> Some of us have quite a few IPv6 customers: >> http://www.worldipv6launch.org/measurements/ >> And we see significant traffic from those users. :-) >> > > Maybe my isolation in silicon valley causes me to have a different IPv6 > experience. Not much IPv6 happening here. I heard Google my have topped > over 2% traffic that is IPv6. Significant ? Not from where I am sitting. > There?s actually lots of IPv6 happening in Silicon Valley. I?ve been running IPv6 for years and so has my employer. Your Google data is old? They?re well over 4% and it?s been doubling about every 3-6 months, so I?d expect to see upwards of 16% by the end of the year, but remember, that?s traffic that chose IPv6 based on happy eyeballs and doesn?t represent all traffic that could have gone IPv6 or even all traffic that would have gone best over IPv6. If Micr0$0ft would publish the stats of native vs. teredo from the xbox one, I bet we?d have a better idea of what percentage of folks are running IPv6 for real. I think it?s a lot more than you seem to believe. Of the major consumer providers in the area, AT&T and SPRINT Wireless are the only ones I?m aware of that are completely unable to do IPv6. Even some of the smaller residential providers are now doing some IPv6 and I hear rumors that some AT&T DSL and uVerse customers can now get IPv6. > We give away the IPv6 to every business on a second port - to make their > life easy and encourage them to play with it. Unfortunately, few try it at > all. We make IPv6 available to all of our customers on the same port which seems to make their life even easier and many of our customers are using it. Perhaps this is food for thought. Owen From mysidia at gmail.com Wed Mar 26 05:41:41 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 26 Mar 2014 00:41:41 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <53325280.9070806@cox.net> References: <53325280.9070806@cox.net> Message-ID: On Tue, Mar 25, 2014 at 11:07 PM, Larry Sheldon wrote: > On 3/25/2014 10:31 PM, Cutler James R wrote: > >> > 2. SMTP is an Application Layer Protocol, supposedly independent of >> Routing and lower layers of the protocol stack. Various communities have >> added connection initiation requirements that sometimes impinge > > [snip] (1) Architectural layers are a protocol design construction, only, which assist with standardization. They are not a separation of responsibilities. A SMTP server has to take care to have an implementation of all layers. Further: A well designed SMTP server has to be built with some understanding of all layers involved, they are used to construct Received: headers, and a SMTP server cannot treat the application layer in isolation. It is a complete and utter fiction, to suppose that the layers can be treated in total isolation. (2) The IP protocol layer is not actually independent. Moving to IPv6 does in fact have effective new requirements for SMTP servers. (3) Abuse transcends all layers, and so does the administration of any service provided by an application. (4) When a major change will [by necessity] be made to any layer underlying the MTA application on the protocol stack, now is also a good time to look at the overall service as a whole. -- -JH From david at mailplus.nl Wed Mar 26 08:17:17 2014 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Wed, 26 Mar 2014 09:17:17 +0100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5331EDAB.8000303@2mbit.com> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75AE91A3D5@SBS1.blinker.local> >Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition. And your opinion is just another one. Someone else has a different one. Resulting in the mess email is now. You won't believe the crap I read in bounces (it also gives a funny insight into the email chain/setup of a company). Email security (against spam) should be fixed. Properly. Fine grained complaining should be possible (to the sender and all intermittent parties, as well as external parties). Make some RFCs that work please. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: Brielle Bruns [mailto:bruns at 2mbit.com] Verzonden: Tuesday, March 25, 2014 9:57 PM Aan: nanog at nanog.org Onderwerp: Re: why IPv6 isn't ready for prime time, SMTP edition On 3/25/14, 11:56 AM, John Levine wrote: > I think this would be a good time to fix your mail server setup. > You're never going to get much v6 mail delivered without rDNS, because > receivers won't even look at your mail to see if it's authenticated. > > CenturyLink is reasonably technically clued so it shouldn't be > impossible to get them to fix it. Nothing wrong with my mail server setup, except the lack of RDNS. Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition. That would be like outright refusing mail unless it had both SPF and DKIM on every single message. Sure, great in theory, does not work in reality and will result in lost mail from legit sources. Already spoken to CenturyLink about RDNS for ipv6 - won't have rdns until native IPv6. Currently, IPv6 seems to be delivered for those who want it, via 6rd. And, frankly, I'm not going to get in a fight with CenturyLink over IPv6 RDNS, considering that I am thankful that they are even offering IPv6 when other large providers aren't even trying to do so to their residential and small business customers. It is very easy for some to forget that not everyone has a gigabit fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks announced over BGP. Some of us actually have to make do with (sometimes very) limited budgets and what the market is offering us and has made available. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From david at mailplus.nl Wed Mar 26 08:28:47 2014 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Wed, 26 Mar 2014 09:28:47 +0100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75AE91A3DB@SBS1.blinker.local> You only need Hotmail, Gmail, Yahoo on board and everyone will follow... They might even be able to dictate new SMTP RFCs. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: Jimmy Hess [mailto:mysidia at gmail.com] Verzonden: Wednesday, March 26, 2014 4:17 AM Aan: John R. Levine CC: NANOG list Onderwerp: Re: why IPv6 isn't ready for prime time, SMTP edition On Tue, Mar 25, 2014 at 9:55 PM, John R. Levine wrote: > I would suggest the formation of an "IPv6 SMTP Server operator's club," >> with a system for enrolling certain IP address source ranges as >> "Active > > Surely you don't think this is a new idea. > Would it make it more unique; if I suggested creation of a new distributed Cryptocurrency something like 'MAILCoin' to track the memberships in the club and handle voting out of abusive mail servers: in a distributed manner, to ensure that no court could ever mandate that a certain IP address be accepted into the club? Not necessarily. But I haven't yet heard of any meaningful attempt to implement something like that. Obviously with IPv4; way too many "legacy" mail servers exist that will never bother to implement new protocols and practice improvements ---- even basic things, such as SMTP rejecting invalid recipients instead of sending unsolicited bounce replies to senders (forged by spammers). > R's, > John -- -JH From jpmuga at tespok.co.ke Wed Mar 26 09:26:58 2014 From: jpmuga at tespok.co.ke (Joseph M. Owino ) Date: Wed, 26 Mar 2014 09:26:58 -0000 (GMT) Subject: Assistance Exporting MRTG graph data In-Reply-To: <9d2222f9-5f8f-4771-ac29-0b3d6f2402a1@mx-ix-nbo.tespok.co.ke> Message-ID: <88964e92-ca9e-47d2-8077-d8a7184f230a@mx-ix-nbo.tespok.co.ke> Hi, I recently changed my monitoring server and would like to know how someone can export MRTG data so that there are no breaks in the graph data? regards Joseph Muga Owino Technical Officer TESPOK Cell: 0721-930-681 twitter.com/jpmuga Zimbra Blog: Celebrate! It?s Community Manager Appreciation Day! http://bit.ly/1e3C1cq From froztbyte at froztbyte.net Wed Mar 26 09:31:48 2014 From: froztbyte at froztbyte.net (JP) Date: Wed, 26 Mar 2014 11:31:48 +0200 Subject: Assistance Exporting MRTG graph data In-Reply-To: <88964e92-ca9e-47d2-8077-d8a7184f230a@mx-ix-nbo.tespok.co.ke> References: <88964e92-ca9e-47d2-8077-d8a7184f230a@mx-ix-nbo.tespok.co.ke> Message-ID: <64AAC619-AC14-439E-B318-D02A8EF10F9A@froztbyte.net> On 26 Mar 2014, at 11:26 AM, Joseph M. Owino wrote: > Hi, > > I recently changed my monitoring server and would like to know how someone can export MRTG data so that there are no breaks in the graph data? If you went between architectures (32bit and 64bit), you?ll need to `rrdtool dump`, and implement a bit of batching. Other than that, you should just be able to transfer the RRAs as is. Transfer them a couple of hundred at a time, or as fast as you can manage within the limits of your disk IOPS, and then just have it timed to run between your updates. Took me a shell 3-liner to move 15k RRAs about 2 years ago. -J From matthias at leisi.net Wed Mar 26 10:11:18 2014 From: matthias at leisi.net (Matthias Leisi) Date: Wed, 26 Mar 2014 11:11:18 +0100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: On Wed, Mar 26, 2014 at 4:16 AM, Jimmy Hess wrote: > Would it make it more unique; if I suggested creation of a new distributed > Cryptocurrency something like 'MAILCoin' to track the memberships in the > club and handle voting out of abusive mail servers: in a distributed > manner, to ensure that no court could ever mandate that a certain IP > address be accepted into the club? > "voting out" - in today's world we need to assume that spammers and other criminals have vastly more resources than what may be considered (sort of) good guys. For the same mechanism a CPU-bound cryptocurrency is not likely to succeed. -- Matthias From matthias at leisi.net Wed Mar 26 10:18:14 2014 From: matthias at leisi.net (Matthias Leisi) Date: Wed, 26 Mar 2014 11:18:14 +0100 Subject: misunderstanding scale In-Reply-To: <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> Message-ID: On Wed, Mar 26, 2014 at 6:31 AM, Owen DeLong wrote: > OTOH, a spammer with a single /64, pretty much the absolute minimum IPv6 > block, has more than 18 quintillion addresses and there's not a computer on > the planet with enough memory (or probably not even enough disk space) to > store that block list. > It only takes a single entry if you do not store /128s but that /64. Yes, RBL lookups do not currently know how to handle this, but there are a couple of good proposals around on how to do it. This would also reduce the risks from cache depletion attacks via DNSxL lookups to IPv4 levels. Sometimes scale is everything. host-based reputation lists scale easily to > 3.2 billion host addresses. IPv6, not so easily. > As soon as we get away from host-centric-view to a network-block-view, things get pretty straightforward. -- Matthias From dot at dotat.at Wed Mar 26 10:30:12 2014 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Mar 2014 10:30:12 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> References: <20140325175603.5423.qmail@joyce.lan> <5331EDAB.8000303@2mbit.com> <04EE0477-BBE2-47B5-ABAE-9F62887E5F4B@heliacal.net> Message-ID: Laszlo Hanyecz wrote: > The usefulness of reverse DNS in IPv6 is dubious. For most systems yes, but you might as well have it if you are manually allocating server addresses. Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes: Variable 4, becoming southeast 5 or 6. Moderate or rough. Fair. Good. From rsk at gsp.org Wed Mar 26 12:36:10 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 26 Mar 2014 08:36:10 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140325233557.6311.qmail@joyce.lan> References: <3D7D0845-CB25-4C05-8FAB-F5728C8602DD@heliacal.net> <20140325233557.6311.qmail@joyce.lan> Message-ID: <20140326123610.GA20685@gsp.org> On Tue, Mar 25, 2014 at 11:35:57PM -0000, John Levine wrote: > It has nothing to do with looking down on "subscribers" and everything > to do with practicality. When 99,9% of mail sent directly from > consumer IP ranges is botnet spam, and I think that's a reasonable > estimate, [...] Data point: it's an extremely reasonable estimate. If anything, though, it's an underestimate: the actual rate has several more 9's in it. And if the sending host (a) has generic rDNS and/or (b) fingerprints as Windows, then it approaches 100% so closely as to not be worth arguing about. There is no point in performing any checks other than these on SMTP connections from such hosts. There is no reason to permit the conversation to continue to the DATA stage and to scrutinize the message contents. These actions are both wasteful and superfluous. The only correct action to take at this point is to issue an SMTP reject and end the conversation. It's a pity that this is true. But a decade-plus after the botnet problem became well-known, I can't name an ISP which has developed and deployed an effective mitigation strategy against them. So far it's been band-aids (blocking port 25) and PR (press conferences and initiatives and task forces etc.). ("botnet takedowns" are meaningless fluff and merely fodder for self-congratulatory press conferences. All those systems in the botnet are still compromised. All those systems are still vulnerable to the same attack vectors that resulted in their initial compromise. And quite likely before the ink is dry on the accompanying press release, other botnet operations will harvest them for use in their own operations. Meet the new boss, same as the old boss.) ---rsk From dtaylor at vocalabs.com Wed Mar 26 12:45:06 2014 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Wed, 26 Mar 2014 07:45:06 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <20140326041858.7576.qmail@joyce.lan> References: <20140326041858.7576.qmail@joyce.lan> Message-ID: <5332CBD2.2030008@vocalabs.com> On 03/25/2014 11:18 PM, John Levine wrote: >> 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with >> one?s own combat boots. And not particularly productive. > If you can figure out how to do effective spam filtering without > looking at the IP addresses from which mail arrives, you will be in a > position to make a whole lot of money. > > But, as always, I'm not holding my breath. > > R's, > John > > PS: Note the word "effective". > You look at the IP, and verify forward and reverse DNS. IPv6 doesn't make this any harder a problem than IPv4, it just means that we're going to *have* to reject mail that comes in from IPv6 addresses that don't have clean DNS. -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From rwebb at ropeguru.com Wed Mar 26 12:55:31 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Wed, 26 Mar 2014 08:55:31 -0400 Subject: A little silly for IPv6 In-Reply-To: <53325754.9040609@cox.net> References: <53325754.9040609@cox.net> Message-ID: On Tue, 25 Mar 2014 23:28:04 -0500 Larry Sheldon wrote: > According to the Ace of Spades HQ blog: > >> IPv6 would allow every atom on the surface of the earth to have its >> own IP address, with enough spare to do Earth 100+ times. > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability >to > learn from their mistakes. > (Adapted from Stephen >Pinker) > I want to see HIS source of hpow many atoms are actually on the earth. Somehow, I do not think anyone knows that answer. So his comparision is a joke. Robert From rwebb at ropeguru.com Wed Mar 26 13:05:52 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Wed, 26 Mar 2014 09:05:52 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <5332CBD2.2030008@vocalabs.com> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> Message-ID: On Wed, 26 Mar 2014 07:45:06 -0500 Daniel Taylor wrote: > On 03/25/2014 11:18 PM, John Levine wrote: >>> 3. Arguing about IPv6 in the context of requirements upon SMTP >>>connections is playing that uncomfortable game with >>> one?s own combat boots. And not particularly productive. >> If you can figure out how to do effective spam filtering without >> looking at the IP addresses from which mail arrives, you will be in >>a >> position to make a whole lot of money. >> >> But, as always, I'm not holding my breath. >> >> R's, >> John >> >> PS: Note the word "effective". >> > You look at the IP, and verify forward and reverse DNS. > > IPv6 doesn't make this any harder a problem than IPv4, it just means >that we're going to *have* to reject mail that comes in from IPv6 >addresses that don't have clean DNS. > > -- > Daniel Taylor VP Operations Vocal Laboratories, >Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ > (612)235-5711 > > Actually, with all the discussion about ipv6 not having rDNS, in most cases, would that not make things easier? So those that want to run email servers SHOULD be on ISP's that allow for rDNS configuration for IPv6. There should be some vetting in the process by the ISP, maybe, before allowing this. So in essence, if you are a legitimate email host, you will have rDNS configured on IPv6 for your server. Again, as others have stated, rDNS should NOT be the only deciding factor in whether or not an email is legit. No rDNS, or havinf rDNS, should have some weight assigned to it for the overall evaluation of the sender. Robert From gary.buhrmaster at gmail.com Wed Mar 26 13:06:15 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 26 Mar 2014 13:06:15 +0000 Subject: A little silly for IPv6 In-Reply-To: References: <53325754.9040609@cox.net> Message-ID: On Wed, Mar 26, 2014 at 12:55 PM, rwebb at ropeguru.com wrote: ..... > I want to see HIS source of hpow many atoms are actually on the earth. > Somehow, I do not think anyone knows that answer. So his comparision is a > joke. Obligatory xkcd ref: https://xkcd.com/865/ From contact at winterei.se Wed Mar 26 13:08:25 2014 From: contact at winterei.se (Paul S.) Date: Wed, 26 Mar 2014 22:08:25 +0900 Subject: A little silly for IPv6 In-Reply-To: References: <53325754.9040609@cox.net> Message-ID: <5332D149.4050403@winterei.se> Of course it is, you don't even need to think about logic to answer that one. On 3/26/2014 ?? 09:55, rwebb at ropeguru.com wrote: > On Tue, 25 Mar 2014 23:28:04 -0500 > Larry Sheldon wrote: >> According to the Ace of Spades HQ blog: >> >>> IPv6 would allow every atom on the surface of the earth to have its >>> own IP address, with enough spare to do Earth 100+ times. >> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >> > > I want to see HIS source of hpow many atoms are actually on the earth. > Somehow, I do not think anyone knows that answer. So his comparision > is a joke. > > Robert > From rwebb at ropeguru.com Wed Mar 26 13:19:14 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Wed, 26 Mar 2014 09:19:14 -0400 Subject: A little silly for IPv6 In-Reply-To: References: <53325754.9040609@cox.net> Message-ID: I would support THIS as a better reference than some of the other email responses I have gotten. Again comparing something like factual numbers of IPv6 addresses the the very fuzzy math of guessing how many atoms there are is very silly indeed. On Wed, 26 Mar 2014 13:06:15 +0000 Gary Buhrmaster wrote: > On Wed, Mar 26, 2014 at 12:55 PM, rwebb at ropeguru.com > wrote: > ..... >> I want to see HIS source of hpow many atoms are actually on the >>earth. >> Somehow, I do not think anyone knows that answer. So his comparision >>is a >> joke. > > Obligatory xkcd ref: https://xkcd.com/865/ From asullivan at dyn.com Wed Mar 26 13:38:14 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 26 Mar 2014 09:38:14 -0400 Subject: IPv6 isn't SMTP In-Reply-To: References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> Message-ID: <20140326133813.GB49668@dyn.com> On Wed, Mar 26, 2014 at 09:05:52AM -0400, rwebb at ropeguru.com wrote: > most cases, would that not make things easier? So those that want to > run email servers SHOULD be on ISP's that allow for rDNS > configuration for IPv6. Several years ago now the IETF DNSOP WG worked on a document about reverse mapping. The topic was so controversial that the final version of the document, which said little more than, "There is a reverse tree, and you might want to take that into consideration. Or not. It's up to you," still couldn't get consensus. I think anything that involves making rules about others' reverse maps is probably an excellent way to attract ducks to nibble you to death. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From rsk at gsp.org Wed Mar 26 13:59:05 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 26 Mar 2014 09:59:05 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <20140326135905.GA7829@gsp.org> On Tue, Mar 25, 2014 at 10:16:37PM -0500, Jimmy Hess wrote: > Would it make it more unique; if I suggested creation of a new distributed > Cryptocurrency something like 'MAILCoin' [...] This is attempt to splash a few drops of water on the people who own the oceans. It won't work, for the same reasons that the last 1,723 very similar proposals won't work. ---rsk From lowen at pari.edu Wed Mar 26 14:07:22 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 10:07:22 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <5332DF1A.9040001@pari.edu> On 03/25/2014 10:51 PM, Jimmy Hess wrote: > > [snip] > > I would suggest the formation of an "IPv6 SMTP Server operator's club," > with a system for enrolling certain IP address source ranges as "Active > mail servers", active IP addresses and SMTP domain names under the > authority of a member. > ... As has been mentioned, this is old hat. There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. That way? Make e-mail cost; have e-postage. No, I don't want it either. But where is the pain point for spam where this becomes less painful? If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots. This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it. That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one. If spam ceases to be profitable, it will stop. Of course, I reserve the right to be wrong, and this might all just be a pipe dream. (and yes, I've thought about what sort of billing infrastructure nightmare this could be.....) From laszlo at heliacal.net Wed Mar 26 14:33:14 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 26 Mar 2014 14:33:14 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5332DF1A.9040001@pari.edu> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> Message-ID: <911CEC5C-2011-4C8D-9CC1-89DF2B4CB2C1@heliacal.net> Maybe you should focus on delivering email instead of refusing it. Or just keep refusing it and trying to bill people for it, until you make yourself irrelevant. The ISP based email made more sense when most end users - the people that we serve - didn't have persistent internet connections. Today, most users are always connected, and can receive email directly to our own computers, without a middle man. With IPv6 it's totally feasible since unique addressing is no longer a problem - there's no reason why every user can't have their own MTA. The problem is that there are many people who are making money off of email - whether it's the sending of mail or the blocking of it - and so they're very interested in breaking direct email to get 'the users' to rely on them. It should be entirely possible to build 'webmail' into home user CPEs or dedicated mailbox appliances, and let everyone deal with their own email delivery. The idea of having to pay other people to host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering the same ground. It boils down to: we have an old crappy system that works, and we don't want to change, because we've come to rely on the flaws of it and don't want them fixed. In the email case, people have figured out how to make money doing it, so they certainly want to keep their control over it. -Laszlo On Mar 26, 2014, at 2:07 PM, Lamar Owen wrote: > On 03/25/2014 10:51 PM, Jimmy Hess wrote: >> >> [snip] >> >> I would suggest the formation of an "IPv6 SMTP Server operator's club," >> with a system for enrolling certain IP address source ranges as "Active >> mail servers", active IP addresses and SMTP domain names under the >> authority of a member. >> > ... > > As has been mentioned, this is old hat. > > There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. > > That way? Make e-mail cost; have e-postage. No, I don't want it either. But where is the pain point for spam where this becomes less painful? If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots. This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it. That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one. If spam ceases to be profitable, it will stop. > > Of course, I reserve the right to be wrong, and this might all just be a pipe dream. (and yes, I've thought about what sort of billing infrastructure nightmare this could be.....) > From dtaylor at vocalabs.com Wed Mar 26 15:25:38 2014 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Wed, 26 Mar 2014 10:25:38 -0500 Subject: IPv6 isn't SMTP In-Reply-To: References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> Message-ID: <5332F172.10908@vocalabs.com> On 03/26/2014 08:05 AM, rwebb at ropeguru.com wrote: > On Wed, 26 Mar 2014 07:45:06 -0500 > Daniel Taylor wrote: >> On 03/25/2014 11:18 PM, John Levine wrote: >>>> 3. Arguing about IPv6 in the context of requirements upon SMTP >>>> connections is playing that uncomfortable game with >>>> one?s own combat boots. And not particularly productive. >>> If you can figure out how to do effective spam filtering without >>> looking at the IP addresses from which mail arrives, you will be in a >>> position to make a whole lot of money. >>> >>> But, as always, I'm not holding my breath. >>> >>> R's, >>> John >>> >>> PS: Note the word "effective". >>> >> You look at the IP, and verify forward and reverse DNS. >> >> IPv6 doesn't make this any harder a problem than IPv4, it just means >> that we're going to *have* to reject mail that comes in from IPv6 >> addresses that don't have clean DNS. >> >> -- >> Daniel Taylor VP Operations Vocal Laboratories, Inc. >> dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 >> >> > > Actually, with all the discussion about ipv6 not having rDNS, in most > cases, would that not make things easier? So those that want to run > email servers SHOULD be on ISP's that allow for rDNS configuration for > IPv6. There should be some vetting in the process by the ISP, maybe, > before allowing this. So in essence, if you are a legitimate email > host, you will have rDNS configured on IPv6 for your server. Again, as > others have stated, rDNS should NOT be the only deciding factor in > whether or not an email is legit. No rDNS, or havinf rDNS, should have > some weight assigned to it for the overall evaluation of the sender. > > Robert If you can't get rDNS on a mail host from your ISP, I'd say you are on the wrong ISP if you want to run your own mail server. This goes for IPv6 and IPv4 equally. -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From jbates at brightok.net Wed Mar 26 15:35:30 2014 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Mar 2014 10:35:30 -0500 Subject: BiLateral Transit Agreements? Message-ID: <5332F3C2.6000309@brightok.net> Does anyone have experience with BiLateral Transit Agreements, compared to the same with Peering Agreements? I have 2 ISP customers that are looking at such an agreement. While I can modify the standard BLPA templates to support transit provisions, I was curious if anyone had done so and what pitfalls to look for or considerations that should be made. Our particular case is high cost transport, so both companies are looking at each having a Tier 1 transit and then supporting the second through their agreement. Jack Bates From rsk at gsp.org Wed Mar 26 16:01:58 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 26 Mar 2014 12:01:58 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5332DF1A.9040001@pari.edu> References: <5332DF1A.9040001@pari.edu> Message-ID: <20140326160158.GA14101@gsp.org> On Wed, Mar 26, 2014 at 10:07:22AM -0400, Lamar Owen wrote: > That way? Make e-mail cost; have e-postage. This is a FUSSP. It has been quite thoroughly debunked and may be dismissed instantly, with prejudice. ---rsk From psirt at cisco.com Wed Mar 26 16:07:45 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Mar 2014 12:07:45 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability Message-ID: <201403261207.17.sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-sip Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary ======= A vulnerability in the Session Initiation Protocol (SIP) implementation in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of an affected device. To exploit this vulnerability, affected devices must be configured to process SIP messages. Limited Cisco IOS Software and Cisco IOS XE Software releases are affected. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that must run SIP; however, mitigations are available to limit exposure to this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-sip Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUuAAoJEIpI1I6i1Mx3NjYP/0etuiRKILQ2sFGrwyA+vUc+ af04L8J24D4/7/qQJ9YsZekjol0u0+vJIhHEMzqeRKiv4qUwHudtzgDLn6svASRR djFwz5QzPkrheF/Xk+tKT4NkDcPrr4MWH5j8zRltfYdRgQHVzGeV7u6JorOAlV3b m8Tkg6+sl4rTBw0tky8swM5H35p9UOnDzlFlzx6WNUGZFrv83wbj9L2ZdcDzXSdl 0jXw1xue9DEpksC3A2KNq9zIrizEJGfx97jhhRG0OsK/3gbO3ESFGr6wbkakLZNS WJmCgk82tiT2mM8/FulyPvdpuDAc5y0br+W0I0O0gABZmOoix0DT3NlJXh5hd48y 5iJ5s15D0Og3jJq3nzC8U2za+lMLcDsm4WGgWsY7UvzMWJ24u1Q4LP0Ios5r7bHV MF9CyWSxxqFO3pWBQw53HZhBDmk4rl3iDHSAytHVEjNlrmKAY/Q5MHZpMER1yQIO O9ER61S6eXTS6yCcoFf7cpdBvZR08C9PS/geOmv+5znJ4AbpzCdrQYUDZlcL/DhW jGZ/cvgytw3zPYozPYSFqnB/aadcA3xHeTjba9qsHlo8tAlJqUGIlIzzGsag1yuW rUSjLrnEUDiy0cGxq/tZsERiyUVWtafsc/F6/dshp27LB7Ih8ulOvpTEIMzZKAnv 8sx8s3vq7KEIpWUpj1ak =e0Cj -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 26 16:08:19 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Mar 2014 12:08:19 -0400 Subject: Cisco Security Advisory: Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks Denial of Service Vulnerability Message-ID: <201403261208.17.RSP72010GE@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-RSP72010GE Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary ======= A vulnerability in the Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks models RSP720-3C-10GE and RSP720-3CXL-10GE could allow an unauthenticated, remote attacker to cause the route processor to reboot or stop forwarding traffic. The vulnerability is due to an issue in the Kailash field-programmable gate array (FPGA) versions prior to 2.6. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-RSP72010GE Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUsAAoJEIpI1I6i1Mx3QqEP/1W/RvtG5zkMAVcGxT/fmT57 YsEGW6+znRSsE7VLq4R6040SQYqJemtkdrug6PB5Ie1IWySd6Qv6FA5nAwtrRqaY aSyVSxXt0ta+zmoSlYqidQl+X+oLTWf4hbkKae2DUqlPSoRadyKzp4Fz6GARolka V1P6dCwXKYo+y8444cilT5iw28RajMYDFVBv8pl1j1O20ts8gLskq1sqQaZneYKZ dS8N4yaIOtRp+6hMtH3dcRDm0dy880l4yrBN+4sOC/Pf/oTRiwkhYUXZaDqOme4R K1rWArmc9tkFMGar5j4wVWYk0B8cdOu5+FQ/1hbd2PxgLpvFylDZ/5W83hnK9J4g HTgE9vQ3BDeJkoxLupOksTRxqYgxUzYCs1LfcCNoNbQTOs8tAidQyzng3Rhw3/Ty mB3dTOaR1giqnnp6HNbRzxmw1j7m2kOfkoNhrcLMcO+2R+SaBmG4IHtRoEeABGdc H19Nv7Y/GFug1AY9ntHOyMw1urVa7Dperb22mSqeeF4HPZoYlAYJG0itwkpmdI+R E8STnyi+Hx2LmjEUc59SSLpS0n1ciBRii6CG+hFUUPCDdyJpdGYgVYbOtn3g0YHw 5OR4qK2/hWNOFQ+6DIjhYvXecLEmGltJ1rMxdFdtgH5JT2IAZsdoUHko9b9PRTJ7 J+6y3e8dU2EfXhK7GuFA =RDpO -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 26 16:08:52 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Mar 2014 12:08:52 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Internet Key Exchange Version 2 Denial of Service Vulnerability Message-ID: <201403261208.17.ikev2@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Internet Key Exchange Version 2 Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ikev2 Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary ======= A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of the affected device that would lead to a denial of service (DoS) condition. The vulnerability is due to how an affected device processes certain malformed IKEv2 packets. An attacker could exploit this vulnerability by sending malformed IKEv2 packets to an affected device to be processed. An exploit could allow the attacker to cause a reload of the affected device that would lead to a DoS condition. Although IKEv2 is automatically enabled on Cisco IOS Software and Cisco IOS XE Software devices when the Internet Security Association and Key Management Protocol (ISAKMP) is enabled, the vulnerability can be triggered only by sending a malformed IKEv2 packet. Only IKEv2 packets can trigger this vulnerability. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ikev2 Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3JYsQAJSSBgUo2Fq6HUJ1Rq/YlpEf S0FE1xiO9M+pD9w+gloAm+r86TTVrvi8eTsguHnm9I7aZBkKK72Fr6en/ywx7+c2 vqNt7sgfu2EHsK45zgYFMzYIOGomydamV6YixO7wvrnhWKjAHfcO51Ks7SPam2y2 2nTAGnifDcbQGcuneKyr61aob361E1UYpqlq4CK0+hEbx9VzCM2DuidiAOqCgtlA xtzw8Eu/8PP0baBi2DM7N/wlMMVTHNLXguSJNvsQxMnkvyoPObCXucSRvAPb5lSh s38f0kZKQSLcVorkelzT5G7Ht7PxqFJAeghongQW77XEoQ0ERi/isuKHKM16AM+F NCMrWeeNCw3Fcpp9lFu7dmnQx/CAdApB26UEnRifN5dp+wPxk7Jzb/Y/H5jMH+vr XxpzCGvDD8Nlm6PaBbP/leezuBUjWv61xKeeJup/thsl6/lJVsrgFScvQNfXP49x IwPvgFx+u67PIkE0+873+JmrPENNUAY7Le6OmA6UyCewY4seDByEbG9AdigmQAR4 yWUUTe2iFAYKuVKshcrOnCX83qM2K6RNBTbQXS0YrE0gx/f71PdiEs4jiUeSh9aO rJsqX1EJa5QWeOgSlSpNJs/RCs1szchnYcKA2FGmF7sQPYHehY5X8rOistgSCRyd SUNxQ9T/HDRmOpXM85n8 =XFWb -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 26 16:09:26 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Mar 2014 12:09:26 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities Message-ID: <201403261209.17.nat@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Network Address Translation Vulnerabilities Advisory ID: cisco-sa-20140326-nat Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary The Cisco IOS Software implementation of the Network Address Translation (NAT) feature contains two vulnerabilities when translating IP packets that could allow an unauthenticated, remote attacker to cause a denial of service condition. Cisco has released free software updates that address these vulnerabilities. There are no workarounds to mitigate these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-nat Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUuAAoJEIpI1I6i1Mx3WmEQAI3rKhU7UnKxev8CKq4Hfp5I mBnX5uHKz+w5vNqgTPYL6y228XHsicFZKNfR9Z2PiyHjwdFq3ndZACYRiK5iKxme oRO3fLAv3Muhb0F0f4j8p6NvzDoE9uZMqIlvG709+VtFhwKeW6aziV9FPNVNbe33 Jnub4qi3AINnxalKiGixmN52rCkNficlHTgbsmvRscqF0NYVos4L+CEcuukyohOV jr41sRLO9/IvY1cwPtkQ5FHI/YLvD7/P1wzVr13eJkTdS28oD0Jo1yArvQJBf+Ae fvlnhoprtAhkGUSYlyUKF5HOCe8lScYMKvfP5Of56yLr+0RQuJty4X4hCX4+HbPd g3AI2yOUHGixLZAVV8GEsnbBtPnenPjqe7EAapyMT+YZx4ocD2dUPMfQTUcUye1r rOQeQjI+vX8NLzlS1paV0vImuN0rJi1phi4/Ne+XT5qSGic3tMZVGm8rsWiMNB8l qosaCwAXUx75KraBU2g8pe8iwmUSGQPFLZoMNkKjez/oEBKXAsCMgZYzsZpht4tg kiDMU2W7OlVPkMcg6Jym/L6bLSzCUekkSREshd2KxzLm4hRSZOX36RNL5wKGjCxQ 94myZA59h4L53lmLUYpsqH6KJafW7NPL/u+YQOQ6qO9iH8c/m04mVCQ2Y05rtDPX OZnQJUm5po9ws6ylHFKw =7Q5K -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 26 16:10:00 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Mar 2014 12:10:00 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Message-ID: <201403261210.17.ios@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software SSL VPN Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ios-sslvpn Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary ======= A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco IOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability is due to a failure to process certain types of HTTP requests. To exploit the vulnerability, an attacker could submit crafted requests designed to consume memory to an affected device. An exploit could allow the attacker to consume and fragment memory on the affected device. This may cause reduced performance, a failure of certain processes, or a restart of the affected device. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 RF3x0wYuErbbC7N9m1UH =1Ixo -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 26 16:10:35 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Mar 2014 12:10:35 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability Message-ID: <201403261210.17.ipv6@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ipv6 Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary ======= A vulnerability in the implementation of the IP version 6 (IPv6) protocol stack in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause I/O memory depletion on an affected device that has IPv6 enabled. The vulnerability is triggered when an affected device processes a malformed IPv6 packet. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ipv6 Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx35GAP/jkk82q87zMnC9n9e2t9u1DD 7OHUYo7fuXu2L85+zDGgtE7LJ5c9mjZou12A87cjgx4v1B6xvDoemjtoIEmqWKQR LsSoI6oQL6E3PAqeDn70Lrr++kAV/4dCSzoFuiDWa5NLWO2NA1pxoRsF8f/KTENj PvPng8UPlF2WBDqNdTnjR2upDMqn1/jQOMxSSRmkMAOQ0Q3j+g9Pd+rb8ocqTJmg wCj5vXfB52E0HoGddT0UxjkxL1+CR9Jo262LeuRRtMGQsEpK94+L9d4kC/AhhclU RodAJztNC42KdFR4iE1jDHUA8HwhgnkdzuXlA12GIXeHB9EBQR5Te1hyzuAnxq5X x3IeqZnaufO2DmxAVpl3lfEDyKeyAipfCPDtFhEmDF/l12zBRlbMudEwA1Buwriq ayH4798ASI0bBumUiaMiiOyYKbqFL33ONdFMiQZv2lYam1QlYU0Ps3IMiZhD5YHX 9nOKcuWU1Uym+VjHiIKLg5/qQpndg9h+E6mNzZrQSXrpU1nYtwBCZiShBhR5+f4J WYLOVZu5LDpW6mQAhYyKC7ehugeqJZRaZQQX5oi94hlBxz1+4zin8GRVLn/Ibrtq GaeMGODALQjpolszEAt7a4QA5884m++h7Z4Crszr4s4E4j4bUdCEgDc9ynInmO80 OvU1rCkvg7QWSv3HfxI2 =nr53 -----END PGP SIGNATURE----- From rwebb at ropeguru.com Wed Mar 26 16:45:18 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Wed, 26 Mar 2014 12:45:18 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <201403261210.17.ios@psirt.cisco.com> References: <201403261210.17.ios@psirt.cisco.com> Message-ID: Is this normal for the list to diretly get Cisco security advisories or something new. First time I have seen these. Robert On Wed, 26 Mar 2014 12:10:00 -0400 Cisco Systems Product Security Incident Response Team wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Cisco IOS Software SSL VPN Denial of Service Vulnerability > > Advisory ID: cisco-sa-20140326-ios-sslvpn > > Revision 1.0 > >For Public Release 2014 March 26 16:00 UTC (GMT) > > Summary > ======= > > A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of >Cisco IOS Software could allow an unauthenticated, remote attacker to >cause a denial of service (DoS) condition. > > The vulnerability is due to a failure to process certain types of >HTTP requests. To exploit the vulnerability, an attacker could submit >crafted requests designed to consume memory to an affected device. An >exploit could allow the attacker to consume and fragment memory on >the affected device. This may cause reduced performance, a failure of >certain processes, or a restart of the affected device. > > Cisco has released free software updates that address this >vulnerability. > There are no workarounds to mitigate this vulnerability. > > This advisory is available at the following link: > http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn > > Note: The March 26, 2014, Cisco IOS Software Security Advisory >bundled publication includes six Cisco Security Advisories. All >advisories address vulnerabilities in Cisco IOS Software. Each Cisco >IOS Software Security Advisory lists the Cisco IOS Software releases >that correct the vulnerability or vulnerabilities detailed in the >advisory as well as the Cisco IOS Software releases that correct all >Cisco IOS Software vulnerabilities in the March 2014 bundled >publication. > > Individual publication links are in Cisco Event Response: Semiannual >Cisco IOS Software Security Advisory Bundled Publication at the >following link: > > http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ > mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i > uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc > X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd > atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn > dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo > RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 > 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ > 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd > EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB > ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 > RF3x0wYuErbbC7N9m1UH > =1Ixo > -----END PGP SIGNATURE----- > From james at jamesstewartsmith.com Wed Mar 26 16:51:55 2014 From: james at jamesstewartsmith.com (james at jamesstewartsmith.com) Date: Wed, 26 Mar 2014 16:51:55 +0000 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: <877642205-1395852716-cardhu_decombobulator_blackberry.rim.net-2093927812-@b17.c12.bise6.blackberry> They don't come out often but it happens. Looks like there were 5 or 6 of them. James -----Original Message----- From: "rwebb at ropeguru.com" Date: Wed, 26 Mar 2014 12:45:18 To: ; Reply-To: Robert Webb Subject: Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Is this normal for the list to diretly get Cisco security advisories or something new. First time I have seen these. Robert On Wed, 26 Mar 2014 12:10:00 -0400 Cisco Systems Product Security Incident Response Team wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Cisco IOS Software SSL VPN Denial of Service Vulnerability > > Advisory ID: cisco-sa-20140326-ios-sslvpn > > Revision 1.0 > >For Public Release 2014 March 26 16:00 UTC (GMT) > > Summary > ======= > > A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of >Cisco IOS Software could allow an unauthenticated, remote attacker to >cause a denial of service (DoS) condition. > > The vulnerability is due to a failure to process certain types of >HTTP requests. To exploit the vulnerability, an attacker could submit >crafted requests designed to consume memory to an affected device. An >exploit could allow the attacker to consume and fragment memory on >the affected device. This may cause reduced performance, a failure of >certain processes, or a restart of the affected device. > > Cisco has released free software updates that address this >vulnerability. > There are no workarounds to mitigate this vulnerability. > > This advisory is available at the following link: > http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn > > Note: The March 26, 2014, Cisco IOS Software Security Advisory >bundled publication includes six Cisco Security Advisories. All >advisories address vulnerabilities in Cisco IOS Software. Each Cisco >IOS Software Security Advisory lists the Cisco IOS Software releases >that correct the vulnerability or vulnerabilities detailed in the >advisory as well as the Cisco IOS Software releases that correct all >Cisco IOS Software vulnerabilities in the March 2014 bundled >publication. > > Individual publication links are in Cisco Event Response: Semiannual >Cisco IOS Software Security Advisory Bundled Publication at the >following link: > > http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ > mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i > uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc > X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd > atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn > dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo > RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 > 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ > 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd > EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB > ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 > RF3x0wYuErbbC7N9m1UH > =1Ixo > -----END PGP SIGNATURE----- > From swmike at swm.pp.se Wed Mar 26 16:58:40 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Mar 2014 17:58:40 +0100 (CET) Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: On Wed, 26 Mar 2014, rwebb at ropeguru.com wrote: > Is this normal for the list to diretly get Cisco security advisories or > something new. First time I have seen these. They do this twice a year, all their advisories were sent here about half a year ago as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From lathama at gmail.com Wed Mar 26 16:58:44 2014 From: lathama at gmail.com (Andrew Latham) Date: Wed, 26 Mar 2014 12:58:44 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: Robert Perfectly normal, almost an announce list for issues like this. On Wed, Mar 26, 2014 at 12:45 PM, rwebb at ropeguru.com wrote: > > Is this normal for the list to diretly get Cisco security advisories or > something new. First time I have seen these. > > Robert > > > On Wed, 26 Mar 2014 12:10:00 -0400 > Cisco Systems Product Security Incident Response Team > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Cisco IOS Software SSL VPN Denial of Service Vulnerability >> >> Advisory ID: cisco-sa-20140326-ios-sslvpn >> >> Revision 1.0 >> >> For Public Release 2014 March 26 16:00 UTC (GMT) >> >> Summary >> ======= >> >> A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco >> IOS Software could allow an unauthenticated, remote attacker to cause a >> denial of service (DoS) condition. >> >> The vulnerability is due to a failure to process certain types of HTTP >> requests. To exploit the vulnerability, an attacker could submit crafted >> requests designed to consume memory to an affected device. An exploit could >> allow the attacker to consume and fragment memory on the affected device. >> This may cause reduced performance, a failure of certain processes, or a >> restart of the affected device. >> >> Cisco has released free software updates that address this vulnerability. >> There are no workarounds to mitigate this vulnerability. >> >> This advisory is available at the following link: >> >> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn >> >> Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled >> publication includes six Cisco Security Advisories. All advisories address >> vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security >> Advisory lists the Cisco IOS Software releases that correct the >> vulnerability or vulnerabilities detailed in the advisory as well as the >> Cisco IOS Software releases that correct all Cisco IOS Software >> vulnerabilities in the March 2014 bundled publication. >> >> Individual publication links are in Cisco Event Response: Semiannual Cisco >> IOS Software Security Advisory Bundled Publication at the following link: >> >> http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ >> mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i >> uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc >> X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd >> atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn >> dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo >> RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 >> 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ >> 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd >> EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB >> ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 >> RF3x0wYuErbbC7N9m1UH >> =1Ixo >> -----END PGP SIGNATURE----- >> > > -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From rwebb at ropeguru.com Wed Mar 26 16:59:39 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Wed, 26 Mar 2014 12:59:39 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: Thanks everyone for the replies. I guess since they are done so infrequently, I was not a list member the last go around. Robert On Wed, 26 Mar 2014 12:58:44 -0400 Andrew Latham wrote: > Robert > > Perfectly normal, almost an announce list for issues like this. > > On Wed, Mar 26, 2014 at 12:45 PM, rwebb at ropeguru.com > wrote: >> >> Is this normal for the list to diretly get Cisco security advisories >>or >> something new. First time I have seen these. >> >> Robert >> >> >> On Wed, 26 Mar 2014 12:10:00 -0400 >> Cisco Systems Product Security Incident Response Team >> >> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Cisco IOS Software SSL VPN Denial of Service Vulnerability >>> >>> Advisory ID: cisco-sa-20140326-ios-sslvpn >>> >>> Revision 1.0 >>> >>> For Public Release 2014 March 26 16:00 UTC (GMT) >>> >>> Summary >>> ======= >>> >>> A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of >>>Cisco >>> IOS Software could allow an unauthenticated, remote attacker to >>>cause a >>> denial of service (DoS) condition. >>> >>> The vulnerability is due to a failure to process certain types of >>>HTTP >>> requests. To exploit the vulnerability, an attacker could submit >>>crafted >>> requests designed to consume memory to an affected device. An >>>exploit could >>> allow the attacker to consume and fragment memory on the affected >>>device. >>> This may cause reduced performance, a failure of certain processes, >>>or a >>> restart of the affected device. >>> >>> Cisco has released free software updates that address this >>>vulnerability. >>> There are no workarounds to mitigate this vulnerability. >>> >>> This advisory is available at the following link: >>> >>> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn >>> >>> Note: The March 26, 2014, Cisco IOS Software Security Advisory >>>bundled >>> publication includes six Cisco Security Advisories. All advisories >>>address >>> vulnerabilities in Cisco IOS Software. Each Cisco IOS Software >>>Security >>> Advisory lists the Cisco IOS Software releases that correct the >>> vulnerability or vulnerabilities detailed in the advisory as well as >>>the >>> Cisco IOS Software releases that correct all Cisco IOS Software >>> vulnerabilities in the March 2014 bundled publication. >>> >>> Individual publication links are in Cisco Event Response: Semiannual >>>Cisco >>> IOS Software Security Advisory Bundled Publication at the following >>>link: >>> >>> http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>> >>> iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ >>> mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i >>> uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc >>> X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd >>> atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn >>> dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo >>> RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 >>> 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ >>> 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd >>> EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB >>> ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 >>> RF3x0wYuErbbC7N9m1UH >>> =1Ixo >>> -----END PGP SIGNATURE----- >>> >> >> > > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From johnl at iecc.com Wed Mar 26 16:59:52 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 16:59:52 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5332DF1A.9040001@pari.edu> Message-ID: <20140326165952.13291.qmail@joyce.lan> >That way? Make e-mail cost; have e-postage. Gee, I wondered how long it would take for this famous bad idea to reappear. I wrote a white paper ten years ago explaining why e-postage is a bad idea, and there is no way to make it work. Nothing of any importance has changed since then. http://www.taugh.com/epostage.pdf R's, John PS: Yes, I've heard of Bitcoins. From johnl at iecc.com Wed Mar 26 17:09:06 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 17:09:06 -0000 Subject: misunderstanding scale, SMTP edition In-Reply-To: <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> Message-ID: <20140326170906.13315.qmail@joyce.lan> >OTOH, a spammer with a single /64, pretty much the absolute minimum IPv6 block, has more than 18 quintillion addresses >and there?s not a computer on the planet with enough memory (or probably not even enough disk space) to store that >block list. > >Sometimes scale is everything. host-based reputation lists scale easily to 3.2 billion host addresses. IPv6, not so easily. Quite right. If I were a spammer or an ESP who wanted to listwash, I could easily use a different IP addres for every single message I sent. R's, John From johnl at iecc.com Wed Mar 26 17:10:10 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 17:10:10 -0000 Subject: misunderstanding scale In-Reply-To: Message-ID: <20140326171010.13340.qmail@joyce.lan> >It only takes a single entry if you do not store /128s but that /64. Yes, >RBL lookups do not currently know how to handle this, but there are a >couple of good proposals around on how to do it. Sigh. See previous note on wny aggregating on /64 won't work. >This would also reduce the risks from cache depletion attacks via DNSxL >lookups to IPv4 levels. Sigh. See previous note on wny aggregating on /64 won't work. R's, John From streiner at cluebyfour.org Wed Mar 26 14:06:24 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 26 Mar 2014 10:06:24 -0400 (EDT) Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: These also get posted to other mailing lists, such as cisco-nsp. jms On Wed, 26 Mar 2014, rwebb at ropeguru.com wrote: > > Thanks everyone for the replies. I guess since they are done so infrequently, > I was not a list member the last go around. > > Robert > > On Wed, 26 Mar 2014 12:58:44 -0400 > Andrew Latham wrote: >> Robert >> >> Perfectly normal, almost an announce list for issues like this. >> >> On Wed, Mar 26, 2014 at 12:45 PM, rwebb at ropeguru.com >> wrote: >> > >> > Is this normal for the list to diretly get Cisco security advisories or >> > something new. First time I have seen these. >> > >> > Robert >> > >> > >> > On Wed, 26 Mar 2014 12:10:00 -0400 >> > Cisco Systems Product Security Incident Response Team >> > wrote: >> > > >> > > -----BEGIN PGP SIGNED MESSAGE----- >> > > Hash: SHA1 >> > > >> > > Cisco IOS Software SSL VPN Denial of Service Vulnerability >> > > >> > > Advisory ID: cisco-sa-20140326-ios-sslvpn >> > > >> > > Revision 1.0 >> > > >> > > For Public Release 2014 March 26 16:00 UTC (GMT) >> > > >> > > Summary >> > > ======= >> > > >> > > A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of >> > > Cisco >> > > IOS Software could allow an unauthenticated, remote attacker to cause a >> > > denial of service (DoS) condition. >> > > >> > > The vulnerability is due to a failure to process certain types of HTTP >> > > requests. To exploit the vulnerability, an attacker could submit >> > > crafted >> > > requests designed to consume memory to an affected device. An exploit >> > > could >> > > allow the attacker to consume and fragment memory on the affected >> > > device. >> > > This may cause reduced performance, a failure of certain processes, or >> > > a >> > > restart of the affected device. >> > > >> > > Cisco has released free software updates that address this >> > > vulnerability. >> > > There are no workarounds to mitigate this vulnerability. >> > > >> > > This advisory is available at the following link: >> > > >> > > http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn >> > > >> > > Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled >> > > publication includes six Cisco Security Advisories. All advisories >> > > address >> > > vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security >> > > Advisory lists the Cisco IOS Software releases that correct the >> > > vulnerability or vulnerabilities detailed in the advisory as well as >> > > the >> > > Cisco IOS Software releases that correct all Cisco IOS Software >> > > vulnerabilities in the March 2014 bundled publication. >> > > >> > > Individual publication links are in Cisco Event Response: Semiannual >> > > Cisco >> > > IOS Software Security Advisory Bundled Publication at the following >> > > link: >> > > >> > > http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html >> > > -----BEGIN PGP SIGNATURE----- >> > > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> > > Comment: GPGTools - http://gpgtools.org >> > > >> > > iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ >> > > mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i >> > > uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc >> > > X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd >> > > atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn >> > > dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo >> > > RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 >> > > 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ >> > > 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd >> > > EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB >> > > ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 >> > > RF3x0wYuErbbC7N9m1UH >> > > =1Ixo >> > > -----END PGP SIGNATURE----- >> > > >> > >> > >> >> >> >> -- >> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > > From lowen at pari.edu Wed Mar 26 17:26:35 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 13:26:35 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140326165952.13291.qmail@joyce.lan> References: <20140326165952.13291.qmail@joyce.lan> Message-ID: <53330DCB.7050607@pari.edu> On 03/26/2014 12:59 PM, John Levine wrote: >> That way? Make e-mail cost; have e-postage. > Gee, I wondered how long it would take for this famous bad idea to > reappear. > > I wrote a white paper ten years ago explaining why e-postage is a > bad idea, and there is no way to make it work. Nothing of any > importance has changed since then. > > http://www.taugh.com/epostage.pdf > And I remember reading this ten years ago. And I also remember thinking at the time that you missed one very important angle, and that is that the typical ISP has the technical capability to bill based on volume of traffic already, and could easily bill per-byte for any traffic with 'e-mail properties' like being on certain ports or having certain characteristics. Yeah, I'm well aware of the technical issues with that; I never said it was a good idea, but what is the alternative? I agree (and agreed ten years ago) with your assessment that the technical hurdles are large, but I disagree that they're completely insurmountable. At some point somebody is going to have to make an outgoing connection on port 25, and that would be the point of billing for the originating host. I don't like it, and I don't think it's a good idea, but the fact of the matter is that as long as spam is profitable there is going to be spam. Every technical anti-spam technique yet developed has a corresponding anti-anti-spam technique (bayesian filters? easy-peasy, just load Hamlet or the Z80 programmer's manual or somesuch as invisible text inside your e-mail, something I've seen in the past week (yes, I got a copy of the text for Zilog's Z80 manual inside spam this past week!). DNS BL's got you stopped? easy peasy, do a bit of address hopping.) The only way to finally and fully stop spam is financial motivation, there is no 'final' technical solution to spam; I and all my users wish there were. From johnl at iecc.com Wed Mar 26 17:28:04 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 17:28:04 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <911CEC5C-2011-4C8D-9CC1-89DF2B4CB2C1@heliacal.net> Message-ID: <20140326172804.13428.qmail@joyce.lan> In article <911CEC5C-2011-4C8D-9CC1-89DF2B4CB2C1 at heliacal.net> you write: >Maybe you should focus on delivering email instead of refusing it Since there is at least an order of magnitude more spam than real mail, I'll just channel Randy Bush and encourage my competitors to take your advice. R's, John From jbates at brightok.net Wed Mar 26 17:33:40 2014 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Mar 2014 12:33:40 -0500 Subject: misunderstanding scale, SMTP edition In-Reply-To: <20140326170906.13315.qmail@joyce.lan> References: <20140326170906.13315.qmail@joyce.lan> Message-ID: <53330F74.1040707@brightok.net> On 3/26/2014 12:09 PM, John Levine wrote: >> OTOH, a spammer with a single /64, pretty much the absolute minimum IPv6 block, has more than 18 quintillion addresses >> and there?s not a computer on the planet with enough memory (or probably not even enough disk space) to store that >> block list. >> >> Sometimes scale is everything. host-based reputation lists scale easily to 3.2 billion host addresses. IPv6, not so easily. > Quite right. If I were a spammer or an ESP who wanted to listwash, I > could easily use a different IP addres for every single message I sent. > > Which isn't too bad for the spam block lists, as they will usually escalate and block /64 and shorter anyways. It will be problematic for handling something like CBL, though. DHCP shifted occasionally, but not as often as IPv6 privacy addresses can. The botnet world is where the problems will arise, and not just for spam. It becomes even more problematic, as you don't know if you have multiple bots in a /64 (individual handouts via DHCPv6) or a single bot shifting within a /64 assignment, or given some layouts, perhaps shifting within a /48 assignment. Jack From lowen at pari.edu Wed Mar 26 17:36:03 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 13:36:03 -0400 Subject: misunderstanding scale, SMTP edition In-Reply-To: <20140326170906.13315.qmail@joyce.lan> References: <20140326170906.13315.qmail@joyce.lan> Message-ID: <53331003.3010405@pari.edu> On 03/26/2014 01:09 PM, John Levine wrote: > Quite right. If I were a spammer or an ESP who wanted to listwash, I > could easily use a different IP addres for every single message I > sent. R's, John Week before last I saw this in great detail, with nearly 100,000 messages sent to our users per day from probably the same spammer (lots of similarities, including an image payload with invisible anti-bayesian text and a .in TLD) where no two messages came from the same IP. It did all come from the same hosting provider, though, and at least for now that hoster's whole address space (all twenty blocks, varying between a /23 and a /17) is in my border router's deny acl for incoming on port 25. At least for now; I did send an e-mail out to the abuse contact, waited 72 hours, then but the blocks in the incoming acl. This hoster was adding rwhois entries for each /32 allocated (yes, IPv4 /32) and they had different NIC handles. I'll probably wait a month, then pull the acl to see if it starts back up. Oh, and each and every /32 that sent mail had fully proper DNS, including PTR etc. Spamassassin's score was well in the 'ham' category for all of those messages. IP reputation lists are one weapon in the arsenal, but not nearly as effective as one would like. There is no technical magic bullet that I've seen work over the long haul. But that's not really on-topic for NANOG. From dot at dotat.at Wed Mar 26 17:36:38 2014 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Mar 2014 17:36:38 +0000 Subject: misunderstanding scale, SMTP edition In-Reply-To: <20140326170906.13315.qmail@joyce.lan> References: <20140326170906.13315.qmail@joyce.lan> Message-ID: John Levine wrote: > > If I were a spammer or an ESP who wanted to listwash, I could easily use > a different IP addres for every single message I sent. Until mail servers start rate-limiting the number of different addresses that are used :-) You can do something like the following in Exim, which limits IPv6 senders to 16 addresses per /64 per day. defer hosts = <; 2000::/4 ratelimit = 16 / 1d / per_conn /\ unique=$sender_host_address /\ ${mask:$sender_host_address/64} Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall: Southerly 5 or 6 at first in west, otherwise variable 3 or 4, becoming northeasterly 4 or 5. Moderate or rough. Showers. Good, occasionally moderate. From dot at dotat.at Wed Mar 26 17:38:43 2014 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Mar 2014 17:38:43 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53330DCB.7050607@pari.edu> References: <20140326165952.13291.qmail@joyce.lan> <53330DCB.7050607@pari.edu> Message-ID: Lamar Owen wrote: > the typical ISP has the technical capability to bill based on volume of > traffic already, and could easily bill per-byte for any traffic with > 'e-mail properties' like being on certain ports or having certain > characteristics. Who do I send the bill to for mail traffic from 41.0.0.0/8 ? Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet, Irish Sea: Northwest veering east 4 or 5, occasionally 6 later in Irish Sea. Moderate or rough. Showers. Good, occasionally moderate. From johnl at iecc.com Wed Mar 26 17:42:59 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 17:42:59 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53330DCB.7050607@pari.edu> Message-ID: <20140326174259.13483.qmail@joyce.lan> >And I also remember thinking at the time that you missed one very >important angle, and that is that the typical ISP has the technical >capability to bill based on volume of traffic already, and could easily >bill per-byte for any traffic with 'e-mail properties' like being on >certain ports or having certain characteristics. Yeah, I'm well aware >of the technical issues with that; I never said it was a good idea, but >what is the alternative? Where do you expect them to send the bill? R's, John PS: The alternative is to deal directly with spam issues, rather than replacing them with even worse e-postage issues. One of the things I pointed out in that white paper is that as soon as you have real money involved, you're going to have a whole new set of frauds and scams that are likely to be worse than the ones you thought you were solving. From lsc at prgmr.com Wed Mar 26 17:55:03 2014 From: lsc at prgmr.com (Luke S. Crawford) Date: Wed, 26 Mar 2014 10:55:03 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> Message-ID: <53331477.1070701@prgmr.com> On 03/24/2014 06:18 PM, Owen DeLong wrote: > DHCPv6 is no less robust in my experience than DHCPv4. > > ARP and ND have mostly equivalent issues. This depends a lot on what you mean by 'robust' Now, I have dealt with NAT, and I see IPv6 as a technology with the potential to make my life less unpleasant. I really want IPv6 to succeed. However, DHCPv6 isn't anywhere near as useful for me, as someone who normally deals with IPs that don't change, as DHCPv4 is. With DHCPv4, my customers all get an address based on their mac that doesn't change if their box is re-installed. I configure this on the DHCP server, and the customer can run whatever dhcp client they like on whatever OS they like and they get the same IP every time. With DHCPv6 there is a time-based identifier that is added to the mac that makes it impossible, as far as I can tell, to give the customer a consistent IP across OS wipes without doing significant client configuration. There are many ways to skin this cat; stateless autoconfig looks like it mostly works, but privacy extensions seem to be the default in many places; outgoing IPv6 from those random addresses will trip my BCP38 filters. That, and reading the standard, it sure doesn't sound like consistency was a goal, even though it seems fairly consistent experimentally. there's a lot of "generally" and "may" in the text about what it adds to the mac in order to get the local identifier. It might make sense to just give everyone their own vlan and their own /64; that would, of course, bring its own problems and complexities (namely that I've gotta have the capability to deal with more customers than I can have native vlans - not impossible to get around, but significant added complexity.) I suppose I can also just keep DHCPv4 around, and if folks want IPv6, well, they have to wire down the address themselves. That's how I'm doing it now. From jbates at brightok.net Wed Mar 26 18:17:26 2014 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Mar 2014 13:17:26 -0500 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53331477.1070701@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> Message-ID: <533319B6.4040801@brightok.net> On 3/26/2014 12:55 PM, Luke S. Crawford wrote: > > However, DHCPv6 isn't anywhere near as useful for me, as someone who > normally deals with IPs that don't change, as DHCPv4 is. > My favorite is the RA thing. Years ago I decided that stupid DSLAMs were better than smart ones, so I generally utilize 1 vlan per customer with q-in-q and let the router handle all security. This meant I didn't have the usual breakage smart DSLAMs had with IPv6. Ideally, the router would run passive and not send regular RA updates. However, that isn't always viable with all clients. Sending out regular announcements and replicating them to all the vlans is extremely inefficient. Jack From bzs at world.std.com Wed Mar 26 18:22:57 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 26 Mar 2014 14:22:57 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <53325892.2070801@cox.net> References: <53325892.2070801@cox.net> Message-ID: <21299.6913.50963.426979@world.std.com> On March 25, 2014 at 23:33 LarrySheldon at cox.net (Larry Sheldon) wrote: > > Is spam fighting really about SMTP? Or is it about abuse of the > transport layer by (among other things) the SMTP? That is the point, isn't it. Most see spam as its content. The real problem with spam is its volume. Without the volume, some bot operators probably send on the order of a billion messages per day, it wouldn't be much of a problem. What makes that volume possible and pervasive is IP address mobility. Otherwise we'd just block the offending IPs and be done with it, to some extent -- I have a newer view on that but it'd be distracting. What makes IP address mobility possible is mass, unauthorized if not simply illegal use of others' resources, such as with botnets or massive exploiting of holes in web hosting sites' software. Fundamentally spam is a security isse. A spammer's stock in trade is the massive, free use of IP address and bandwidth resources. That the content is unwanted is almost incidental to this fact. -- -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 mohacsi at niif.hu Wed Mar 26 18:24:33 2014 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 26 Mar 2014 19:24:33 +0100 (CET) Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53331477.1070701@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> Message-ID: On Wed, 26 Mar 2014, Luke S. Crawford wrote: > On 03/24/2014 06:18 PM, Owen DeLong wrote: >> DHCPv6 is no less robust in my experience than DHCPv4. >> >> ARP and ND have mostly equivalent issues. > > This depends a lot on what you mean by 'robust' > > Now, I have dealt with NAT, and I see IPv6 as a technology with the potential > to make my life less unpleasant. I really want IPv6 to succeed. > > However, DHCPv6 isn't anywhere near as useful for me, as someone who normally > deals with IPs that don't change, as DHCPv4 is. > > With DHCPv4, my customers all get an address based on their mac that doesn't > change if their box is re-installed. I configure this on the DHCP server, > and the customer can run whatever dhcp client they like on whatever OS they > like and they get the same IP every time. > > With DHCPv6 there is a time-based identifier that is added to the mac that > makes it impossible, as far as I can tell, to give the customer a consistent > IP across OS wipes without doing significant client configuration. This is stupidity of the DHCPv6 client/OS implementation. They should use DUID type 3 (DUID-LL) by default, not DUID type 1 (DUID-LLT). This can be circumvented by setting the default to type 3, but... Regards, Janos Mohacsi From lowen at pari.edu Wed Mar 26 18:26:14 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 14:26:14 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140326165952.13291.qmail@joyce.lan> Message-ID: <53331BC6.1090309@pari.edu> On 03/26/2014 01:38 PM, Tony Finch wrote: > Who do I send the bill to for mail traffic from 41.0.0.0/8 ? Tony. You don't. Their upstream(s) in South Africa would bill them for outgoing e-mail. Postage, at least for physical mail, is paid by the sender at the point of ingress to the postal network. Yes, there are ways of gaming physical mail, but they are rarely actually used; the challenge of an e-mail version of such a system would be making it dirt simple and relatively resistant to gaming; or at least making gaming the system more expensive than using the system. And let me reiterate: I don't like the idea, and I don't even think it is a good idea. But how else do we make spamming unprofitable? I'd love to see a real solution, but it just isn't here yet. From mansaxel at besserwisser.org Wed Mar 26 18:32:27 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 26 Mar 2014 19:32:27 +0100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> Message-ID: <20140326183226.GE10032@besserwisser.org> Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Tue, Mar 25, 2014 at 10:45:00PM -0400 Quoting John R. Levine (johnl at iecc.com): > >None of this is REQUIRED. It is forced on people by a cartel of > >email providers. > > It must be nice to live in world where there is so little spam and > other mail abuse that you don't have to do any of the anti-abuse > things that real providers in the real world have to do. What is a real provider? And what in the email specifications tells us that the email needs and solutions of any one individual, as long as they are following protocol (which I'm quite convinced Mark is) are "unreal"? There are scalability issues that single out the mega-class providers as something special. But those are no reason to go around debating the realness of other email handling organisations. Also, the accept/reject policies of email recipients are subject to individual evaluation and implementation at each MX host. Attempts at describing the state of email as other than that are false and should be discarded[0]. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Content: 80% POLYESTER, 20% DACRONi ... The waitress's UNIFORM sheds TARTAR SAUCE like an 8" by 10" GLOSSY ... [0] I'm sorry for the wording here, I just had to recall a paraphrased instruction from when Sweden had a psyops defence organisation. "Varje meddelande om att motst?ndet skall uppges ?r falskt." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From lowen at pari.edu Wed Mar 26 18:45:10 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 14:45:10 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140326174259.13483.qmail@joyce.lan> References: <20140326174259.13483.qmail@joyce.lan> Message-ID: <53332036.9000205@pari.edu> On 03/26/2014 01:42 PM, John Levine wrote: >> And I also remember thinking at the time that you missed one very >> important angle, and that is that the typical ISP has the technical >> capability to bill based on volume of traffic already, and could easily >> bill per-byte for any traffic with 'e-mail properties' like being on >> certain ports or having certain characteristics. Yeah, I'm well aware >> of the technical issues with that; I never said it was a good idea, but >> what is the alternative? > Where do you expect them to send the bill? The entity with whom they already have a business relationship. Basically, if I'm an ISP I would bill each of my customers, with whom I already have a business relationship, for e-mail traffic. Do this as close to the edge as possible. And yes, I know, it will happen just about as soon as all edge networks start applying BCP38. I'm well aware of the limitations and challenges, but I'm also well aware of how ungainly and broken current anti-spam measures are. > One of the things I > pointed out in that white paper is that as soon as you have real money > involved, you're going to have a whole new set of frauds and scams that > are likely to be worse than the ones you thought you were solving. Yes, and this is the most challenging aspect. Again, I'm not saying e-postage is a good idea (because I don't think it is), but the fact of the matter is, like any other crime, as long as e-mail unsolicited commercial e-mail is profitable it will be done. So, what other ways are there to make unsolicited commercial e-mail unprofitable? From dot at dotat.at Wed Mar 26 18:55:40 2014 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Mar 2014 18:55:40 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53332036.9000205@pari.edu> References: <20140326174259.13483.qmail@joyce.lan> <53332036.9000205@pari.edu> Message-ID: Lamar Owen wrote: > > The entity with whom they already have a business relationship. Basically, if > I'm an ISP I would bill each of my customers, with whom I already have a > business relationship, for e-mail traffic. Do this as close to the edge as > possible. Ooh, excellent, so I can deliver loads of spam to them and charge them for it! Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: Northwest 4 or 5, becoming variable 4. Moderate or rough. Rain or showers. Good, occasionally moderate. From dot at dotat.at Wed Mar 26 18:56:49 2014 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Mar 2014 18:56:49 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53331BC6.1090309@pari.edu> References: <20140326165952.13291.qmail@joyce.lan> <53331BC6.1090309@pari.edu> Message-ID: Lamar Owen wrote: > On 03/26/2014 01:38 PM, Tony Finch wrote: > > Who do I send the bill to for mail traffic from 41.0.0.0/8 ? Tony. > > You don't. Their upstream(s) in South Africa would bill them for outgoing > e-mail. You mean Nigeria. So how do I get compensated for dealing with the junk they send me? Tony. -- f.anthony.n.finch http://dotat.at/ Thames, Dover, Wight, Portland, Plymouth: North 4 or 5, becoming variable 3 or 4, then east 4 or 5 later. Slight or moderate, but rough in southwest Plymouth. Rain or showers. Good, occasionally moderate. From Valdis.Kletnieks at vt.edu Wed Mar 26 18:59:47 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Mar 2014 14:59:47 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "Wed, 26 Mar 2014 10:07:22 -0400." <5332DF1A.9040001@pari.edu> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> Message-ID: <9370.1395860387@turing-police.cc.vt.edu> On Wed, 26 Mar 2014 10:07:22 -0400, Lamar Owen said: > it; get enough endusers with this problem and you'll get a class-action > suit against OS vendors that allow the problem to remain a problem; you > can get rid of the bots. You *do* realize that the OS vendor can't really do much about users who click on stuff they shouldn't, or reply to phishing emails, or most of the other ways people *actually* get pwned these days? Hint: Microsoft *tried* to fix this with UAC. The users rioted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Mar 26 19:09:26 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Mar 2014 15:09:26 -0400 Subject: A little silly for IPv6 In-Reply-To: Your message of "Wed, 26 Mar 2014 09:19:14 -0400." References: <53325754.9040609@cox.net> Message-ID: <10036.1395860966@turing-police.cc.vt.edu> On Wed, 26 Mar 2014 09:19:14 -0400, "rwebb at ropeguru.com" said: > Again comparing something like factual numbers of IPv6 addresses the > the very fuzzy math of guessing how many atoms there are is very silly > indeed. A bit of thought will show that you can probably compute this based on our estimage of the mass of the earth, which is known to be 5.97219 ? 10^24 kg, and an estimate of what elements the mantle and core are made up of. http://education.jlab.org/qa/mathatom_05.html I don't think that 3 significant digits counts as "very fuzzy math".... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From fergdawgster at mykolab.com Wed Mar 26 19:16:45 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 26 Mar 2014 12:16:45 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53332036.9000205@pari.edu> References: <20140326174259.13483.qmail@joyce.lan> <53332036.9000205@pari.edu> Message-ID: <5333279D.30808@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/26/2014 11:45 AM, Lamar Owen wrote: > So, what other ways are there to make unsolicited commercial > e-mail unprofitable? Well, perhaps not by punishing legitimate SMTP senders who have done nothing wrong. Don't get me wrong -- I already *pay* to send mail. I migrated all of my personal e-mail off of free webmail platforms some time ago to a paid service (e.g. "If you are not paying for a service, you are the product."). - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMzJ50ACgkQKJasdVTchbItSQD8DKy1yGJ68b4yNgl0ttoGMjHs RtLTqY6vunNnzgvcXlUBAMLeosoLBKQTcjYkZAYnLqObjXJU4EZQN60vjI0C+FUY =exPx -----END PGP SIGNATURE----- From johnl at iecc.com Wed Mar 26 19:35:48 2014 From: johnl at iecc.com (John R. Levine) Date: 26 Mar 2014 15:35:48 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140326183226.GE10032@besserwisser.org> References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> Message-ID: >> It must be nice to live in world where there is so little spam and >> other mail abuse that you don't have to do any of the anti-abuse >> things that real providers in the real world have to do. > > What is a real provider? And what in the email specifications tells us > that the email needs and solutions of any one individual, as long as they > are following protocol (which I'm quite convinced Mark is) are "unreal"? A real provider is one that provides mail for real users, as opposed to someone who plays RFC language lawyer games. I only have a few dozen users, but I can assure you I use a whole lot of different filtering approaches including DNSBLs to keep my users' mailboxes usable. I must say it's pretty amusing that someone who works for the organization that published the original DNSBL seems to be ranting against them. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From LarrySheldon at cox.net Wed Mar 26 19:55:25 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 26 Mar 2014 14:55:25 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140326174259.13483.qmail@joyce.lan> <53332036.9000205@pari.edu> Message-ID: <533330AD.7010806@cox.net> On 3/26/2014 2:16 PM, Paul Ferguson wrote: to a > paid service (e.g. "If you are not paying for a service, you are the > product."). That needs to be engraved in the glass screens of every device, like the "G.O.A.L" at the bottom of the rear-view mirror of some semi-truck tractors. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From lowen at pari.edu Wed Mar 26 19:56:23 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 15:56:23 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <9370.1395860387@turing-police.cc.vt.edu> References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <533330E7.3030503@pari.edu> On 03/26/2014 02:59 PM, Valdis.Kletnieks at vt.edu wrote: > You *do* realize that the OS vendor can't really do much about users > who click on stuff they shouldn't, or reply to phishing emails, or > most of the other ways people *actually* get pwned these days? Hint: > Microsoft *tried* to fix this with UAC. The users rioted. Yep, I do realize that and I do remember the UAC 'riots.' But the OS vendor can make links that are clicked run in a sandbox and make said sandbox robust. A user clicking on an e-mail link should not be able to pwn the system. Period. Most of the phishing e-mails I've sent don't have a valid reply-to, from, or return-path; replying to them is effectively impossible, and the linked/attached/inlined payload is the attack vector. From lowen at pari.edu Wed Mar 26 20:03:43 2014 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Mar 2014 16:03:43 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <533330E7.3030503@pari.edu> References: <20140325172328.5224.qmail@joyce.lan> Message-ID: <5333329F.8030106@pari.edu> On 03/26/2014 03:56 PM, Lamar Owen wrote: > > Most of the phishing e-mails I've sent don't have a valid reply-to, > from, or return-path; replying to them is effectively impossible, and > the linked/attached/inlined payload is the attack vector. > > > Blasted spellcheck.... Now that everybody has had a good laugh; I've not 'sent' *any* phishing e-mails, but I have *seen* plenty. Argh. From johnl at iecc.com Wed Mar 26 20:48:28 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 20:48:28 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Message-ID: <20140326204828.14163.qmail@joyce.lan> >> On 03/26/2014 01:38 PM, Tony Finch wrote: >> > Who do I send the bill to for mail traffic from 41.0.0.0/8 ? Tony. >> >> You don't. Their upstream(s) in South Africa would bill them for outgoing >> e-mail. > >You mean Nigeria. So how do I get compensated for dealing with the junk >they send me? I am Mrs. Mariam Abacha with TEN MILLION DOLLARS in blocked mail payments in a bank account. I apologize for contacting you this way but it is urgent that your assistance be applied to repatriating those funds. From bzs at world.std.com Wed Mar 26 21:06:36 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 26 Mar 2014 17:06:36 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140326165952.13291.qmail@joyce.lan> References: <5332DF1A.9040001@pari.edu> <20140326165952.13291.qmail@joyce.lan> Message-ID: <21299.16732.141347.602416@world.std.com> On March 26, 2014 at 16:59 johnl at iecc.com (John Levine) wrote: > > I wrote a white paper ten years ago explaining why e-postage is a > bad idea, and there is no way to make it work. Nothing of any > importance has changed since then. > > http://www.taugh.com/epostage.pdf It's a fine white paper, I just read it again. But it does tend to make the best the enemy of the good. I remember during the metered bandwidth arguments many years ago people asserting similarly that it was (practically) impossible to implement, would just anger people, was full of holes (hey I can't completely control my bandwidth usage, some outsider could run it up!), etc. Yet, here we are in a world of (mobile) bandwidth caps etc. Big money has a way of focusing efforts. I actually think we're just not quite there yet as horrid as spam is. This is what I alluded to in my previous message. The next leg will be when the line between "spam" as in questionable content and commercial "ham" grows fuzzier and fuzzier. There are for examplee about 1,000 Fortune 1,000 companies, many of which can name any of us legitimate business contacts. And many of them have dozens if not hundreds of sub-divisions (e.g., insurance brokers) who also would qualify as not spam under commonly accepted definitons (and CAN-SPAM.) And they will be motivated by the same things which motivated spammers: (nearly) Free access to our eyeballs, push technology. My guess is the next generation solution won't be motivated by end-users being overwhelmed though that will be cited. It will be motivated by the opportunity to outcapitalize access to our eyeballs as they realize no one is reading the thousands of pieces of ham per day, let alone the spam. This is independent of reputation and similar identity services as a filter: They're all legitimate! Every one of the 5,000 messages you got that day were perfectly legitimate, anyone you ever gave your credit card to for example. Anyhow, obviously I can go on and on, it's a complex subject. But I think the solutions will be driven by the creation of economics around the problem, just as they often are in real life. And a lot of the leakage can be mitigated merely by big men with big sticks once money is a factor, rather than magic algorithms (though they will help of course.) -- -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 SNaslund at medline.com Wed Mar 26 21:48:08 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 26 Mar 2014 21:48:08 +0000 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4B542373A@MUNPRDMBXA1.medline.com> If you can figure out how to store an address and a mask you can have any size entry you want. Just like a routing table. This is not insurmountable. Steven Naslund Chicago IL > OTOH, a spammer with a single /64, pretty much the absolute minimum > IPv6 block, has more than 18 quintillion addresses and there's not a > computer on the planet with enough memory (or probably not even enough > disk space) to store that block list. > It only takes a single entry if you do not store /128s but that /64. Yes, RBL lookups do not currently know how to handle this, but there are a couple of good proposals around on how to do it. This would also reduce the risks from cache depletion attacks via DNSxL lookups to IPv4 levels. Sometimes scale is everything. host-based reputation lists scale easily to > 3.2 billion host addresses. IPv6, not so easily. > As soon as we get away from host-centric-view to a network-block-view, things get pretty straightforward. -- Matthias From streiner at cluebyfour.org Wed Mar 26 19:00:30 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 26 Mar 2014 15:00:30 -0400 (EDT) Subject: A little silly for IPv6 In-Reply-To: <10036.1395860966@turing-police.cc.vt.edu> References: <53325754.9040609@cox.net> <10036.1395860966@turing-police.cc.vt.edu> Message-ID: On Wed, 26 Mar 2014, Valdis.Kletnieks at vt.edu wrote: > On Wed, 26 Mar 2014 09:19:14 -0400, "rwebb at ropeguru.com" said: > >> Again comparing something like factual numbers of IPv6 addresses the >> the very fuzzy math of guessing how many atoms there are is very silly >> indeed. > > A bit of thought will show that you can probably compute this based on our > estimage of the mass of the earth, which is known to be 5.97219 ? 10^24 kg, > and an estimate of what elements the mantle and core are made up of. This thread has gone pretty far off the rails, in terms of being on topic for NANOG. jms From SNaslund at medline.com Wed Mar 26 22:10:49 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 26 Mar 2014 22:10:49 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75AE91A3DB@SBS1.blinker.local> References: <20140325172328.5224.qmail@joyce.lan> <78C35D6C1A82D243B830523B4193CF5F75AE91A3DB@SBS1.blinker.local> Message-ID: <9578293AE169674F9A048B2BC9A081B4B5423783@MUNPRDMBXA1.medline.com> >>>Would it make it more unique; if I suggested creation of a new distributed Cryptocurrency something like 'MAILCoin' to track the memberships in the club and handle voting out of abusive mail servers: in a distributed >>>manner, to ensure that no court could ever mandate that a certain IP >>>address be accepted into the club? >>>Not necessarily. But I haven't yet heard of any meaningful attempt to >>>implement something like that. Obviously with IPv4; way too many >>>"legacy" mail servers exist that will never bother to implement new >>>protocols and practice improvements ---- even basic things, such as SMTP >>>rejecting invalid recipients instead of sending unsolicited bounce replies to senders (forged by spammers). How about something much simpler? We already are aware of bandwidth caps at service providers, there could just as well be email caps. How hard would it be to ask your customer how many emails we should expect them to send in a day? We don't need to be precise about it, just within an order of magnitude. For example, I could say that a residential user should not be over 750 a day and for a commercial user you could find out their projection and add to it to allow a reasonable headroom. Now, the service provider is protecting us from pwned systems within their network. If I get a residential customer asking for 100,000 emails per day I just might have some questions for them. It also seems that it would be easy for the service provider to send an alert to the customer telling them that they have hit their cap and make it easy for them to lift the cap if the traffic is actually legitimate. If they are lifting their cap too often you could investigate or run their outbound email through some type of filtering solution to see how it scores. Now, the providers that implement that system could be allowed to send me email and the ones that don't can't send me email. If this was adopted widely, it would put a lot of pressure on the service provider to get on-board. In that case your filters do not need to be that granular. This is not a spam proof solution but would cut down on the very high volume abusers. It also helps deal with the service providers that condone that sort of stuff and will punish them because you are going to lose customers fast if email from that provider is generally not accepted. Maybe if we start scoring against the originating service provider, instead of address blocks and stop accepting email from them, they might do something about the high volume offenders. Steven Naslund Chicago IL From blake at ispn.net Wed Mar 26 22:16:25 2014 From: blake at ispn.net (Blake Hudson) Date: Wed, 26 Mar 2014 17:16:25 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <5332CBD2.2030008@vocalabs.com> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> Message-ID: <533351B9.9050204@ispn.net> Daniel Taylor wrote the following on 3/26/2014 7:45 AM: > On 03/25/2014 11:18 PM, John Levine wrote: >>> 3. Arguing about IPv6 in the context of requirements upon SMTP >>> connections is playing that uncomfortable game with >>> one?s own combat boots. And not particularly productive. >> If you can figure out how to do effective spam filtering without >> looking at the IP addresses from which mail arrives, you will be in a >> position to make a whole lot of money. >> >> But, as always, I'm not holding my breath. >> >> R's, >> John >> >> PS: Note the word "effective". >> > You look at the IP, and verify forward and reverse DNS. > > IPv6 doesn't make this any harder a problem than IPv4, it just means > that we're going to *have* to reject mail that comes in from IPv6 > addresses that don't have clean DNS. > With this in mind, how hard is it for a spamming operation to setup rDNS for their IPv6 ranges? Not very hard, just like their ability to use SPF or DKIM (they will do it if it improves their deliverability). This is separate from infected bots on residential connections, which is effectively dealt with today through the PBL or some basic rDNS checks since practically everyone has rDNS in IPv4. Having rDNS doesn't automatically make you a good guy. SMTP operators will still have the need for reputation based services. Due to the design of the SMTP protocol (which provides little protection for abuse on its own), people chose to place additional checks at L3. I see this as a deficiency in SMTP that we were fortunate enough to solve in an IPv4 landscape (after a lot of initial concern about RBLs and their operators), but is going to be harder to to utilize the same tool as effectively in IPv6. The problem is with SMTP and is probably best addressed in the application layer through updates to SMTP or required bolt-ons (e.g SPF or similar); it was just simpler for most folks to address it on their own at L3 rather than trying to get everyone to agree on a new/better way to send email messages. --Blake From mpalmer at hezmatt.org Wed Mar 26 22:49:51 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 27 Mar 2014 09:49:51 +1100 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53331477.1070701@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> Message-ID: <20140326224951.GH24282@hezmatt.org> On Wed, Mar 26, 2014 at 10:55:03AM -0700, Luke S. Crawford wrote: > There are many ways to skin this cat; stateless autoconfig looks > like it mostly works, but privacy extensions seem to be the default > in many places; outgoing IPv6 from those random addresses will trip > my BCP38 filters. Your what-now? You do realise SLAAC works entirely within a single /64, which shouldn't be difficult to decide is either routable or not in one hit, right? - Matt -- Q: Why do Marxists only drink herbal tea? A: Because proper tea is theft. -- Chris Suslowicz, in the Monastery From lsc at prgmr.com Wed Mar 26 23:25:57 2014 From: lsc at prgmr.com (Luke S. Crawford) Date: Wed, 26 Mar 2014 16:25:57 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <20140326224951.GH24282@hezmatt.org> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> Message-ID: <53336205.2010206@prgmr.com> On 03/26/2014 03:49 PM, Matt Palmer wrote: > On Wed, Mar 26, 2014 at 10:55:03AM -0700, Luke S. Crawford wrote: >> There are many ways to skin this cat; stateless autoconfig looks >> like it mostly works, but privacy extensions seem to be the default >> in many places; outgoing IPv6 from those random addresses will trip >> my BCP38 filters. > > Your what-now? You do realise SLAAC works entirely within a single /64, > which shouldn't be difficult to decide is either routable or not in one hit, > right? If you give every customer their own vlan and /64, sure. That can be done, and there are many advantages to doing it that way. But it's quite a bit more complex than my current setup. The way I'm setup now, I've got an IPv4 address block on a vlan, and an IPv6/64 on the same vlan. I have many customers on that vlan. Each customer has one (or more) IPv4 /32 addresses and one IPv6 /128 addresses. (if the customer wants more IPv6, we just route a /64 to the /128 they are allowed.) There are firewall rules that only allow appropriate packets in and out of the interface. These rules are important for privacy as well as preventing spoofing; they prevent sniffing of most traffic bound for other guests. This is in production on many of my hosts, and because I give every user both an IPv4 and an IPv6 address, this mostly works. My setup scripts wire down both the v4 and v6 addresses before I hand it off to the user; if the user wants re-install, well, they can wire down the IPv6 address by hand if they want it, and IPv4 works regardless. It is valid to say that I'm trying to use IPv6 the way I use IPv4, and perhaps that is the wrong thing to do. Perhaps IPv6 needs to be thought of in a different way from IPv4; Perhaps in IPv6, a /64 should be the smallest block I give to a user, and the smallest block I filter on, and I just need to eat the network complexity costs inherent to giving each user a vlan. My original comment and complaint, though, was in response to the assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 does not fill the role that DHCPv4 fills, if you care about tying an IP to a MAC and you want that connection to persist across OS installs by customers. From johnl at iecc.com Wed Mar 26 23:35:20 2014 From: johnl at iecc.com (John Levine) Date: 26 Mar 2014 23:35:20 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <9578293AE169674F9A048B2BC9A081B4B5423783@MUNPRDMBXA1.medline.com> Message-ID: <20140326233520.14706.qmail@joyce.lan> >How about something much simpler? We already are aware of bandwidth caps at service providers, there could just as >well be email caps. How hard would it be to ask your customer how many emails we should expect them to send in a day? Once again, I encourage my competitors to follow your advice. R's, John PS: There are plenty of giant botnets that only send a trickle of mail from each infected host, but the aggregate amount is enormous. From tmorizot at gmail.com Wed Mar 26 23:52:53 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Wed, 26 Mar 2014 18:52:53 -0500 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53336205.2010206@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> <53336205.2010206@prgmr.com> Message-ID: On Mar 26, 2014 6:27 PM, "Luke S. Crawford" wrote: > My original comment and complaint, though, was in response to the assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 does not fill the role that DHCPv4 fills, if you care about tying an IP to a MAC and you want that connection to persist across OS installs by customers. You're right. DHCPv6 is more robust than DHCPv4. At least those of us in the enterprise space appreciate a client identifier that doesn't change when the hardware changes. And v6 doesn't work the same as v4 so you will expend more effort trying to force it to fit a v4 model. Scott From dhc2 at dcrocker.net Thu Mar 27 00:07:09 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 26 Mar 2014 17:07:09 -0700 Subject: IPv6 isn't SMTP In-Reply-To: References: <53325280.9070806@cox.net> Message-ID: <53336BAD.8040702@dcrocker.net> On 3/25/2014 10:41 PM, Jimmy Hess wrote: > (1) Architectural layers are a protocol design construction, only, which > assist with standardization. They are not a separation of > responsibilities. Actually, they are specifically a separation of responsibilities. That the separation doesn't work adequately and all the time means that pragmatics requires wandering across layer boundaries. But pragmatics also dictate being extremely careful when choosing to do that. > A SMTP server has to take care to have an implementation of all layers. There are two possible meanings to that sentence. The first prompts a 'duh' reaction, since SMTP (usually) runs over TCP/IP. So the server won't be very useful unless it 'has' an implementation of all layers. The other interpretation is that an SMTP package needs to have its own version of TCP and IP. This, of course, is silliness. SMTP packages do not typically implement TCP or IP. They might pay quite a lot of attention to those lower layers, but they don't implement them. > (2) The IP protocol layer is not actually independent. Moving to IPv6 does > in fact have effective new requirements for SMTP servers. Mostly, no. Not completely no, of course, but mostly. Language like #2 is leading quite a few folk to try to treat email over IPv6 as if it will be a separate service from the one currently running over v4. It won't be a separate service. Or, at least, it has better not be. The success of email has been through seamless, end-to-end integration, not through disparate silos with different service models. By way of example, please highlight which email packages require or even allow an author to dictate which version of IP to send over. For anything that someone thinks should be done for v6, pursue it instead as a change for the entire global service. It's fine for v6-related issues to /motivate/ global changes, but don't isolate the work to v6 platforms. > (4) When a major change will [by necessity] be made to any layer > underlying the MTA application on the protocol stack, > now is also a good time to look at the overall service as a whole. Sure, but not 'also'. Rather 'only', except for relatively trivial layer convergence gluing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mysidia at gmail.com Thu Mar 27 00:12:49 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 26 Mar 2014 19:12:49 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <533351B9.9050204@ispn.net> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> Message-ID: On Wed, Mar 26, 2014 at 5:16 PM, Blake Hudson wrote: > >>> With this in mind, how hard is it for a spamming operation to setup > rDNS for their IPv6 ranges? Not very hard, just like their ability to use > SPF or DKIM (they will do it if it improves their deliverability). This is > separate from infected bots on residential connections, which is > effectively dealt with today through the PBL or some basic rDNS checks > since practically everyone has rDNS in IPv4. > [snip] There are plenty of residential connections, and enterprise non-mail server connections, that PBL is no good for. As far as i'm concerned.... if you can force the spammer to use their own IP range, that they can setup RDNS for, then you have practically won, for all intents and purposes, as it makes blacklisting feasible, once again! Spammers can jump through these hoops --- but spammers aren't going to effectively scale up their spamming operation by using IP address ranges they can setup RDNS on. I would argue that less than 100% of spammers for sure would make the shift from compromising as many IP addresses as possible and turning them into mail servers. Following that.... what's really left is: misconfigured mail servers allowing open relays, and mail users that fall to phishing or pick easy to guess passwords. (Spammer intruding upon and co-oping mailboxes that are legitimate in the first place.) > Having rDNS doesn't automatically make you a good guy. SMTP operators will > still have the need for reputation based services. Due to the design of the > SMTP protocol Indeed it doesn't, but it's highly suggestive. *I would rather rDNS be augmented with a registration of intent to run a mail server that can verifiably be linked to whomever is authorized contact for the IP space. > (which provides little protection for abuse on its own), people chose to > place additional checks at L3. I see this as a deficiency in SMTP that we > were fortunate enough to solve in an IPv4 landscape (after a lot of initial > concern about RBLs and their operators), but is going to be harder to to > utilize the same tool as effectively in IPv6. It will be immensly harder. > The problem is with SMTP and is probably best addressed in the application > layer through updates to SMTP or required bolt-ons (e.g SPF or similar); it > was just simpler SPF is useful, but not a complete solution. I'm curious what form you think these updates to SMTP would take? What changes to SMTP protocol itself could really have a meaningful impact, without frustrating, confusing, or terribly complicating the lives of millions of mail users? > --Blake > -- -JH From fred at cisco.com Thu Mar 27 00:47:20 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Thu, 27 Mar 2014 00:47:20 +0000 Subject: IPv6 isn't SMTP In-Reply-To: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> Message-ID: On Mar 25, 2014, at 8:31 PM, Cutler James R wrote: > 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one?s own combat boots. And not particularly productive. That is one of my two big take-aways from this conversation. The other is that operators of SMTP MTAs should implement RDNS for them, which I thought we already knew. To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would do well to observe RFC 6555?s considerations). Another is that, whether on an incoming or an outbound connection, when the application gets its own address from the OS (binary or as a character string), it needs to allocate more storage for the data structure. The third is that it needs to be able to interpret user at 2001:db8::1 as well as user at dns-name and user at 192.0.2.1. All things considered, that?s a pretty narrow change set. Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. We know that there are people in the world that don?t implement it for IPv4. Yet, here we are, using SMTP/IPv4 to discuss this, and I don?t hear anyone saying that IPv4 isn?t ready for prime time as a result of the fact of some operators not implementing RDNS. ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cra at WPI.EDU Thu Mar 27 00:50:40 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 26 Mar 2014 20:50:40 -0400 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> <53336205.2010206@prgmr.com> Message-ID: <20140327005039.GB7867@angus.ind.WPI.EDU> On Wed, Mar 26, 2014 at 06:52:53PM -0500, Timothy Morizot wrote: > On Mar 26, 2014 6:27 PM, "Luke S. Crawford" wrote: > > My original comment and complaint, though, was in response to the > assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 > does not fill the role that DHCPv4 fills, if you care about tying an IP to > a MAC and you want that connection to persist across OS installs by > customers. > > You're right. DHCPv6 is more robust than DHCPv4. At least those of us in > the enterprise space appreciate a client identifier that doesn't change > when the hardware changes. No, it is LESS robust, because the client identifier changes when the SOFTWARE changes. Around here, software changes MUCH more often than hardware. Heck, even a dual-boot scenario breaks the client identifier stability. Worse yet, DHCPv6 has created a scenario where a client's IPv4 connectivity and IPv6 connectivity break under /different/ scenarios, causing difficult-to-troubleshoot half-connectivity issues when either the hardware is replaced or the software is reloaded. From james.cutler at consultant.com Thu Mar 27 02:04:04 2014 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 26 Mar 2014 22:04:04 -0400 Subject: IPv6 isn't SMTP In-Reply-To: References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> Message-ID: <1C2A64F9-6671-4310-B344-CF7BA4AA1A7B@consultant.com> On Mar 26, 2014, at 8:47 PM, Fred Baker (fred) wrote: > > On Mar 25, 2014, at 8:31 PM, Cutler James R wrote: > >> 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one?s own combat boots. And not particularly productive. > > That is one of my two big take-aways from this conversation. The other is that operators of SMTP MTAs should implement RDNS for them, which I thought we already knew. > > To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would do well to observe RFC 6555?s considerations). Another is that, whether on an incoming or an outbound connection, when the application gets its own address from the OS (binary or as a character string), it needs to allocate more storage for the data structure. The third is that it needs to be able to interpret user at 2001:db8::1 as well as user at dns-name and user at 192.0.2.1. > > All things considered, that?s a pretty narrow change set. > > Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. We know that there are people in the world that don?t implement it for IPv4. Yet, here we are, using SMTP/IPv4 to discuss this, and I don?t hear anyone saying that IPv4 isn?t ready for prime time as a result of the fact of some operators not implementing RDNS. > > ... > Fred Baker describes the requirements in a most satisfactory manner. Thank you, Fred. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johnl at iecc.com Thu Mar 27 02:08:33 2014 From: johnl at iecc.com (John Levine) Date: 27 Mar 2014 02:08:33 -0000 Subject: IPv6 isn't SMTP In-Reply-To: Message-ID: <20140327020833.15253.qmail@joyce.lan> >To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS >interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would >do well to observe RFC 6555?s considerations). In practice it's considerably more complex than that due to MX handling. If you have multihomed hosts, or multiple MXes at the same priority, you need to decide in what order to try them, and what to do next if a connection attempt fails. If one MX has an A record and another has AAAA, do you always prefer the one with the AAAA? If a host has both an A and an AAAA, you probably try the AAAA first, so if the AAAA connection fails, do you try the A or do you skip to the next host? The RFC is deliberately unhelpful here, and a fair amount of fiddling is required to come up with heuristics that work well. There are also some odd things in the spec. For example, according to RFC 5321 this is not a syntactically valid e-mail address: mailbox@[IPv6:2001:12:34:56::78:ab:cd] R's, John From fmartin at linkedin.com Thu Mar 27 02:16:40 2014 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 27 Mar 2014 02:16:40 +0000 Subject: IPv6 isn't SMTP In-Reply-To: References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> Message-ID: <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> On Mar 26, 2014, at 5:47 PM, Fred Baker (fred) wrote: > > On Mar 25, 2014, at 8:31 PM, Cutler James R wrote: > >> 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one?s own combat boots. And not particularly productive. > > That is one of my two big take-aways from this conversation. The other is that operators of SMTP MTAs should implement RDNS for them, which I thought we already knew. It is in several industry recommendations cf for instance BCP at www.m3aawg.org > > To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would do well to observe RFC 6555?s considerations). Another is that, whether on an incoming or an outbound connection, when the application gets its own address from the OS (binary or as a character string), it needs to allocate more storage for the data structure. The third is that it needs to be able to interpret user at 2001:db8::1 as well as user at dns-name and user at 192.0.2.1. > and user at 2001:db8::1.25 with user at 192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. > All things considered, that?s a pretty narrow change set. > > Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. We know that there are people in the world that don?t implement it for IPv4. Yet, here we are, using SMTP/IPv4 to discuss this, and I don?t hear anyone saying that IPv4 isn?t ready for prime time as a result of the fact of some operators not implementing RDNS. > There is some confusion between MX selection and address selection, I tried to document it, and resolve the ambiguities in http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-IPv6/ (comments at apps-discuss at ietf.org) Remember 70 to 90% of email is spam, blacklists can drop as much as 75% of spam at connection time (an IPv6 blacklist has problems due to size and impact on DNS). If we mess up the transition of SMTP to IPv6, less than 1 out of 10 emails in your mailbox will be remotely interesting?. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdrake at direcpath.com Thu Mar 27 03:12:10 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 26 Mar 2014 23:12:10 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> Message-ID: <5333970A.6070107@direcpath.com> On 3/26/2014 10:16 PM, Franck Martin wrote: > > and user at 2001:db8::1.25 with user at 192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. From: http://tools.ietf.org/html/rfc3986#section-3.2.2 From dhc2 at dcrocker.net Thu Mar 27 03:21:19 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 26 Mar 2014 20:21:19 -0700 Subject: IPv6 isn't SMTP In-Reply-To: <21299.6913.50963.426979@world.std.com> References: <53325892.2070801@cox.net> <21299.6913.50963.426979@world.std.com> Message-ID: <5333992F.6020300@dcrocker.net> On 3/26/2014 11:22 AM, Barry Shein wrote: > What makes IP address mobility possible is mass, unauthorized if not > simply illegal use of others' resources, such as with botnets or > massive exploiting of holes in web hosting sites' software. Except that compromised personal computers are 'valid' by all normal metrics. An army of such machines provides a kind of address mobility that is not detected by any normal means. > Fundamentally spam is a security isse. In the same way as burglary is a security issue, yeah. Which is to say that fundamentally, spam is a social issue, like any other crime. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nick at wiredmedium.com Thu Mar 27 03:30:27 2014 From: nick at wiredmedium.com (Nick) Date: Wed, 26 Mar 2014 22:30:27 -0500 Subject: WISP or other options Message-ID: <53339B53.9040700@wiredmedium.com> Hey, I have a weird off the wall question for a NA group. Does any have contacts in Edinburgh Scotland who can provide WISP service at the Hopetoun House and Dundas Castle. I would like to have 20-60mpbs to for 2 days of services. Our company's event planner claims there are no good ISP options in the area and wants us to go with satellite internet which is pricy and has high latency. Its worth noting both locations have ~7mpbs DLS. I'm also open to other options. Thanks, Nick Poulakos From johnl at iecc.com Thu Mar 27 03:28:28 2014 From: johnl at iecc.com (John Levine) Date: 27 Mar 2014 03:28:28 -0000 Subject: IPv6 address literals probably aren't SMTP either In-Reply-To: <5333970A.6070107@direcpath.com> Message-ID: <20140327032828.15628.qmail@joyce.lan> In article <5333970A.6070107 at direcpath.com> you write: > >On 3/26/2014 10:16 PM, Franck Martin wrote: >> >> and user at 2001:db8::1.25 with user at 192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the >separator for the port in IPv4? A few MTA are confused by it. >At the network level the IPv6 address is just a big number. No >confusion there. At the plaintext level the naked IPv6 address should >be wrapped in square brackets. > >From: >http://tools.ietf.org/html/rfc3986#section-3.2.2 It's messier than that. See RFC 5321 section 4.1.3. I have no idea whether anyone has actually implemented IPv6 address literals and if so, how closely they followed the somewhat peculiar spec. R's, John From wbailey at satelliteintelligencegroup.com Thu Mar 27 03:35:20 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 27 Mar 2014 03:35:20 +0000 Subject: WISP or other options In-Reply-To: <53339B53.9040700@wiredmedium.com> References: <53339B53.9040700@wiredmedium.com> Message-ID: 20-60mbps is a tall order. I?d say cellular.. Maybe you can pair together a couple of 4g cradle points and do load balancing on them? You are screwed for LOS microwave, 60mbps on a microwave hope requires real life engineering to function correctly. Frequency coordination, towers, AGL requirements. If you?re looking for satellite, I can tell you for certain that a 60mbps circuit for a month would exceed 140k a month in your neck of the woods. That?s just to start off, it can get higher as the link budget dictates. Is there any reason you need THAT much? Have you thought about using compression stuff at all? Are these people paying for it? On 3/26/14, 8:30 PM, "Nick" wrote: >Hey, > >I have a weird off the wall question for a NA group. > >Does any have contacts in Edinburgh Scotland who can provide WISP >service at the Hopetoun House and Dundas Castle. I would like to have >20-60mpbs to for 2 days of services. > >Our company's event planner claims there are no good ISP options in the >area and wants us to go with satellite internet which is pricy and has >high latency. Its worth noting both locations have ~7mpbs DLS. > >I'm also open to other options. > > >Thanks, > >Nick Poulakos > From rdrake at direcpath.com Thu Mar 27 04:02:07 2014 From: rdrake at direcpath.com (Robert Drake) Date: Thu, 27 Mar 2014 00:02:07 -0400 Subject: IPv6 address literals probably aren't SMTP either In-Reply-To: <20140327032828.15628.qmail@joyce.lan> References: <20140327032828.15628.qmail@joyce.lan> Message-ID: <5333A2BF.5050902@direcpath.com> On 3/26/2014 11:28 PM, John Levine wrote: > > It's messier than that. See RFC 5321 section 4.1.3. I have no idea > whether anyone has actually implemented IPv6 address literals and if > so, how closely they followed the somewhat peculiar spec. > > R's, > John > I'm not sure why the SMTP RFC defines IPv6-addr so thoroughly and in an incompatible way with the other RFCs. It would make more sense to refer back to another RFC with authoritative definitions. They're completely missing the fun that's happening with Zone Identifiers in RFC6874 and the hacks to support them some have been doing with the IPvFuture definition. I'm not saying John Klensin shouldn't have a say in how the IPv6 address is defined, but I do think it would be best for everyone to work it out in an official place somewhere so that email software isn't doing the complete opposite of everyone else. From mfidelman at meetinghouse.net Thu Mar 27 04:02:30 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 27 Mar 2014 00:02:30 -0400 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> Message-ID: <5333A2D6.5010302@meetinghouse.net> Laser link, and pray for clear weather? Warren Bailey wrote: > 20-60mbps is a tall order. > > I?d say cellular.. Maybe you can pair together a couple of 4g cradle > points and do load balancing on them? > > You are screwed for LOS microwave, 60mbps on a microwave hope requires > real life engineering to function correctly. Frequency coordination, > towers, AGL requirements. If you?re looking for satellite, I can tell you > for certain that a 60mbps circuit for a month would exceed 140k a month in > your neck of the woods. That?s just to start off, it can get higher as the > link budget dictates. > > Is there any reason you need THAT much? Have you thought about using > compression stuff at all? Are these people paying for it? > > On 3/26/14, 8:30 PM, "Nick" wrote: > >> Hey, >> >> I have a weird off the wall question for a NA group. >> >> Does any have contacts in Edinburgh Scotland who can provide WISP >> service at the Hopetoun House and Dundas Castle. I would like to have >> 20-60mpbs to for 2 days of services. >> >> Our company's event planner claims there are no good ISP options in the >> area and wants us to go with satellite internet which is pricy and has >> high latency. Its worth noting both locations have ~7mpbs DLS. >> >> I'm also open to other options. >> >> >> Thanks, >> >> Nick Poulakos >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From wbailey at satelliteintelligencegroup.com Thu Mar 27 04:15:42 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 27 Mar 2014 04:15:42 +0000 Subject: WISP or other options In-Reply-To: <5333A2D6.5010302@meetinghouse.net> References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> Message-ID: Yeah.. If you have an extra 10k per radio. Free Space Optics are everything but free. Lol And attenuation at 80ghz is going to be heavy.. When I say heavy.. I mean.. A fart will cause a fade if you?re close enough to the tx. ;) I would not recommend FSO for anyone with less than an ultra black belt in RF. They are such a bxtch to get lined up and running, you could be hanging out on site for a week trying to figure out why your path isn?t aligned. It is not for the feint hearted. Sharks with laser beams on their friggin? head, probably. On 3/26/14, 9:02 PM, "Miles Fidelman" wrote: >Laser link, and pray for clear weather? > >Warren Bailey wrote: >> 20-60mbps is a tall order. >> >> I?d say cellular.. Maybe you can pair together a couple of 4g cradle >> points and do load balancing on them? >> >> You are screwed for LOS microwave, 60mbps on a microwave hope requires >> real life engineering to function correctly. Frequency coordination, >> towers, AGL requirements. If you?re looking for satellite, I can tell >>you >> for certain that a 60mbps circuit for a month would exceed 140k a month >>in >> your neck of the woods. That?s just to start off, it can get higher as >>the >> link budget dictates. >> >> Is there any reason you need THAT much? Have you thought about using >> compression stuff at all? Are these people paying for it? >> >> On 3/26/14, 8:30 PM, "Nick" wrote: >> >>> Hey, >>> >>> I have a weird off the wall question for a NA group. >>> >>> Does any have contacts in Edinburgh Scotland who can provide WISP >>> service at the Hopetoun House and Dundas Castle. I would like to have >>> 20-60mpbs to for 2 days of services. >>> >>> Our company's event planner claims there are no good ISP options in the >>> area and wants us to go with satellite internet which is pricy and has >>> high latency. Its worth noting both locations have ~7mpbs DLS. >>> >>> I'm also open to other options. >>> >>> >>> Thanks, >>> >>> Nick Poulakos >>> > > >-- >In theory, there is no difference between theory and practice. >In practice, there is. .... Yogi Berra > > From bzs at world.std.com Thu Mar 27 04:24:25 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 27 Mar 2014 00:24:25 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <5333992F.6020300@dcrocker.net> References: <53325892.2070801@cox.net> <21299.6913.50963.426979@world.std.com> <5333992F.6020300@dcrocker.net> Message-ID: <21299.43001.594066.309143@world.std.com> On March 26, 2014 at 20:21 dhc2 at dcrocker.net (Dave Crocker) wrote: > On 3/26/2014 11:22 AM, Barry Shein wrote: > > What makes IP address mobility possible is mass, unauthorized if not > > simply illegal use of others' resources, such as with botnets or > > massive exploiting of holes in web hosting sites' software. > > Except that compromised personal computers are 'valid' by all normal > metrics. >From the receiving or intermediary point of view, sure. One would like to think that the owner of the transmitting host knows s/he didn't intend to send 15,000 herbal hair regrowth ads this morning if somehow it was pointed out to them and would probably be unhappy over it. So, illegal or at best unauthorized from the POV of the transmitter, owner or manager etc of the PC. I'm simply saying that spam would barely exist without these illegal (oh let's not split that hair) resources. > An army of such machines provides a kind of address mobility that is not > detected by any normal means. I agree. Perhaps a more global view might work but we don't have a way to implement that, or perhaps put better, the will to implement that. For example 1,000,000 systems sending out basically the same message (BUY HERBAL HAIR RE-GROWER!) would be suspicious particularly if the sending systems were scattered hither and yon. And we do try to do this via blacklists but it's not quite enough mostly because it's after the fact, much of the damage has been done, the 1M msgs were sent and put into peoples' mailboxes already. And then the spammers change their footprint. Really not a very good method but we do what we can. > > > Fundamentally spam is a security isse. > > In the same way as burglary is a security issue, yeah. Which is to say > that fundamentally, spam is a social issue, like any other crime. No, I really mean that without the illegal (let's not regrow that hair) resources the spammers are sunk, kaput, out of business. It's the only way they can operate in any effective manner. The only way. There's more to this but foiling whatever it is that spammers use to build botnets and massively exploit for example web hosting software will tend to work. The list is pretty short as far as I can tell. Everything else, such as content analysis and blacklisting will tend to not work, or only so much, a never-ending battle. Some will blanche at this but the entire spam problem basically arose from the crap security in Windows systems, particularly prior to maybe XP/SP2. Not sure where all that leads us, however. Better security at those major exploitation points, in a nutshell. And if someone disagrees then please tell me how spammers as we know them (and related miscreants) can operate without these few sources of purloined resources. Preferably without a big hand-wave like "oh they'll just find something else!" Maybe not! -- -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 johnl at iecc.com Thu Mar 27 04:28:49 2014 From: johnl at iecc.com (John R. Levine) Date: 27 Mar 2014 00:28:49 -0400 Subject: IPv6 address literals probably aren't SMTP either In-Reply-To: <5333A2BF.5050902@direcpath.com> References: <20140327032828.15628.qmail@joyce.lan> <5333A2BF.5050902@direcpath.com> Message-ID: > I'm not saying John Klensin shouldn't have a say in how the IPv6 address is > defined, but I do think it would be best for everyone to work it out in an > official place somewhere so that email software isn't doing the complete > opposite of everyone else. Too late. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2314 bytes Desc: S/MIME Cryptographic Signature URL: From wbailey at satelliteintelligencegroup.com Thu Mar 27 05:09:05 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 27 Mar 2014 05:09:05 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> Message-ID: I think the real problem here is the event is for 2 days and he requires a metric shxt ton of data (for wireless anyways..). Sure you could get all kinds of COOL solutions together, but do you think the (UK Version) LEC is going to run DSL/fiber/blah for a two day event? And who bears that cost burden? If this was an office, sure .. Go for it. A two day event, find something cheap or tell them to use smoke signals. (not to mention all of the venues I've worked with stateside either don't help, or want 15k for the "event" in question) And as a side note, as a die hard wireless guy (satellite, microwave, and cellular) I ask only one thing: Do not trivialize a wireless link.. It's not 802.11 and it doesn't act that way. If you just run an air fiber across and it works - great. But when it doesn't work, we're left to explain to the customer why the equipment neglected to work. Microwave is not 802.11.. Cellular is not 802.11.. 5ghz is not 802.11. They all act differently, and need to be designed properly to function in a less than suck capacity. I can't tell you how many times I've heard "Ewwww.. Satellite??" or "Ewww.. Microwave??" or "We'll use AT&T 4G for disaster recovery" and when you get into it the equipment didn't work because the office wireless guy (Todd, the only guy there who can configure the link sys router) couldn't get this POS 4k microwave radio to work. There are appropriate applications for all of these.. I'm usually the only guy in the room who can drop 100mbps into a field in the middle of Africa next week. It's all about choosing your poison and understanding how to handle it. It can be very beneficial, but it can also lead to you polishing your resume should it not "just work".. A pair of Air Fiber is like 3k USD, and at 24ghz you had better know what you are doing.. I don't know if you've ever pointed something with that narrow of a beam width, but if you have I imagine you'll appreciate what a shit show it is. Especially if you don't have guys at both sides of the path flashing or a pretty decent path analysis (which can cost upwards of 10k in some cases). My .02 :) From: Alex Howells > Date: Wednesday, March 26, 2014 at 9:41 PM To: Warren Bailey > Cc: Miles Fidelman >, "nanog at nanog.org" > Subject: Re: WISP or other options Pay someone to worry about all this stuff, MaxWiFi has a good reputation in the UK at least. Stuff like the Ubiquiti Networks AirFiber can be good for getting from A-B over "relatively short" distances if you've identified another place which has really good connectivity which you can use, and if good connectivity is truly critical to the events. Obviously this involves masts, may involve permitting, and is a bit more complex than just a DSL line. It's usually possible to bond multiple DSL connections, and it's not impossible to get phone lines and DSL installed for short events either, although it does depend on the venue being willing to accommodate you. According to SamKnows the South Queensferry exchange (Dundas Castle) is supposed to have gotten BT FTTC capability from 1st March and some LLU (O2, TalkTalk, Sky) has happened, so again, talk to someone who specialises in this stuff and they'll be able to navigate "What is the least fucked up way to solve this for the event?". HTH, -Alex From frnkblk at iname.com Thu Mar 27 05:11:43 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 27 Mar 2014 00:11:43 -0500 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> <001c01cf4710$0441be60$0cc53b20$@iname.com> Message-ID: <005c01cf497b$0b8e1660$22aa4320$@iname.com> And MSOs, wireless carriers, and satellite providers aren't competitors to RLECs? Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, March 24, 2014 9:05 PM To: Frank Bulk Cc: Naslund, Steve; nanog at nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica Since a second build-out is impractical (if not actually impossible) and they don't sell UNEs, they are, in fact, pretty much exempt from direct competition for the same services. Owen On Mar 23, 2014, at 8:20 PM, Frank Bulk wrote: > I think I understand what you're saying -- you believe that RLECs that don't > have to provide UNE's are exempt from competition. I guess I don't see the > lack of that requirement meaning that there's no competition -- it just > means that the kind of competition is different. > > Frank > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Sunday, March 23, 2014 10:16 PM > To: Frank Bulk > Cc: nanog at nanog.org > Subject: RE: Level 3 blames Internet slowdowns on Technica > > Many rural LECs are not required to provide unbundled network elements. As > a network provider you can resell their service but they are not required to > provide unbundled elements necessary to compete against them as a facilities > based provider. So, for example, in Alamo Tennessee or Northern Wisconsin > you can get a T-1 from a competitive carrier that resells their services but > you cannot get competitive POTS service. You can buy DSL service from > anyone but they are reselling the RLECs DSL access services not just running > on their cable pairs. One of the biggest players that specializes in being > a rural LEC is Frontier Communications. > > Yes, there are wireless carriers and satellite providers but especially in > rural areas they are not a real viable alternative for high speed data since > we know the characteristic of satellite service and WISPs have the same > density problem in providing service in rural areas. It is hard for a WISP > to be profitable when you only have a handful of customers per mile. Same > formula, low density, long distances, high infrastructure per customer cost > for the WISP. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Sunday, March 23, 2014 10:08 PM > To: Naslund, Steve > Cc: nanog at nanog.org > Subject: RE: Level 3 blames Internet slowdowns on Technica > > Not sure which rural LECs are exempt from competition. Some areas are > effectively exempt from facilities-based (i.e. wireline) competition because > it's unaffordable, without subsidy, to build a duplicate wireline > infrastructure. There are also wireless carriers and WISPs the compete > against RLECs, as well as satellite providers. I'm not aware of any > exclusivity. > > Frank > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Sunday, March 23, 2014 9:00 PM > To: Joe Greco > Cc: nanog at nanog.org > Subject: RE: Level 3 blames Internet slowdowns on Technica > > > > In a low density area you can never fund a build out which is where > universal access charges came from and the reason that rural LECs are exempt > from competition. In return for building a network that is not profitable > easily they get exclusive access to sell services on it to give them a > chance. Will your NRC be reasonable anywhere outside a major metro area? > > > > Steven Naslund > Chicago IL > > > > > > From owen at delong.com Thu Mar 27 05:17:18 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 22:17:18 -0700 Subject: misunderstanding scale In-Reply-To: References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> Message-ID: <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> On Mar 26, 2014, at 3:18 AM, Matthias Leisi wrote: > On Wed, Mar 26, 2014 at 6:31 AM, Owen DeLong wrote: > > >> OTOH, a spammer with a single /64, pretty much the absolute minimum IPv6 >> block, has more than 18 quintillion addresses and there's not a computer on >> the planet with enough memory (or probably not even enough disk space) to >> store that block list. >> > > It only takes a single entry if you do not store /128s but that /64. Yes, > RBL lookups do not currently know how to handle this, but there are a > couple of good proposals around on how to do it. Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. Admittedly, /48s are only 65,536 RBL entries per, but I still think that address-based reputations are a losing battle in an IPv6 world unless we provide some way for providers to hint at block sizes. After all, if you start blocking a /64, what if it?s a /64 shared by thousands of hosting customers at one provider offering virtuals? > > This would also reduce the risks from cache depletion attacks via DNSxL > lookups to IPv4 levels. Yes and no. > > Sometimes scale is everything. host-based reputation lists scale easily to >> 3.2 billion host addresses. IPv6, not so easily. >> > > As soon as we get away from host-centric-view to a network-block-view, > things get pretty straightforward. Except where they don?t. Owen From owen at delong.com Thu Mar 27 05:25:37 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 22:25:37 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5332DF1A.9040001@pari.edu> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> Message-ID: On Mar 26, 2014, at 7:07 AM, Lamar Owen wrote: > On 03/25/2014 10:51 PM, Jimmy Hess wrote: >> >> [snip] >> >> I would suggest the formation of an "IPv6 SMTP Server operator's club," >> with a system for enrolling certain IP address source ranges as "Active >> mail servers", active IP addresses and SMTP domain names under the >> authority of a member. >> > ... > > As has been mentioned, this is old hat. > > There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. > > That way? Make e-mail cost; have e-postage. No, I don't want it either. But where is the pain point for spam where this becomes less painful? If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots. This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it. That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one. If spam ceases to be profitable, it will stop. > > Of course, I reserve the right to be wrong, and this might all just be a pipe dream. (and yes, I've thought about what sort of billing infrastructure nightmare this could be.....) Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. Thoughts? Owen From owen at delong.com Thu Mar 27 05:45:00 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 22:45:00 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53331477.1070701@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> Message-ID: <836694A3-D37D-495C-83DC-AEDD045E1FC4@delong.com> On Mar 26, 2014, at 10:55 AM, Luke S. Crawford wrote: > On 03/24/2014 06:18 PM, Owen DeLong wrote: >> DHCPv6 is no less robust in my experience than DHCPv4. >> >> ARP and ND have mostly equivalent issues. > > This depends a lot on what you mean by 'robust' > > Now, I have dealt with NAT, and I see IPv6 as a technology with the potential to make my life less unpleasant. I really want IPv6 to succeed. > > However, DHCPv6 isn't anywhere near as useful for me, as someone who normally deals with IPs that don't change, as DHCPv4 is. > > With DHCPv4, my customers all get an address based on their mac that doesn't change if their box is re-installed. I configure this on the DHCP server, and the customer can run whatever dhcp client they like on whatever OS they like and they get the same IP every time. Other than it being based on DUID instead of MAC (which, btw, DUID can be based on MAC), this is also possible in DHCP6. > With DHCPv6 there is a time-based identifier that is added to the mac that makes it impossible, as far as I can tell, to give the customer a consistent IP across OS wipes without doing significant client configuration. Nope. Not true. > There are many ways to skin this cat; stateless autoconfig looks like it mostly works, but privacy extensions seem to be the default in many places; outgoing IPv6 from those random addresses will trip my BCP38 filters. That, and reading the standard, it sure doesn't sound like consistency was a goal, even though it seems fairly consistent experimentally. there's a lot of "generally" and "may" in the text about what it adds to the mac in order to get the local identifier. Why would your BCP38 filters be filtering down below the prefix level? The random addresses all still have the same 64 bit prefix. For non-privacy addresses, it?s very clear? 64 bit mac is just used. 48 bit mac is OR?d with 0x0200 0000 0000 and then split at the OUI/ESI boundary (24 bits) where 0xfffe is inserted. Thus 1234.5678.abcd would become 1234.56ff.fe78.abcd and 0123.4567.89ab would become 0323.45ff.fe67.89ab. For privacy addresses, this is kind of all over the map and multiple different algorithms with different entropic properties are proposed. Worse, Micr0$0ft doesn?t conform to the standard at all and, instead, uses no entropy to provide an address that is different per prefix, but the same every time for the same prefix. > It might make sense to just give everyone their own vlan and their own /64; that would, of course, bring its own problems and complexities (namely that I've gotta have the capability to deal with more customers than I can have native vlans - not impossible to get around, but significant added complexity.) I don?t see the point of that. > I suppose I can also just keep DHCPv4 around, and if folks want IPv6, well, they have to wire down the address themselves. That's how I'm doing it now. > That seems unnecessarily difficult. Owen From owen at delong.com Thu Mar 27 06:03:24 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 23:03:24 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5333329F.8030106@pari.edu> References: <20140325172328.5224.qmail@joyce.lan> <5333329F.8030106@pari.edu> Message-ID: LoL Spellcheck? Helping you correctly spell the incorrect word every time. Owen On Mar 26, 2014, at 1:03 PM, Lamar Owen wrote: > On 03/26/2014 03:56 PM, Lamar Owen wrote: >> >> Most of the phishing e-mails I've sent don't have a valid reply-to, from, or return-path; replying to them is effectively impossible, and the linked/attached/inlined payload is the attack vector. >> >> >> > Blasted spellcheck.... Now that everybody has had a good laugh; I've not 'sent' *any* phishing e-mails, but I have *seen* plenty. Argh. > From owen at delong.com Thu Mar 27 06:14:55 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 23:14:55 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53336205.2010206@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> <53336205.2010206@prgmr.com> Message-ID: On Mar 26, 2014, at 4:25 PM, Luke S. Crawford wrote: > On 03/26/2014 03:49 PM, Matt Palmer wrote: >> On Wed, Mar 26, 2014 at 10:55:03AM -0700, Luke S. Crawford wrote: >>> There are many ways to skin this cat; stateless autoconfig looks >>> like it mostly works, but privacy extensions seem to be the default >>> in many places; outgoing IPv6 from those random addresses will trip >>> my BCP38 filters. >> >> Your what-now? You do realise SLAAC works entirely within a single /64, >> which shouldn't be difficult to decide is either routable or not in one hit, >> right? > > If you give every customer their own vlan and /64, sure. That can be done, and there are many advantages to doing it that way. But it's quite a bit more complex than my current setup. > > The way I'm setup now, I've got an IPv4 address block on a vlan, and an IPv6/64 on the same vlan. I have many customers on that vlan. Each customer has one (or more) IPv4 /32 addresses and one IPv6 /128 addresses. (if the customer wants more IPv6, we just route a /64 to the /128 they are allowed.) There are firewall rules that only allow appropriate packets in and out of the interface. These rules are important for privacy as well as preventing spoofing; they prevent sniffing of most traffic bound for other guests. Why not just use private VLAN layer 2 controls for the privacy you describe? Yes, you risk customer A spoofing customer B, but is that really a problem in your environment? Really? If so, one could argue you might want to consider getting a better class of customers. Owen From owen at delong.com Thu Mar 27 06:20:00 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 23:20:00 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <20140327005039.GB7867@angus.ind.WPI.EDU> References: <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> <53336205.2010206@prgmr.com> <20140327005039.GB7867@angus.ind.WPI.EDU> Message-ID: <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> On Mar 26, 2014, at 5:50 PM, Chuck Anderson wrote: > On Wed, Mar 26, 2014 at 06:52:53PM -0500, Timothy Morizot wrote: >> On Mar 26, 2014 6:27 PM, "Luke S. Crawford" wrote: >>> My original comment and complaint, though, was in response to the >> assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 >> does not fill the role that DHCPv4 fills, if you care about tying an IP to >> a MAC and you want that connection to persist across OS installs by >> customers. >> >> You're right. DHCPv6 is more robust than DHCPv4. At least those of us in >> the enterprise space appreciate a client identifier that doesn't change >> when the hardware changes. > > No, it is LESS robust, because the client identifier changes when the > SOFTWARE changes. Around here, software changes MUCH more often than > hardware. Heck, even a dual-boot scenario breaks the client > identifier stability. Worse yet, DHCPv6 has created a scenario where > a client's IPv4 connectivity and IPv6 connectivity break under > /different/ scenarios, causing difficult-to-troubleshoot > half-connectivity issues when either the hardware is replaced or the > software is reloaded. Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6?s fault. DHCPv6 is perfectly capable of behaving as you wish. Blaming the protocol for poor implementation choices by your (or your client?s) vendors is a little odd in my opinion. Owen From owen at delong.com Thu Mar 27 06:26:44 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 23:26:44 -0700 Subject: IPv6 isn't SMTP In-Reply-To: <5333970A.6070107@direcpath.com> References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> <5333970A.6070107@direcpath.com> Message-ID: <9F773913-3350-485E-9BE3-706B2AAE5CA5@delong.com> On Mar 26, 2014, at 8:12 PM, Robert Drake wrote: > > On 3/26/2014 10:16 PM, Franck Martin wrote: >> >> and user at 2001:db8::1.25 with user at 192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. > At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. > > From: > http://tools.ietf.org/html/rfc3986#section-3.2.2 > Two errors, actually? As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). Owen From owen at delong.com Thu Mar 27 06:31:40 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Mar 2014 23:31:40 -0700 Subject: Level 3 blames Internet slowdowns on Technica In-Reply-To: <005c01cf497b$0b8e1660$22aa4320$@iname.com> References: <9578293AE169674F9A048B2BC9A081B4B5420CA4@MUNPRDMBXA1.medline.com> <201403211501.s2LF171x005077@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B4B54217B2@MUNPRDMBXA1.medline.com> <001601cf470e$47b1c2a0$d71547e0$@iname.com> <9578293AE169674F9A048B2BC9A081B4B542186E@MUNPRDMBXA1.medline.com> <001c01cf4710$0441be60$0cc53b20$@iname.com> <005c01cf497b$0b8e1660$22aa4320$@iname.com> Message-ID: <4F3F2424-FE0C-4F94-97D3-FC9AE38DB1C6@delong.com> Depends. On some services (L3, etc.), yes, they compete. That should not be conflated with competing at the L1 service. MSOs deliver L1 co-ax or HFC. RLECs deliver copper pairs and/or GPON. Satellite is it?s own peculiar sets of L1 transport. None of them compete head-to-head on the same technology on L1. Owen On Mar 26, 2014, at 10:11 PM, Frank Bulk wrote: > And MSOs, wireless carriers, and satellite providers aren't competitors to > RLECs? > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, March 24, 2014 9:05 PM > To: Frank Bulk > Cc: Naslund, Steve; nanog at nanog.org > Subject: Re: Level 3 blames Internet slowdowns on Technica > > Since a second build-out is impractical (if not actually impossible) and > they don't > sell UNEs, they are, in fact, pretty much exempt from direct competition for > the > same services. > > Owen > > On Mar 23, 2014, at 8:20 PM, Frank Bulk wrote: > >> I think I understand what you're saying -- you believe that RLECs that > don't >> have to provide UNE's are exempt from competition. I guess I don't see > the >> lack of that requirement meaning that there's no competition -- it just >> means that the kind of competition is different. >> >> Frank >> >> -----Original Message----- >> From: Naslund, Steve [mailto:SNaslund at medline.com] >> Sent: Sunday, March 23, 2014 10:16 PM >> To: Frank Bulk >> Cc: nanog at nanog.org >> Subject: RE: Level 3 blames Internet slowdowns on Technica >> >> Many rural LECs are not required to provide unbundled network elements. > As >> a network provider you can resell their service but they are not required > to >> provide unbundled elements necessary to compete against them as a > facilities >> based provider. So, for example, in Alamo Tennessee or Northern Wisconsin >> you can get a T-1 from a competitive carrier that resells their services > but >> you cannot get competitive POTS service. You can buy DSL service from >> anyone but they are reselling the RLECs DSL access services not just > running >> on their cable pairs. One of the biggest players that specializes in > being >> a rural LEC is Frontier Communications. >> >> Yes, there are wireless carriers and satellite providers but especially in >> rural areas they are not a real viable alternative for high speed data > since >> we know the characteristic of satellite service and WISPs have the same >> density problem in providing service in rural areas. It is hard for a > WISP >> to be profitable when you only have a handful of customers per mile. Same >> formula, low density, long distances, high infrastructure per customer > cost >> for the WISP. >> >> Steven Naslund >> Chicago IL >> >> -----Original Message----- >> From: Frank Bulk [mailto:frnkblk at iname.com] >> Sent: Sunday, March 23, 2014 10:08 PM >> To: Naslund, Steve >> Cc: nanog at nanog.org >> Subject: RE: Level 3 blames Internet slowdowns on Technica >> >> Not sure which rural LECs are exempt from competition. Some areas are >> effectively exempt from facilities-based (i.e. wireline) competition > because >> it's unaffordable, without subsidy, to build a duplicate wireline >> infrastructure. There are also wireless carriers and WISPs the compete >> against RLECs, as well as satellite providers. I'm not aware of any >> exclusivity. >> >> Frank >> >> -----Original Message----- >> From: Naslund, Steve [mailto:SNaslund at medline.com] >> Sent: Sunday, March 23, 2014 9:00 PM >> To: Joe Greco >> Cc: nanog at nanog.org >> Subject: RE: Level 3 blames Internet slowdowns on Technica >> >> >> >> In a low density area you can never fund a build out which is where >> universal access charges came from and the reason that rural LECs are > exempt >> from competition. In return for building a network that is not profitable >> easily they get exclusive access to sell services on it to give them a >> chance. Will your NRC be reasonable anywhere outside a major metro area? >> >> >> >> Steven Naslund >> Chicago IL >> >> >> >> >> >> > > From mark.tinka at seacom.mu Thu Mar 27 07:38:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Mar 2014 09:38:20 +0200 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53331BC6.1090309@pari.edu> References: <53331BC6.1090309@pari.edu> Message-ID: <201403270938.21308.mark.tinka@seacom.mu> On Wednesday, March 26, 2014 08:26:14 PM Lamar Owen wrote: > You don't. Their upstream(s) in South Africa would bill > them for outgoing e-mail. Not all of 41/8 is served by South Africa :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jimpop at gmail.com Thu Mar 27 07:48:09 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 27 Mar 2014 03:48:09 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <201403270938.21308.mark.tinka@seacom.mu> References: <53331BC6.1090309@pari.edu> <201403270938.21308.mark.tinka@seacom.mu> Message-ID: On Thu, Mar 27, 2014 at 3:38 AM, Mark Tinka wrote: > > Not all of 41/8 is served by South Africa :-). > But a significant portion of it routes through London :-) *cough *cough co.tz to co.za, etc., etc. -Jim P. From matthias at leisi.net Thu Mar 27 07:47:59 2014 From: matthias at leisi.net (Matthias Leisi) Date: Thu, 27 Mar 2014 08:47:59 +0100 Subject: misunderstanding scale In-Reply-To: <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> Message-ID: On Thu, Mar 27, 2014 at 6:17 AM, Owen DeLong wrote: > > It only takes a single entry if you do not store /128s but that /64. Yes, > > RBL lookups do not currently know how to handle this, but there are a > > couple of good proposals around on how to do it. > > Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. > > Admittedly, /48s are only 65,536 RBL entries per, but I still think that > address-based > reputations are a losing battle in an IPv6 world unless we provide some > way for providers > to hint at block sizes. > That's why I believe having varying levels of granularity is the best trade off between cache friendliness, administrative effort and implementation complexity, independent on whether it's "default deny" or "default accept". We either need to solve (or reduce the impact of) the DNS cache issue or we need to solve the fixed-range issue. Or IP-based reputation as we know it today is more or less dropped from the anti-spam toolset when it comes to IPv6. -- Matthias From sthaug at nethelp.no Thu Mar 27 07:52:06 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 27 Mar 2014 08:52:06 +0100 (CET) Subject: IPv6 Security In-Reply-To: <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> References: <20140327005039.GB7867@angus.ind.WPI.EDU> <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> Message-ID: <20140327.085206.74744053.sthaug@nethelp.no> > > No, it is LESS robust, because the client identifier changes when the > > SOFTWARE changes. Around here, software changes MUCH more often than > > hardware. Heck, even a dual-boot scenario breaks the client > > identifier stability. Worse yet, DHCPv6 has created a scenario where > > a client's IPv4 connectivity and IPv6 connectivity break under > > /different/ scenarios, causing difficult-to-troubleshoot > > half-connectivity issues when either the hardware is replaced or the > > software is reloaded. > > Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6?s fault. It is reality. DHCPv6 needs to take reality into account. DHCPv6 as defined in RFC 3315 does not offer client MAC address at all (thus making the job more difficult for a number of organizations). All I've seen so far indicates that this was a deliberate choice by the DHCPv6 designers, and in my opinion a very poor one. Fortunately we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and we're waiting for vendors to implement this. That solves one half of the problem. The other half is to actually let the DHCPv6 lease be based directly on the MAC address. The language in RFC 3315, as I read it, makes this difficult or impossible. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mark.tinka at seacom.mu Thu Mar 27 07:55:30 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Mar 2014 09:55:30 +0200 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <201403270938.21308.mark.tinka@seacom.mu> Message-ID: <201403270955.30590.mark.tinka@seacom.mu> On Thursday, March 27, 2014 09:48:09 AM Jim Popovitch wrote: > > But a significant portion of it routes through London :-) > > *cough *cough co.tz to co.za, etc., etc. Perhaps, but that does not mean it's all served by South African ISP's. The London trombone is a separate issue. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From h.wahl at ifw-dresden.de Thu Mar 27 08:16:45 2014 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Thu, 27 Mar 2014 09:16:45 +0100 Subject: IPv6 Security In-Reply-To: <20140327.085206.74744053.sthaug@nethelp.no> References: <20140327005039.GB7867@angus.ind.WPI.EDU> <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> <20140327.085206.74744053.sthaug@nethelp.no> Message-ID: <5333DE6D.10700@ifw-dresden.de> > It is reality. DHCPv6 needs to take reality into account. > One modest attempt to do so is dhcpy6d at https://dhcpy6d.ifw-dresden.de. Still work in progress and might not fit into every environment but helps some others. Regards -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From mansaxel at besserwisser.org Thu Mar 27 09:22:31 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 27 Mar 2014 10:22:31 +0100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> Message-ID: <20140327092231.GH10032@besserwisser.org> Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Wed, Mar 26, 2014 at 03:35:48PM -0400 Quoting John R. Levine (johnl at iecc.com): > >>It must be nice to live in world where there is so little spam and > >>other mail abuse that you don't have to do any of the anti-abuse > >>things that real providers in the real world have to do. > > > >What is a real provider? And what in the email specifications tells us > >that the email needs and solutions of any one individual, as long as they > >are following protocol (which I'm quite convinced Mark is) are "unreal"? > > A real provider is one that provides mail for real users, as opposed > to someone who plays RFC language lawyer games. I only have a few > dozen users, but I can assure you I use a whole lot of different > filtering approaches including DNSBLs to keep my users' mailboxes > usable. Ergo, ad hominem. Please quit doing that. As a side note I happen to run my own mail server without spam filters -- it works for me. I might not be the norm, but then again, is there really a norm? (A norm that transcends SMTP RFC reach, that is -- the necessity to stick to protocol is not under debate) > I must say it's pretty amusing that someone who works for the > organization that published the original DNSBL seems to be ranting > against them. The ability to change ones mind when circumstances change is usually seen as advantageous. Why not here? -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 This is a NO-FRILLS flight -- hold th' CANADIAN BACON!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From david at mailplus.nl Thu Mar 27 09:37:32 2014 From: david at mailplus.nl (David Hofstee) Date: Thu, 27 Mar 2014 10:37:32 +0100 Subject: [mailop] IPv6 DNSBL In-Reply-To: <53336B85.5040004@linuxmagic.com> References: <20140326234210.14730.qmail@joyce.lan> <53336B85.5040004@linuxmagic.com> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75AE91A5B0@SBS1.blinker.local> I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. And I would like fine-grained complaining possible (so everyone can filter like the big boys can, one might need the 'ham' numbers too). But you want to be sure such numbers are authentic. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: mailop [mailto:mailop-bounces at mailop.org] Namens Michael Peddemors Verzonden: Thursday, March 27, 2014 1:06 AM Aan: mailop at mailop.org Onderwerp: Re: [mailop] IPv6 DNSBL On 14-03-26 04:42 PM, John Levine wrote: > As a reliable rule of thumb, any list that's large enough to be > interesting is also large enough to be compromised. > > I know people who have run whitelists at Returnpath, and I was in > charge of the never very successful Spamhaus whitelist. The ones at > Returnpath always said that much of the job was dealing with bullshit > and deception from people trying to sneak into the whitelist. At > Spamhaus, the main problem was that nearly all of the people willing > to go to the effort to be whitelisted didn't qualify, which wasn't > surprising, since people with good mail behavior rarely have trouble > getting their mail delivered. > > R's, > John Here Here.. (For instance, we recommend that people running filtering turn those off right away, eg SA..) But we do see a lot of people discussing this here, and at the risk of making even more noise on this list on this subject, and maybe we should kill the thread there.. It would be interesting to get a poll of sorts.. hands please.. (You can reply off-list) Options: 1) Only allow IPv4 to be used for MTA's 2) Create a Registry of Operators/IPs for MTA's on IPv6 3) Allow all IPv6 to be used for MTA's, and use blacklists 4) Other (Suggestions) And if you believe in item 2, (personally I am happy with 1 or 2 and open to 4) what would you expect such a registry to look like? -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. _______________________________________________ mailop mailing list mailop at mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop From wwaites at tardis.ed.ac.uk Thu Mar 27 10:09:48 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Thu, 27 Mar 2014 10:09:48 +0000 Subject: WISP or other options In-Reply-To: <53339B53.9040700@wiredmedium.com> References: <53339B53.9040700@wiredmedium.com> Message-ID: <20140327100948.GI2267@mavrino.styx.org> On Wed, Mar 26, 2014 at 10:30:27PM -0500, Nick wrote: > > Does any have contacts in Edinburgh Scotland who can provide WISP > service at the Hopetoun House and Dundas Castle. I would like to > have 20-60mpbs to for 2 days of services. There is a *chance* that we (http://hubs.net.uk/) can help. Our network in Edinburgh is mostly constructed for serving areas to the South -- the Lothians, the Borders, etc. and South Queensferry is to the Northwest. So one way of doing this would be to find an intermediate spot and make two links. Briefly consulting a map there are a few candidates, and for some, a temporary relay (the broadband wagon parked on a hilltop) might work. It also looks as though there may be line of sight to Scolocate in South Gyle which is a major datacentre where IX Scotland is -- unfortunately we don't have anything on the roof there at the moment. If the event is for some sort of not for profit or academic related thing other possibilities open up as well, it may be possible to use one of the universities' networks to get most of the way there. There are definitely possibilities, but it may well be too expensive for such a short duration. Send me a mail off list if you want to discuss in more detail. > Our company's event planner claims there are no good ISP options in > the area and wants us to go with satellite internet which is pricy > and has high latency. Its worth noting both locations have ~7mpbs > DLS. It would be interesting to talk to this event planner... Another option is bonded ADSL. I'd recommend Andrews and Arnold (http://aa.net.uk/) for that. It's a bit ugly, and any DSL or FTTx is very expensive for real use (BT Wholesale's tarrif for bandwidth on their DSL carrier interconnect for resale is something like -L-40/Mbps plus lots of other charges) but for a temporary situation it's not a bad option. Cheers, -w From wwaites at tardis.ed.ac.uk Thu Mar 27 10:10:02 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Thu, 27 Mar 2014 10:10:02 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> Message-ID: <20140327101002.GJ2267@mavrino.styx.org> On Thu, Mar 27, 2014 at 03:35:20AM +0000, Warren Bailey wrote: > > You are screwed for LOS microwave, 60mbps on a microwave hope requires > real life engineering to function correctly. Well now, really. Yes it needs engineering, but nothing spectacularly difficult. The upper bound on distance the OP needs is something like 10 miles which is peanuts. Any of your typical off the shelf 5GHz stuff will do that, you can even just eyeball the alignment. The upper 5GHz band is not very crowded around here. You do need line of sight which means spending a little time with a topo map. You're right that it isn't as simple as just putting up some antennas, leaving the kit at factory defaults and hoping, but that's not a very high bar. > towers Rather conveniently there are lots of hills around here. A typical can easily be something made out of standard scaffolding not more than 2.5m tall. You try to build them at the top of steep bits so that people (and sheep) can't easily stand in front of the antennas. > If you?re looking for satellite Satellite is a last resort, and almost always unnecessary even in very remote places. It is also, as you point out, extremely expensive. Best, -w From wwaites at tardis.ed.ac.uk Thu Mar 27 10:10:13 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Thu, 27 Mar 2014 10:10:13 +0000 Subject: WISP or other options In-Reply-To: <5333A2D6.5010302@meetinghouse.net> References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> Message-ID: <20140327101013.GK2267@mavrino.styx.org> On Thu, Mar 27, 2014 at 12:02:30AM -0400, Miles Fidelman wrote: > Laser link, and pray for clear weather? You'll have to pray really hard around here, especially in South Queensferry down by the water... We actually have an FSO link between two tall buildings in South Edinburgh. Only about 500m. It works pretty well except when the haar rolls in. Giant pain in the behind to align though, and given that the wind that comes over the top of these tall buildings can be 5x that at ground level, and gales happen several times a year, keeping them aligned is... interesting... -w From wwaites at tardis.ed.ac.uk Thu Mar 27 10:10:25 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Thu, 27 Mar 2014 10:10:25 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> Message-ID: <20140327101025.GL2267@mavrino.styx.org> On Thu, Mar 27, 2014 at 05:09:05AM +0000, Warren Bailey wrote: > It's not 802.11 and it doesn't act that way. Actually most of the installations I've seen -- and my day job is working with community networks around Scotland that have built all manner of strange things -- the problems most often have nothing at all to do with the physical layer. More often they're related to doing things with spanning tree that we all learned in networking long ago to not do, or running many layers of NAT because IP routing is not understood. Things like that. The only common RF problem is leaving the channel selection on "auto". Which invariably means one radio, like an access point with a sector antenna, can't hear the point to point link coming in to the dish behind it and picks the wrong channel. Again, yes, you're right, you have to understand how this stuff works and think a little bit when you build, but your messages saying "It's really really hard" are coming across a little like FUD. > A pair of Air Fiber is like 3k USD, and at 24ghz you had better know The AF24 are also illegal here. Or rather the lower channel belongs to the police, and the upper channel is limited to a very low output power. We have a pair of these, with a special non-operational license from Ofcom to put them through their paces. They do work, though they are a pain to align and subject to rain fade. They are on the West coast which is very rainy. Right now we're using them to measure rain intensity rather than to carry real traffic (which we can't do with a non-op license anyways). -w From fmartin at linkedin.com Thu Mar 27 10:24:54 2014 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 27 Mar 2014 10:24:54 +0000 Subject: IPv6 isn't SMTP In-Reply-To: <9F773913-3350-485E-9BE3-706B2AAE5CA5@delong.com> References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> <5333970A.6070107@direcpath.com> <9F773913-3350-485E-9BE3-706B2AAE5CA5@delong.com> Message-ID: On Mar 26, 2014, at 11:26 PM, Owen DeLong wrote: > > On Mar 26, 2014, at 8:12 PM, Robert Drake wrote: > >> >> On 3/26/2014 10:16 PM, Franck Martin wrote: >>> >>> and user at 2001:db8::1.25 with user at 192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. >> At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. >> >> From: >> http://tools.ietf.org/html/rfc3986#section-3.2.2 >> > > Two errors, actually? As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). > indeed, but MTAs are know to accept any kind of non RFC compliant emails and trying to make some sense out of it? :P see http://tools.ietf.org/html/rfc7103 which tries to address some of it in a more deterministic way. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Thu Mar 27 12:34:23 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 05:34:23 -0700 Subject: IPv6 Security In-Reply-To: <20140327.085206.74744053.sthaug@nethelp.no> References: <20140327005039.GB7867@angus.ind.WPI.EDU> <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> <20140327.085206.74744053.sthaug@nethelp.no> Message-ID: <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com> On Mar 27, 2014, at 12:52 AM, sthaug at nethelp.no wrote: >>> No, it is LESS robust, because the client identifier changes when the >>> SOFTWARE changes. Around here, software changes MUCH more often than >>> hardware. Heck, even a dual-boot scenario breaks the client >>> identifier stability. Worse yet, DHCPv6 has created a scenario where >>> a client's IPv4 connectivity and IPv6 connectivity break under >>> /different/ scenarios, causing difficult-to-troubleshoot >>> half-connectivity issues when either the hardware is replaced or the >>> software is reloaded. >> >> Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6?s fault. > > It is reality. DHCPv6 needs to take reality into account. > > DHCPv6 as defined in RFC 3315 does not offer client MAC address at all > (thus making the job more difficult for a number of organizations). Yes it does? What do you think ?Link Layer Address? (RFC 3315, Section 9.1 Type 3) is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what this is intended to be. True, it includes an additional 16 bits of media type, but I don?t see that as being a problem. > All I've seen so far indicates that this was a deliberate choice by > the DHCPv6 designers, and in my opinion a very poor one. Fortunately > we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and > we're waiting for vendors to implement this. That solves one half of > the problem. Yes and no. At the time RFC3315 was written, network cards changed independent of motherboards on a regular basis and this fact was a source of great consternation for DHCPv4 operators. Over time, that changed AFTER RFC3315 was written, but if you read section 9.4, it seems pretty clear that this change was anticipated by the authors and that DUID-LL was intended for the situation we have today. Clients failing to implement DUID-LL as defined in RFC-3315 can hardly be blamed on DHCPv6. > The other half is to actually let the DHCPv6 lease be based directly > on the MAC address. The language in RFC 3315, as I read it, makes this > difficult or impossible. Reread section 9.4? It seems not only possible, but recommended from my reading. The problem isn?t that the MAC address isn?t allowed. The problem is that the clients aren?t properly using permanent MAC addresses as DUID. Owen From owen at delong.com Thu Mar 27 12:39:49 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 05:39:49 -0700 Subject: [mailop] IPv6 DNSBL In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75AE91A5B0@SBS1.blinker.local> References: <20140326234210.14730.qmail@joyce.lan> <53336B85.5040004@linuxmagic.com> <78C35D6C1A82D243B830523B4193CF5F75AE91A5B0@SBS1.blinker.local> Message-ID: <7A34FFDC-C548-4AF1-89B0-B64270410D41@delong.com> On Mar 27, 2014, at 2:37 AM, David Hofstee wrote: > I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. Owen From owen at delong.com Thu Mar 27 12:40:38 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 05:40:38 -0700 Subject: IPv6 isn't SMTP In-Reply-To: References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> <5333970A.6070107@direcpath.com> <9F773913-3350-485E-9BE3-706B2AAE5CA5@delong.com> Message-ID: <2E023CA5-02D6-4280-8371-18DA1D31FD27@delong.com> On Mar 27, 2014, at 3:24 AM, Franck Martin wrote: > > On Mar 26, 2014, at 11:26 PM, Owen DeLong wrote: > >> >> On Mar 26, 2014, at 8:12 PM, Robert Drake wrote: >> >>> >>> On 3/26/2014 10:16 PM, Franck Martin wrote: >>>> >>>> and user at 2001:db8::1.25 with user at 192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. >>> At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. >>> >>> From: >>> http://tools.ietf.org/html/rfc3986#section-3.2.2 >>> >> >> Two errors, actually? As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). >> > indeed, but MTAs are know to accept any kind of non RFC compliant emails and trying to make some sense out of it? :P see http://tools.ietf.org/html/rfc7103 which tries to address some of it in a more deterministic way. > Sure, but that doesn?t mean we should be sending random garbage deliberately. Owen From shawnl at up.net Thu Mar 27 12:44:18 2014 From: shawnl at up.net (Shawn L) Date: Thu, 27 Mar 2014 08:44:18 -0400 Subject: Access Lists for Subscriber facing ports? Message-ID: With all of the new worms / denial of service / exploits, etc. that are coming out, I'm wondering what others are using for access-lists on residential subscriber-facing ports. We've always taken the stance of 'allow unless there is a compelling reason not to', but with everything that is coming out lately, I'm not sure that's the correct position any more. thanks From david at mailplus.nl Thu Mar 27 13:21:02 2014 From: david at mailplus.nl (David Hofstee) Date: Thu, 27 Mar 2014 14:21:02 +0100 Subject: [mailop] IPv6 DNSBL In-Reply-To: <7A34FFDC-C548-4AF1-89B0-B64270410D41@delong.com> References: <20140326234210.14730.qmail@joyce.lan> <53336B85.5040004@linuxmagic.com> <78C35D6C1A82D243B830523B4193CF5F75AE91A5B0@SBS1.blinker.local> <7A34FFDC-C548-4AF1-89B0-B64270410D41@delong.com> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75AE91A642@SBS1.blinker.local> >> I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. >Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. True. But the world must progress too. It would be nice if the spam-issue is better solved on IPv6 (than on IPv4). You would then have a reason to /not/ accept on IPv4 (and give IPv6 a boost). There must be a good reason for people to get of their asses and start implementing things like DMARC. All the banks (!$%^) I talk to do not have any reason to implement it swiftly (they turn on p=none and then all progress stops). Frustrating that they are too lazy to implement a few DNS records. It only needs firm backing by 3+ large companies like Hotmail. Give everyone on IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). Give me ammunition and all corporates will move. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: Owen DeLong [mailto:owen at delong.com] Verzonden: Thursday, March 27, 2014 1:40 PM Aan: David Hofstee CC: Michael Peddemors; nanog at nanog.org Onderwerp: Re: [mailop] IPv6 DNSBL On Mar 27, 2014, at 2:37 AM, David Hofstee wrote: > I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. Owen From mike-nanog at tiedyenetworks.com Thu Mar 27 13:40:11 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 27 Mar 2014 06:40:11 -0700 Subject: Access Lists for Subscriber facing ports? In-Reply-To: References: Message-ID: <53342A3B.6080004@tiedyenetworks.com> On 03/27/2014 05:44 AM, Shawn L wrote: > With all of the new worms / denial of service / exploits, etc. that are > coming out, I'm wondering what others are using for access-lists on > residential subscriber-facing ports. > > We've always taken the stance of 'allow unless there is a compelling reason > not to', but with everything that is coming out lately, I'm not sure that's > the correct position any more. As a residential ISP, we have seen quite a lot of this in terms of both compromised customer computers spewing spam and ddos, as well as compromised customer routers participating in ddos attacks as well as dns redirection exploits for phishing and other purposes. I too am an advocate of staying out of the way as much as possible, but I've come around to realize that the average customer NEEDS to be protected against the consequences of their ignorance, MORE than they need the freedom to run a publicly accessible dns or ntp server. We now have a default access list in place which locks down subscriber ports and prevents them from being a server on commonly exploited services like dns,ntp,smtp and so forth. The average customer neither knows nor cares, and suffers absolutely nothing because of it. What tipped it over for me was a rash of dns changers that exploited unknown to us default credentials in a number of subscriber modems, causing no end of customers who secretly depended on a set of DNS resolvers controlled by attackers that were performing poorly and resulting in 'why is it slow?' calls to my support staff. These devices should never have internet facing management, but they do and they did. I should also say that the acl's are also easily removable for any customer who asks. We don't make a big production out of it or anything, we just put the flag on their account and thats that. Mike- From chip at 2bithacker.net Thu Mar 27 13:41:14 2014 From: chip at 2bithacker.net (Chip Marshall) Date: Thu, 27 Mar 2014 09:41:14 -0400 Subject: misunderstanding scale In-Reply-To: <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> References: <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> Message-ID: <20140327134114.GA36777@2bithacker.net> On 2014-03-26, Owen DeLong sent: > Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. > > Admittedly, /48s are only 65,536 RBL entries per, but I still > think that address-based reputations are a losing battle in an > IPv6 world unless we provide some way for providers to hint at > block sizes. > > After all, if you start blocking a /64, what if it?s a /64 > shared by thousands of hosting customers at one provider > offering virtuals? It was brought to my attention in a parallel thread on Mailop that such a mechanism does exist for allowing ISP to hint about the size of customer allocations, at least in the RIPE database: http://www.ripe.net/ripe/docs/ripe-513 So how do we make this universal and get ISPs to use it? If we know customer sizes, it becomes much easier to do reputation on a per-customer basis, which is probably granular enough for a lot of cases. -- Chip Marshall http://2bithacker.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From blake at ispn.net Thu Mar 27 13:51:49 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 27 Mar 2014 08:51:49 -0500 Subject: IPv6 isn't SMTP In-Reply-To: References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> Message-ID: <53342CF5.3090009@ispn.net> Jimmy Hess wrote the following on 3/26/2014 7:12 PM: > > The problem is with SMTP and is probably best addressed in the > application layer through updates to SMTP or required bolt-ons > (e.g SPF or similar); it was just simpler > > > SPF is useful, but not a complete solution. > > I'm curious what form you think these updates to SMTP would take? > What changes to SMTP protocol itself could really have a meaningful > impact, > > without frustrating, confusing, or terribly complicating the lives of > millions of mail users? > The primary issues I see with SMTP as a protocol related to the lack of authentication and authorization. Take, for instance, the fact that the SMTP protocol requires a mail from: and rcpt to: address (more or less for authentication and authorization purposes), but then in the message allows the sender to specify a completely different set of sender and recipient information that gets displayed in the mail client. SMTP is simple, it is reliable, and it works well for delivering a message, but it does not address authentication or authorization of remote users (to my knowledge). An extension to SMTP that provides some form of authentication and authorization for remote users could address the abuse concerns. For example, one could utilize a public key infrastructure through previously shared vcard or similar contact information to both authenticate and authorize a sender to be allowed to send email to a recipient. There are probably a few ways to accomplish the same goal, a PKI is just one example. This would allow one to configure his or her email as either 'default allow' to receive email from anyone at any time or 'default deny' to only allow authorized senders. There are some folks doing this today outside of SMTP, but without a mass effort these schemes will probably not take a strong foothold. Implementing something like this takes some work in the mail client to be able to generate a private key and hold the public key info of others. Realistically, the key information could be exchanged and verified simply between clients at the remote ends without any SMTP server involvement, but that seems like a waste for servers to process and store messages that are going to be junked in the end that it would make sense that the SMTP servers could also be able to make these decisions server side. On the other hand, putting spam filtering in the hands of the end users could really untie the server operators from costly or cumbersome anti-SPAM efforts. Any open source email clients want to take this task on and build an industry consensus? I'm all for having my emails tagged as trusted/authorized or untrusted/unauthorized in my email client. Once the level of untrusted, yet legitimate, messages drops to a low enough level I can stop accepting untrusted messages altogether. --Blake From dot at dotat.at Thu Mar 27 13:52:27 2014 From: dot at dotat.at (Tony Finch) Date: Thu, 27 Mar 2014 13:52:27 +0000 Subject: IPv6 isn't SMTP In-Reply-To: <20140327020833.15253.qmail@joyce.lan> References: <20140327020833.15253.qmail@joyce.lan> Message-ID: John Levine wrote: > > There are also some odd things in the spec. For example, according to > RFC 5321 this is not a syntactically valid e-mail address: > > mailbox@[IPv6:2001:12:34:56::78:ab:cd] You aren't allowed to use :: to abbreviate one zero hexadectet according to RFC 5952. http://www.rfc-editor.org/errata_search.php?eid=2467 Tony. -- f.anthony.n.finch http://dotat.at/ Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest. Showers. Good, occasionally moderate. From keastes at gmail.com Wed Mar 26 16:52:42 2014 From: keastes at gmail.com (kendrick eastes) Date: Wed, 26 Mar 2014 10:52:42 -0600 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: The Full-disclosure mailing list was recently... retired, I guess cisco thought NANOG was the next best place. On Wed, Mar 26, 2014 at 10:45 AM, rwebb at ropeguru.com wrote: > > Is this normal for the list to diretly get Cisco security advisories or > something new. First time I have seen these. > > Robert > > > On Wed, 26 Mar 2014 12:10:00 -0400 > Cisco Systems Product Security Incident Response Team > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Cisco IOS Software SSL VPN Denial of Service Vulnerability >> >> Advisory ID: cisco-sa-20140326-ios-sslvpn >> >> Revision 1.0 >> >> For Public Release 2014 March 26 16:00 UTC (GMT) >> >> Summary >> ======= >> >> A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco >> IOS Software could allow an unauthenticated, remote attacker to cause a >> denial of service (DoS) condition. >> >> The vulnerability is due to a failure to process certain types of HTTP >> requests. To exploit the vulnerability, an attacker could submit crafted >> requests designed to consume memory to an affected device. An exploit could >> allow the attacker to consume and fragment memory on the affected device. >> This may cause reduced performance, a failure of certain processes, or a >> restart of the affected device. >> >> Cisco has released free software updates that address this vulnerability. >> There are no workarounds to mitigate this vulnerability. >> >> This advisory is available at the following link: >> http://tools.cisco.com/security/center/content/ >> CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn >> >> Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled >> publication includes six Cisco Security Advisories. All advisories address >> vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security >> Advisory lists the Cisco IOS Software releases that correct the >> vulnerability or vulnerabilities detailed in the advisory as well as the >> Cisco IOS Software releases that correct all Cisco IOS Software >> vulnerabilities in the March 2014 bundled publication. >> >> Individual publication links are in Cisco Event Response: Semiannual >> Cisco IOS Software Security Advisory Bundled Publication at the following >> link: >> >> http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ >> mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i >> uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc >> X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd >> atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn >> dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo >> RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 >> 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ >> 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd >> EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB >> ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 >> RF3x0wYuErbbC7N9m1UH >> =1Ixo >> -----END PGP SIGNATURE----- >> >> > > From sbuettner at frii.net Wed Mar 26 14:58:12 2014 From: sbuettner at frii.net (Scott Buettner) Date: Wed, 26 Mar 2014 08:58:12 -0600 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <911CEC5C-2011-4C8D-9CC1-89DF2B4CB2C1@heliacal.net> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <911CEC5C-2011-4C8D-9CC1-89DF2B4CB2C1@heliacal.net> Message-ID: <5332EB04.9070409@frii.net> This is totally ignoring a few facts. A: That the overwhelming majority of users don't have the slightest idea what an MTA is, why they would want one, or how to install/configure one. ISP/ESP hosted email is prevalent only partially to do with technical reasons and a lot to do with technical apathy on the part of the user base at large. Web hosting is the same way. A dedicated mailbox appliance would be another cost to the user that they would not understand why they need, and thus would not want. In a hypothetical tech-utopia, where everyone was fluent in bash (or powershell, take your pick), and read RFCs over breakfast instead of the newspaper, this would be an excellent solution. Meanwhile, in reality, technology frightens most people, and they are more than happy to pay someone else to deal with it for them. B: The relevant technical reason can be summarized as "good luck getting a residential internet connection with a static IP" (If your response includes the words "dynamic DNS" then please see point A) (Also I'm just going to briefly touch the fact that this doesn't address spam as a problem at all, and in fact would make that problem overwhelmingly worse, as MTAs would be expected to accept mail from everywhere, and we obviously can't trust end user devices or ISP CPE to be secure against intrusion) Scott Buettner Front Range Internet Inc NOC Engineer On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote: > Maybe you should focus on delivering email instead of refusing it. Or just keep refusing it and trying to bill people for it, until you make yourself irrelevant. The ISP based email made more sense when most end users - the people that we serve - didn't have persistent internet connections. Today, most users are always connected, and can receive email directly to our own computers, without a middle man. With IPv6 it's totally feasible since unique addressing is no longer a problem - there's no reason why every user can't have their own MTA. The problem is that there are many people who are making money off of email - whether it's the sending of mail or the blocking of it - and so they're very interested in breaking direct email to get 'the users' to rely on them. It should be entirely possible to build 'webmail' into home user CPEs or dedicated mailbox appliances, and let everyone deal with their own email delivery. The idea of having to pay other people to host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering the same ground. It boils down to: we have an old crappy system that works, and we don't want to change, because we've come to rely on the flaws of it and don't want them fixed. In the email case, people have figured out how to make money doing it, so they certainly want to keep their control over it. > > -Laszlo > > > On Mar 26, 2014, at 2:07 PM, Lamar Owen wrote: > >> On 03/25/2014 10:51 PM, Jimmy Hess wrote: >>> [snip] >>> >>> I would suggest the formation of an "IPv6 SMTP Server operator's club," >>> with a system for enrolling certain IP address source ranges as "Active >>> mail servers", active IP addresses and SMTP domain names under the >>> authority of a member. >>> >> ... >> >> As has been mentioned, this is old hat. >> >> There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. >> >> That way? Make e-mail cost; have e-postage. No, I don't want it either. But where is the pain point for spam where this becomes less painful? If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots. This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it. That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one. If spam ceases to be profitable, it will stop. >> >> Of course, I reserve the right to be wrong, and this might all just be a pipe dream. (and yes, I've thought about what sort of billing infrastructure nightmare this could be.....) >> > From hasservalve at gmail.com Wed Mar 26 16:08:28 2014 From: hasservalve at gmail.com (hasser css) Date: Wed, 26 Mar 2014 12:08:28 -0400 Subject: Link Layer Filtering not supported on popular equipment? Message-ID: Is there any common equipment that doesn't support this kind of filtering? I have no access to the switches where I work (I am just a CS agent at a smaller service provider), but my boss tells me that they do not support doing this... however, I do not believe this at all. I think that all the switches are all from Dell. Issues are happening as some customers accidentally have rogue DHCP servers running from their routers being connected improperly, and his only solution to this issue is to disable the switch port instead of simply preemptively filtering out this. Any insight? Regards. From esmithstubbs at gmail.com Wed Mar 26 22:39:23 2014 From: esmithstubbs at gmail.com (Edison Smith-Stubbs) Date: Thu, 27 Mar 2014 08:39:23 +1000 Subject: Looking for 2M service in CA Message-ID: Hi all, Apologies if this is the incorrect forum for this request, first time posting to the group! I work for an ISP in Australia and we have a requirement to deliver a service to a client site in CA. I'm not familiar with the American market but I'd be interested in chatting with providers who can deliver 2M tails between the following locations: A End: Washington Avenue, San Leandro CA B End: Equinix San Jose *OR *Coresite San Jose. Response off list to esmithstubbs at gmail.com would be appreciated. Thanks in advance! Ed From alex at howells.me Thu Mar 27 04:41:39 2014 From: alex at howells.me (Alex Howells) Date: Thu, 27 Mar 2014 04:41:39 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> Message-ID: Pay someone to worry about all this stuff, MaxWiFi has a good reputation in the UK at least. Stuff like the Ubiquiti Networks AirFiber can be good for getting from A-B over "relatively short" distances if you've identified another place which has really good connectivity which you can use, and if good connectivity is truly critical to the events. Obviously this involves masts, may involve permitting, and is a bit more complex than just a DSL line. It's usually possible to bond multiple DSL connections, and it's not impossible to get phone lines and DSL installed for short events either, although it does depend on the venue being willing to accommodate you. According to SamKnows the South Queensferry exchange (Dundas Castle) is supposed to have gotten BT FTTC capability from 1st March and some LLU (O2, TalkTalk, Sky) has happened, so again, talk to someone who specialises in this stuff and they'll be able to navigate "What is the least fucked up way to solve this for the event?". HTH, -Alex From alex at howells.me Thu Mar 27 05:22:40 2014 From: alex at howells.me (Alex Howells) Date: Thu, 27 Mar 2014 05:22:40 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> Message-ID: On 27 March 2014 05:09, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > I think the real problem here is the event is for 2 days and he requires > a metric shxt ton of data (for wireless anyways..). Sure you could get all > kinds of COOL solutions together, but do you think the (UK Version) LEC is > going to run DSL/fiber/blah for a two day event? And who bears that cost > burden? > Yes. Absolutely. Getting a phone line or multiple installed for 2 days is *completely* feasible, and depending on the length to the cabinet/exchange, the speeds he wants are also not too difficult (~20Mbps) through bonding. Both of the locations he has identified probably already have a significant number of copper pairs into the building. There are more than likely to be enough spare although the install process could be complicated if that is not the case. Typically speaking a line install costs from BT Openreach costs around ?50+VAT, but you'd pay ?145+VAT to get an expedited install appointment. In *theory* (never tried this myself) they should be able to install multiple lines within the same appointment, so four lines might run you ?345+VAT or thereabouts although worst case you could be looking at ?195+VAT per line. I believe it's possible to just cancel them immediately after the event, and that it's possible to avoid a 12 month minimum term, so you'd be looking at fairly minimal rental costs (?12+VAT per line, or thereabouts) to cover their rental for the 30 days covering your event. I am not trivialising the use of AirFiber in the slightest, however, if that's what it takes to get him the required bandwidth it's also not out of the realm of possibility for someone (i.e. doing it through MaxWiFi) to set up, for the required amount of money. I specifically stated it would be more complex than a DSL line. I think the OP was looking for solutions, not pages of text about how difficult or impossible his situation actually is ;-) From alex at howells.me Thu Mar 27 10:30:13 2014 From: alex at howells.me (Alex Howells) Date: Thu, 27 Mar 2014 10:30:13 +0000 Subject: WISP or other options In-Reply-To: <20140327101025.GL2267@mavrino.styx.org> References: <53339B53.9040700@wiredmedium.com> <5333A2D6.5010302@meetinghouse.net> <20140327101025.GL2267@mavrino.styx.org> Message-ID: I think the AF5 should be legal over here, at least, the lower bands are license free up to 1W transmit power. Not used the AF5 at all yet, it's quite new, and the only AF24 experience I have is only ~1000m worth of distance so comparatively easy to make work. Either way you latched onto the point, which is "Where there's a will, there's a way". In a lot of ways the UK is significantly more forward-thinking in terms of what can be done with DSL lines, the US LECs really aren't very imaginative. Who ever thought I'd be praising BT. On 27 March 2014 10:10, William Waites wrote: > On Thu, Mar 27, 2014 at 05:09:05AM +0000, Warren Bailey wrote: > > It's not 802.11 and it doesn't act that way. > > Actually most of the installations I've seen -- and my day job is > working with community networks around Scotland that have built all > manner of strange things -- the problems most often have nothing at > all to do with the physical layer. More often they're related to doing > things with spanning tree that we all learned in networking long ago > to not do, or running many layers of NAT because IP routing is not > understood. Things like that. > > The only common RF problem is leaving the channel selection on > "auto". Which invariably means one radio, like an access point with a > sector antenna, can't hear the point to point link coming in to the > dish behind it and picks the wrong channel. > > Again, yes, you're right, you have to understand how this stuff works > and think a little bit when you build, but your messages saying "It's > really really hard" are coming across a little like FUD. > > > A pair of Air Fiber is like 3k USD, and at 24ghz you had better know > > The AF24 are also illegal here. Or rather the lower channel belongs to > the police, and the upper channel is limited to a very low output > power. We have a pair of these, with a special non-operational license > from Ofcom to put them through their paces. They do work, though they > are a pain to align and subject to rain fade. They are on the West > coast which is very rainy. Right now we're using them to measure rain > intensity rather than to carry real traffic (which we can't do with a > non-op license anyways). > > -w > > > From dot at dotat.at Thu Mar 27 13:56:52 2014 From: dot at dotat.at (Tony Finch) Date: Thu, 27 Mar 2014 13:56:52 +0000 Subject: IPv6 isn't SMTP In-Reply-To: <9F773913-3350-485E-9BE3-706B2AAE5CA5@delong.com> References: <4AA4280D-D6EF-4751-9E0F-45BD6D03F10D@consultant.com> <0FD0EB52-8543-4F9B-8A65-9781FFC946F0@linkedin.com> <5333970A.6070107@direcpath.com> <9F773913-3350-485E-9BE3-706B2AAE5CA5@delong.com> Message-ID: Owen DeLong wrote: > > Two errors, actually? As an RFC-821 address, it should be user@[IP]:port > in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). You have never been able to specify a port number in an email address. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet: East or northeast 4 or 5, occasionally 6 later. Moderate becoming rough in south. Thundery showers. Good, occasionally poor. From dustin at rseng.net Thu Mar 27 14:04:41 2014 From: dustin at rseng.net (Dustin Jurman) Date: Thu, 27 Mar 2014 14:04:41 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> Message-ID: There are plenty of Microwave products that produce that type of bandwidth and more, LOS and NLOS. I do not know if there is a WISPA counterpart in Scotland but you may want to reach out to WISPA to see if they know of an organization. You can also reach out to Cambium to see whom their partners are in the area. Dustin Jurman -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Wednesday, March 26, 2014 11:35 PM To: Nick; nanog at nanog.org Subject: Re: WISP or other options 20-60mbps is a tall order. I?d say cellular.. Maybe you can pair together a couple of 4g cradle points and do load balancing on them? You are screwed for LOS microwave, 60mbps on a microwave hope requires real life engineering to function correctly. Frequency coordination, towers, AGL requirements. If you?re looking for satellite, I can tell you for certain that a 60mbps circuit for a month would exceed 140k a month in your neck of the woods. That?s just to start off, it can get higher as the link budget dictates. Is there any reason you need THAT much? Have you thought about using compression stuff at all? Are these people paying for it? On 3/26/14, 8:30 PM, "Nick" wrote: >Hey, > >I have a weird off the wall question for a NA group. > >Does any have contacts in Edinburgh Scotland who can provide WISP >service at the Hopetoun House and Dundas Castle. I would like to have >20-60mpbs to for 2 days of services. > >Our company's event planner claims there are no good ISP options in the >area and wants us to go with satellite internet which is pricy and has >high latency. Its worth noting both locations have ~7mpbs DLS. > >I'm also open to other options. > > >Thanks, > >Nick Poulakos > From erey at ernw.de Thu Mar 27 14:04:41 2014 From: erey at ernw.de (Enno Rey) Date: Thu, 27 Mar 2014 15:04:41 +0100 Subject: IPv6 isn't SMTP In-Reply-To: References: <20140327020833.15253.qmail@joyce.lan> Message-ID: <20140327140441.GD73770@ernw.de> Hi, On Thu, Mar 27, 2014 at 01:52:27PM +0000, Tony Finch wrote: > John Levine wrote: > > > > There are also some odd things in the spec. For example, according to > > RFC 5321 this is not a syntactically valid e-mail address: > > > > mailbox@[IPv6:2001:12:34:56::78:ab:cd] > > You aren't allowed to use :: to abbreviate one zero hexadectet according > to RFC 5952. well, RFC 5952 _recommends_ against using that. Still, it's perfectly valid as of RFC 4291 and the approach can be found in quite large vendors' implementations, see http://labs.apnic.net/blabs/?p=309. RFC 5952 explicitly states: "all implementations must accept and be able to handle any legitimate RFC 4291 format." best Enno > > http://www.rfc-editor.org/errata_search.php?eid=2467 > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest. > Showers. Good, occasionally moderate. > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From johnl at iecc.com Thu Mar 27 14:17:35 2014 From: johnl at iecc.com (John R. Levine) Date: 27 Mar 2014 10:17:35 -0400 Subject: IPv6 isn't SMTP In-Reply-To: References: <20140327020833.15253.qmail@joyce.lan> Message-ID: >> mailbox@[IPv6:2001:12:34:56::78:ab:cd] > > You aren't allowed to use :: to abbreviate one zero hexadectet according > to RFC 5952. > > http://www.rfc-editor.org/errata_search.php?eid=2467 Oh, look at that. I wonder how many people realized that it made an incompatible change to RFC 4291 four years ago. I certainly didn't. I wonder what problem they thought they were solving. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From rdobbins at arbor.net Thu Mar 27 14:21:27 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 27 Mar 2014 14:21:27 +0000 Subject: Link Layer Filtering not supported on popular equipment? In-Reply-To: References: Message-ID: <0A4EA06C-9F70-4F47-B748-DDBB710B6849@arbor.net> On Mar 26, 2014, at 11:08 PM, hasser css wrote: > Any insight? I don't know about Dell switches, but Cisco switches have DHCP Snooping, IP Source Guard, PACLs, VACLs, and so forth at layer-2. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From lowen at pari.edu Thu Mar 27 14:23:10 2014 From: lowen at pari.edu (Lamar Owen) Date: Thu, 27 Mar 2014 10:23:10 -0400 Subject: IPv6 isn't SMTP In-Reply-To: References: <20140326041858.7576.qmail@joyce.lan> Message-ID: <5334344E.6070006@pari.edu> On 03/26/2014 08:12 PM, Jimmy Hess wrote: > As far as i'm concerned.... if you can force the spammer to use their own > IP range, that they can setup RDNS for, then you have practically won, > for all intents and purposes, as it makes blacklisting feasible, once > again! > > Spammers can jump through these hoops --- but spammers aren't going to > effectively scale up their spamming operation by using IP address ranges > they can setup RDNS on. > Tell that to the 100,000+ e-mails I blocked last week (and the several hundred that got through before I was able to get all the blocks entered into my ingress ACLs) from proper rDNS addresses where the addresses were hopping all over a /24, a /22, three /21's, four /20's, and six /19s in widely separated blocks. Every single address in those blocks eventually attempted to send e-mail, and every address had proper rDNS for the pseudorandom domain names, mostly in the .in TLD, but some others, too (the blocks were all over, with some registed through ARIN, some through RIPE, some through AfriNIC, and some through APNIC, with hosters in Europe, North and South America, Asia, and Africa.) Note that these passed full FCrDNS verification in postfix. They all had very similar characteristics, including an embedded image payload/ad and a couple of hundred kB of anti-Bayesian text, including the full text of Zilog's Z80 manual at one point. Of course, the other tens of thousands per day that get blocked for not having rDNS from residential bots make the case for leaving rDNS (and the FCrDNS variant) turned on, but it is not a cure-all. From johnl at iecc.com Thu Mar 27 14:32:42 2014 From: johnl at iecc.com (John R. Levine) Date: 27 Mar 2014 10:32:42 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140327092231.GH10032@besserwisser.org> References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> Message-ID: > Ergo, ad hominem. Please quit doing that. > As a side note I happen to run my own mail server without spam filters > -- it works for me. I might not be the norm, but then again, is there > really a norm? (A norm that transcends SMTP RFC reach, that is -- I know a lot of people who run a lot of mail systems, and let's just say you're so far out in the long tail we need a telescope to see you. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From list at mass-distortion.net Thu Mar 27 15:02:17 2014 From: list at mass-distortion.net (cbr) Date: Thu, 27 Mar 2014 09:02:17 -0600 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: For anyone who was subscribed to the old full-disclosure list ... Fydor of nmap has brought it back to life. Infolink @ http://insecure.org/news/fulldisclosure/ Subscribe @ http://nmap.org/mailman/listinfo/fulldisclosure On Mar 26, 2014, at 10:52 AM, kendrick eastes wrote: > The Full-disclosure mailing list was recently... retired, I guess cisco > thought NANOG was the next best place. > > > On Wed, Mar 26, 2014 at 10:45 AM, rwebb at ropeguru.com wrote: > >> >> Is this normal for the list to diretly get Cisco security advisories or >> something new. First time I have seen these. >> >> Robert >> >> >> On Wed, 26 Mar 2014 12:10:00 -0400 >> Cisco Systems Product Security Incident Response Team >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Cisco IOS Software SSL VPN Denial of Service Vulnerability >>> >>> Advisory ID: cisco-sa-20140326-ios-sslvpn >>> >>> Revision 1.0 >>> >>> For Public Release 2014 March 26 16:00 UTC (GMT) >>> >>> Summary >>> ======= >>> >>> A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco >>> IOS Software could allow an unauthenticated, remote attacker to cause a >>> denial of service (DoS) condition. >>> >>> The vulnerability is due to a failure to process certain types of HTTP >>> requests. To exploit the vulnerability, an attacker could submit crafted >>> requests designed to consume memory to an affected device. An exploit could >>> allow the attacker to consume and fragment memory on the affected device. >>> This may cause reduced performance, a failure of certain processes, or a >>> restart of the affected device. >>> >>> Cisco has released free software updates that address this vulnerability. >>> There are no workarounds to mitigate this vulnerability. >>> >>> This advisory is available at the following link: >>> http://tools.cisco.com/security/center/content/ >>> CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn >>> >>> Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled >>> publication includes six Cisco Security Advisories. All advisories address >>> vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security >>> Advisory lists the Cisco IOS Software releases that correct the >>> vulnerability or vulnerabilities detailed in the advisory as well as the >>> Cisco IOS Software releases that correct all Cisco IOS Software >>> vulnerabilities in the March 2014 bundled publication. >>> >>> Individual publication links are in Cisco Event Response: Semiannual >>> Cisco IOS Software Security Advisory Bundled Publication at the following >>> link: >>> >>> http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>> >>> iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ >>> mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i >>> uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc >>> X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd >>> atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn >>> dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo >>> RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 >>> 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ >>> 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd >>> EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB >>> ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 >>> RF3x0wYuErbbC7N9m1UH >>> =1Ixo >>> -----END PGP SIGNATURE----- >>> >>> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jimpop at gmail.com Thu Mar 27 15:15:05 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 27 Mar 2014 11:15:05 -0400 Subject: [mailop] IPv6 DNSBL In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75AE91A642@SBS1.blinker.local> References: <20140326234210.14730.qmail@joyce.lan> <53336B85.5040004@linuxmagic.com> <78C35D6C1A82D243B830523B4193CF5F75AE91A5B0@SBS1.blinker.local> <7A34FFDC-C548-4AF1-89B0-B64270410D41@delong.com> <78C35D6C1A82D243B830523B4193CF5F75AE91A642@SBS1.blinker.local> Message-ID: On Thu, Mar 27, 2014 at 9:21 AM, David Hofstee wrote: > There must be a good reason for people to get of their asses and start implementing things like DMARC. All the banks (!$%^) I talk to do not have any reason to implement it swiftly (they turn on p=none and then all progress stops). Frustrating that they are too lazy to implement a few DNS records. > > It only needs firm backing by 3+ large companies like Hotmail. Give everyone on IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). Give me ammunition and all corporates will move. > Please no. DMARC is great for 1:1 direct email (from:me, to:you). Anything other than p=none fails miserably once the scope is expanded. Let me give you examples of things that would fail miserably under your suggestion above: 1) This list 2) The recent, heavily forwarded and reflected, Cisco PSIRT notices. NANOG is not the place to debate this, nor is it the place to advocate self inflicted harm. -Jim P. From johnl at iecc.com Thu Mar 27 15:30:09 2014 From: johnl at iecc.com (John Levine) Date: 27 Mar 2014 15:30:09 -0000 Subject: WKBIs, was why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Message-ID: <20140327153009.20389.qmail@joyce.lan> >Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has >previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, >then your postage is put into the recipients e-postage account to offset the cost of their emails. > >Thoughts? You could have bought the patent on this WKBI on eBay last year: http://www.ebay.com/itm/251279133681 When I was running the ASRG, I set up a wiki where we could keep a taxonomy of anti-spam techniques, so we could save time and just point people at it when they reinvent them. It's still there, contributions of anything we've missed are still welcome: http://wiki.asrg.sp.am/wiki/Attention_bonds R's, John PS: Well Known Bad Idea From rwebb at ropeguru.com Thu Mar 27 15:49:22 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Thu, 27 Mar 2014 11:49:22 -0400 Subject: No subject Message-ID: <4tnbh3ls91b0iw11ks7wawj9.1395935362235@email.android.com> So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. All TX and RX counters look normal except on the TX side, I am showing?1107597?input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert Sent from my Verizon Wireless 4G LTE smartphone From rwebb at ropeguru.com Thu Mar 27 15:55:48 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Thu, 27 Mar 2014 11:55:48 -0400 Subject: Switchport Counters Message-ID: Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: rwebb at ropeguru.com Date:03/27/2014 11:52 AM (GMT-05:00) To: nanog at nanog.org Subject: From james at talkunafraid.co.uk Thu Mar 27 16:03:54 2014 From: james at talkunafraid.co.uk (James Harrison) Date: Thu, 27 Mar 2014 16:03:54 +0000 Subject: WISP or other options In-Reply-To: References: <53339B53.9040700@wiredmedium.com> Message-ID: <53344BEA.9020404@talkunafraid.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/03/14 14:04, Dustin Jurman wrote: > There are plenty of Microwave products that produce that type of > bandwidth and more, LOS and NLOS. I do not know if there is a > WISPA counterpart in Scotland but you may want to reach out to > WISPA to see if they know of an organization. You can also reach > out to Cambium to see whom their partners are in the area. Indeed - there's fairly local transit capacity (though it is via a BT exchange, so good luck actually getting a reasonable price off BTWC for a temporary line) and doing LOS on some temporary towers should be within the capabilities of some creative engineers. WISPA might be a good starting point, INCA can certainly put you in touch with the local crowd to advise. Either way it'd certainly work out a heck of a lot cheaper than sat. You can do 3G (DC-HSDPA) in that area on at least one MNO but probably want a decent directional antenna with some gain on it. That'd probably work out cheapest, but will be bandwidth limited and you'd be looking at a fair few devices bonded to get that much bandwidth. - -- Cheers, James -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTNEvqAAoJENTyYHL8dmp9StIP/RnilFJ1SzfEqsQ5dkxMO+Hg jc7b4q41h7sNiWoWjRPbjc/nRsG0JNHIK/JicfuOKVzlrCIBdhO30B+EnR2DhZ+i roc09WwbJckwoGwTZjvXESm1qJE1bZTynr7nrrc7WFXak6HDN3MZqhHlkElShYAg i7Al5m5LjUFXKr+xorOam84w/DcmgFCi5SzAQOu5fTvQxbJ1gmiwb+n7q5V6xzRH /B+bRFBwaqW6mtTQ2Wh9lxxXaMoIRHWfo/AlI21Z8FyKANArypqBC3YNw0BSkeBP kN3dRy6AlbmhFQ3XaiOrYiHbx/vp4WV3VVe6S8/Suey2eKASmyglB3nfeCYvokOk kvMs4phfE8lTAntMm0HKykHtZHtPbUdwTOag4TyYCjlBtLZahBDqF9Q6TFwuhhxL e1Vi86PEpPgMGAGlim81DCHu9/BwWsvnp2R98/hAW5bMTanm6sBcAera0EYrAtKr MXYN5WOmAZzVxW/x1nbtxYBM8iNG2fY/w0lGDH+2Z7DgJxP/WQOVUhU3UCJcQYgi jkx9BSjBJJtyR6F/WKxKbDhIaTfZ58Y7qNqXpg27z1KuCxkz9HdpjYH2kuMO5icx Hq29kD4cJm5APCcBjyP8mlIyHG2GZqeNmJLaSfmCWYwhuf/XOKQQbgtOdfMLsoyS z3OJ0iuivtdirXz7RAoR =eyO1 -----END PGP SIGNATURE----- From sthaug at nethelp.no Thu Mar 27 16:10:06 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 27 Mar 2014 17:10:06 +0100 (CET) Subject: IPv6 Security In-Reply-To: <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com> References: <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> <20140327.085206.74744053.sthaug@nethelp.no> <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com> Message-ID: <20140327.171006.74728017.sthaug@nethelp.no> > > DHCPv6 as defined in RFC 3315 does not offer client MAC address at all > > (thus making the job more difficult for a number of organizations). > > Yes it does? > > What do you think ?Link Layer Address? (RFC 3315, Section 9.1 Type 3) > is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what > this is intended to be. True, it includes an additional 16 bits of > > media type, - I cannot a priori know which DUID type a particular client will use. Of the three DUID types in RFC 3315 section 9.1, type 1 and 3 include link layer address while type 2 does not. - As has already been pointed out, the same physical hardware may use different DUID types when booted with different operating systems. - The language in RFC 3315 is pretty explicit in saying that a server *must* treat the DUID as an opaque value - in other words, you are not allowed to "inspect" it in any way to find the presumed MAC address and take any action based on the MAC address. > > All I've seen so far indicates that this was a deliberate choice by > > the DHCPv6 designers, and in my opinion a very poor one. Fortunately > > we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and > > we're waiting for vendors to implement this. That solves one half of > > the problem. > > Yes and no. > > At the time RFC3315 was written, network cards changed independent of > motherboards on a regular basis and this fact was a source of great > consternation for DHCPv4 operators. Over time, that changed AFTER > RFC3315 was written, but if you read section 9.4, it seems pretty clear that > this change was anticipated by the authors and that DUID-LL was intended > for the situation we have today. I think understand the well-meant intentions of the RFC 3315 authors. However, my claim is that the actual end result for IPv6 leaves us in a *worse* situation than for IPv4. And one which, among others, makes it very difficult to correlate IPv4 and IPv6 leases (something which I have no need for today, but which I could easily see a need for in the future). Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mloftis at wgops.com Thu Mar 27 16:42:12 2014 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 27 Mar 2014 09:42:12 -0700 Subject: Link Layer Filtering not supported on popular equipment? In-Reply-To: References: Message-ID: On Wed, Mar 26, 2014 at 9:08 AM, hasser css wrote: > Is there any common equipment that doesn't support this kind of filtering? > I have no access to the switches where I work (I am just a CS agent at a > smaller service provider), but my boss tells me that they do not support > doing this... however, I do not believe this at all. I think that all the > switches are all from Dell. Issues are happening as some customers > accidentally have rogue DHCP servers running from their routers being > connected improperly, and his only solution to this issue is to disable the > switch port instead of simply preemptively filtering out this. > > Any insight? Regards. The supported options vary within the PowerConnect product line. So it depends entirely on WHAT exact switch. Some do support DHCP snooping like that, some don't. Even with it on it can create it's own problems, on the 6248 f/ex this causes the DHCP replies from trusted ports to always get copied to the CPU so it can inspect them and create it's VLAN+MAC+IP bindings databases. All untrusted port DHCP traffic gets punted to CPU. The gist is that this can open up a potential DoS attack on the switch, or, even without that, the DHCP traffic might be too high for the switch to manage. Similar issues with ACLs. There are some options in Cisco (not certain if any of dell's products have this) that basically keep ports from talking to eachother, but allow them to talk to the upstream port (usually a router that can then enforce deeper ACLs and such). All of these additional protection/security methods can have their drawbacks for any particular environment, assuming the hardware even supports them. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From rwebb at ropeguru.com Thu Mar 27 16:51:40 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Thu, 27 Mar 2014 12:51:40 -0400 Subject: Switchport Counters - Take two Message-ID: Apologies to everyone for the original email with no subject. I am having some senior email moments today. Anyway.... So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. All TX and RX counters look normal except on the TX side, I am showing 1107597 input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert From ler762 at gmail.com Thu Mar 27 16:55:46 2014 From: ler762 at gmail.com (Lee) Date: Thu, 27 Mar 2014 12:55:46 -0400 Subject: In-Reply-To: <4tnbh3ls91b0iw11ks7wawj9.1395935362235@email.android.com> References: <4tnbh3ls91b0iw11ks7wawj9.1395935362235@email.android.com> Message-ID: On 3/27/14, rwebb at ropeguru.com wrote: > So I certainly admit I am a basic networking guy and in the past have not > had to get into the nitty gritty of port statistics. > > I am trying to understand some statistics off a switch port in a Nexus > 4001i. Good luck. I couldn't find anything for a nexus 4000, but did find this for IOS: In-Discard - The result of inbound valid frames that were discarded because the frame did not need to be switched. This can be normal if a hub is connected to a port and two devices on that hub exchange data. The switch port still sees the data but does not have to switch it (since the CAM table shows the MAC address of both devices associated with the same port), and so it is discarded. This counter can also increment on a port configured as a trunk if that trunk blocks for some VLANs, or on a port that is the only member of a VLAN. so if you've got something like switch a: switchport trunk allowed vlan 1-5 switch b: switchport trunk allowed vlan 1-4 when switch a sends a frame on vlan 5, switch b counts it as an input discard. Lee > > All TX and RX counters look normal except on the TX side, I am > showing 1107597 input discards. Last clearing of show counters is 1d8h ago. > > I have it in my mind that this particular counter is dropping packets coming > in from another port inside the switch that are to be transmitted out to the > end server. > > So lets say the interface I am looking at is port 2 on the switch. So server > 1 sends a packet to port 1 on the switch. That packet then traverses to > backplane, or inside the same ASIC, to port 2 on the switch. It is then > dropped and not transmitted out to server 2. > > Is the scenario I just presented correct? Not looking for the reason in this > email, just that my logical understanding is correct. > > Robert > > > Sent from my Verizon Wireless 4G LTE smartphone From rwebb at ropeguru.com Thu Mar 27 17:04:28 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Thu, 27 Mar 2014 13:04:28 -0400 Subject: In-Reply-To: References: <4tnbh3ls91b0iw11ks7wawj9.1395935362235@email.android.com> Message-ID: It is actually a 4001i for an IBM Blade Chassis. Sorry for that. So in this setup, port a would be a trunk with multiple vlans connection back to a 6509. port b would be a switch port in access mode that connects to an IBM blade in the chassis. Not sure that this situation fits either of those scenarios. Overall problem is that we are seeing performance issues between servers. These servers are all AIX based. We believe/know that we have some misconfigurations in the environment with jumbo frames and flow control. My curiosity about the discards is due to those misconfigurations. The port I mentioned in my original email has around 480 million output packes to the 1.1 million discards. We do have IBM and Cisco support engaged, I am just trying to make sure I understand enough to be dangerous when I am working with them. Robert On Thu, 27 Mar 2014 12:55:46 -0400 Lee wrote: > On 3/27/14, rwebb at ropeguru.com wrote: >> So I certainly admit I am a basic networking guy and in the past >>have not >> had to get into the nitty gritty of port statistics. >> >> I am trying to understand some statistics off a switch port in a >>Nexus >> 4001i. > > Good luck. I couldn't find anything for a nexus 4000, but did find > this for IOS: > In-Discard - The result of inbound valid frames that were discarded > because the frame did not need to be switched. This can be normal if >a > hub is connected to a port and two devices on that hub exchange >data. > The switch port still sees the data but does not have to switch it > (since the CAM table shows the MAC address of both devices >associated > with the same port), and so it is discarded. This counter can also > increment on a port configured as a trunk if that trunk blocks for > some VLANs, or on a port that is the only member of a VLAN. > > so if you've got something like > switch a: switchport trunk allowed vlan 1-5 > switch b: switchport trunk allowed vlan 1-4 > > when switch a sends a frame on vlan 5, switch b counts it as an >input discard. > > Lee > >> >> All TX and RX counters look normal except on the TX side, I am >> showing 1107597 input discards. Last clearing of show counters is >>1d8h ago. >> >> I have it in my mind that this particular counter is dropping >>packets coming >> in from another port inside the switch that are to be transmitted >>out to the >> end server. >> >> So lets say the interface I am looking at is port 2 on the switch. >>So server >> 1 sends a packet to port 1 on the switch. That packet then traverses >>to >> backplane, or inside the same ASIC, to port 2 on the switch. It is >>then >> dropped and not transmitted out to server 2. >> >> Is the scenario I just presented correct? Not looking for the reason >>in this >> email, just that my logical understanding is correct. >> >> Robert >> >> >> Sent from my Verizon Wireless 4G LTE smartphone From lsc at prgmr.com Thu Mar 27 17:19:13 2014 From: lsc at prgmr.com (Luke S. Crawford) Date: Thu, 27 Mar 2014 10:19:13 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> <53336205.2010206@prgmr.com> Message-ID: <53345D91.6010301@prgmr.com> On 03/26/2014 11:14 PM, Owen DeLong wrote: > Why not just use private VLAN layer 2 controls for the privacy you describe? The technology I know of is what cisco calls 'protected ports' - My understanding is that those simply mean you can't pass traffic to or from other 'protected ports' - I use that capability when, say, putting a bunch of IPMIs on a private network, it works great, as if one of the IPMI ports is trying to talk to another, something is very wrong and it gets blocked. They are commonly used in the dedicated server hosting world to do what you are describing, but they have a big downside when being used on the public side; customer 1 can't talk to customer 2. Now, this isn't usually a big deal, except in one very common case; what if one entity buys two hosts? now those two hosts can't talk to oneanother. This is a very common problem for dedicated hosting providers (and why I give my dedicated hosts a vlan and a routed subnet, wasting IPv4.) For my virtuals, though, I have a much more clever "switch" as it's just some software running in the Dom0, so at least in the IPv4 world, filtering just their /32 in and out is a much better solution. > Yes, you risk customer A spoofing customer B, but is that really a problem in your environment? Really? If so, one could argue you might want to consider getting a better class of customers. You wouldn't feel uncomfortable if some other company could come in and not only spoof your IP, but receive the return traffic? Keep in mind that they could do this in a way that is quite difficult to detect or trace, if they were clever about it. I may trust my provider, to a certain extent, but I certainly don't trust everyone who gives my provider money. From lsc at prgmr.com Thu Mar 27 17:25:34 2014 From: lsc at prgmr.com (Luke S. Crawford) Date: Thu, 27 Mar 2014 10:25:34 -0700 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <836694A3-D37D-495C-83DC-AEDD045E1FC4@delong.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <836694A3-D37D-495C-83DC-AEDD045E1FC4@delong.com> Message-ID: <53345F0E.8020204@prgmr.com> >> It might make sense to just give everyone their own vlan and their own /64; that would, of course, bring its own problems and complexities (namely that I've gotta have the capability to deal with more customers than I can have native vlans - not impossible to get around, but significant added complexity.) > > I don?t see the point of that. why not? After carefully considering everything you have told me, this sounds like the way forward to do it the "IPv6 way" - privacy IPs would work fine, and I could filter every port such that only packets from that /64 were allowed out and only addresses to that /64 would be allowed in. Nobody would be able to spoof or listen in on their neighbor; yeah, my router would have to send a lot of RAs, but routers that handle the amount of traffic my customers send are cheap. I have a lot of customers, sure, but they are small. Sure, it's going to cost me in routing complexity, but it looks like the only thing I can do that will actually solve my problems and use IPv6 the way IPv6 is expecting to be used. I'd then have to figure out how to make their ipv4 /32 work, but I can think of several possibilities that might work. If nothing else, I could give them one interface for IPv6 and one for IPv4, and leave the IPv4 interface the current system. From bzs at world.std.com Thu Mar 27 17:47:49 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 27 Mar 2014 13:47:49 -0400 Subject: misunderstanding scale In-Reply-To: <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> References: <20140323051037.94159.qmail@joyce.lan> <201403232113.15291.mark.tinka@seacom.mu> <532F3783.4080502@ledeuns.net> <201403240838.27974.mark.tinka@seacom.mu> <74E5BAED-BB1C-438B-80AC-26549616C792@delong.com> <9578293AE169674F9A048B2BC9A081B4B5422604@MUNPRDMBXA1.medline.com> <17c4fe20bcf74f80b749d234c9c2df6b@BN1PR04MB250.namprd04.prod.outlook.com> <9578293AE169674F9A048B2BC9A081B4B5422952@MUNPRDMBXA1.medline.com> <4CEDA137-F651-4532-8FFB-AEF84742889C@delong.com> <90E6F06C-88A0-4A5F-A98D-5A27CFD6692C@delong.com> Message-ID: <21300.25669.640095.985328@world.std.com> On March 26, 2014 at 22:17 owen at delong.com (Owen DeLong) wrote: > > Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. Hang on, do spammers "grab" address blocks? Ok, I'm sure it happens, this is not an existence proof. But is that really a significant characterization of their behavior? That they go to an RIR or ISP and get an address block allocation? I mean post-Ralsky (almost obscure historical spam reference.) It seems like ALL the spam I see is purloined resources: botnets, unauthorized use of (usually misconfigured) mail servers, web software holes, free sites in general (such as google groups but also those "community" free sites), etc. I suppose this is the place where someone just says: "Yes, Barry, it is" and considers the matter settled but it sure doesn't match my experience. We block a lot of /24s (like about 150,000 right now) and even a few larger chunks but not because they're owned by spammers but because they're repeatedly ABUSED by spammers. But unfortunately they're just about always owned by people/companies who believe they're legitimate but just can't seem to keep the spammers from abusing them over and over. And the chance of ham from them is so slight that one just blocks them wholesale. Well, maybe for the purpose of this discussion it's the same thing, how do you block blocks which are being abused or you want to block for whatever reason. -- -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 rspott at irongoat.net Thu Mar 27 17:57:13 2014 From: rspott at irongoat.net (D. Ryan Spott) Date: Thu, 27 Mar 2014 10:57:13 -0700 Subject: Former 360/Ledcor employees from the NW Message-ID: <53346679.4040107@irongoat.net> I am looking for some fiber in the PNW coastal area and for that field tech that knows where all the skeletons and vaults might be buried. I know Ledcor installed it, 360-networks bought it and then Zayo now owns it but cannot find it on their maps. ryan From jbates at brightok.net Thu Mar 27 18:14:30 2014 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Mar 2014 13:14:30 -0500 Subject: IPv6 Security [Was: Re: misunderstanding scale] In-Reply-To: <53345D91.6010301@prgmr.com> References: <532DB095.9040801@ropeguru.com> <532DBA5E.9090800@dougbarton.us> <532DC580.8060901@foobar.org> <532E4E6A.6050701@dougbarton.us> <532F0834.9030401@foobar.org> <532F0B02.7090208@mykolab.com> <532F55F7.3010802@mykolab.com> <53331477.1070701@prgmr.com> <20140326224951.GH24282@hezmatt.org> <53336205.2010206@prgmr.com> <53345D91.6010301@prgmr.com> Message-ID: <53346A86.10804@brightok.net> On 3/27/2014 12:19 PM, Luke S. Crawford wrote: > > This is a very common problem for dedicated hosting providers (and why > I give my dedicated hosts a vlan and a routed subnet, wasting IPv4.) > Implement what some DSL access providers do. Unnumbered interfaces with /32 routing to the vlan. The last I checked, I think a J can even get the /32 route from radius when using autoconfig with radius auth. We did similar things with IPv6, as well. proxy-arp/proxy-nd to handle the cross talk. IOS 12.1 7206 confirmed. No autoconf, but static subinterfaces for each vlan (q-in-q supported or atm), unnumbered to loopback. DHCPv4 and static routing works. IPv6 had issues, but could handle static /64 per subint. ASR/J MX, autoconfig w/ radius backend, manual subint/unit, or combination. DHCPv4 confirmed, static host routes confirmed. IPv6 not confirmed. Radius static host route establishment not confirmed. Still testing. Jack From jmglass at iup.edu Thu Mar 27 17:06:03 2014 From: jmglass at iup.edu (Jim Glassford) Date: Thu, 27 Mar 2014 13:06:03 -0400 Subject: Switchport Counters - Take two In-Reply-To: References: Message-ID: <53345A7B.5000900@iup.edu> I have no experience with a Nexus 4001i, seems this could be counting up due to frames of no interest, wrong VLAN, Spanning tree, other. Not by chance on a IBM BladeCenter? The "input discard" counter on any internal interface (Ethernet1/1 - Ethernet1/14) may increment on Cisco Nexus 4001i switches, even when the connected blade is started into Unified Extensible Firmware Interface (UEFI) and not sending Operating System (OS) data. This has been observed with QLogic Dual-Port 10 GB Converged Network Adapter (CFFh) for IBM BladeCenter, Option part number 42C1830, but may occur with other Network Interface Controllers (NICs). Workaround: This is a reporting issue. The 'input discards' are not counting actual packet loss. Do not replace any hardware or update firmware. On 3/27/2014 12:51 PM, rwebb at ropeguru.com wrote: > Apologies to everyone for the original email with no subject. I am > having some senior email moments today. > > Anyway.... > > So I certainly admit I am a basic networking guy and in the past have > not had to get into the nitty gritty of port statistics. > > I am trying to understand some statistics off a switch port in a Nexus > 4001i. > > All TX and RX counters look normal except on the TX side, I am showing > 1107597 input discards. Last clearing of show counters is 1d8h ago. > > I have it in my mind that this particular counter is dropping packets > coming in from another port inside the switch that are to be > transmitted out to the end server. > > So lets say the interface I am looking at is port 2 on the switch. So > server 1 sends a packet to port 1 on the switch. That packet then > traverses to backplane, or inside the same ASIC, to port 2 on the > switch. It is then dropped and not transmitted out to server 2. > > Is the scenario I just presented correct? Not looking for the reason > in this email, just that my logical understanding is correct. > > Robert > From bzs at world.std.com Thu Mar 27 18:15:26 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 27 Mar 2014 14:15:26 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> Message-ID: <21300.27326.575281.57423@world.std.com> On March 26, 2014 at 22:25 owen at delong.com (Owen DeLong) wrote: > > Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. > > Thoughts? It's a fine idea but too complicated. Look, the (paper) post office doesn't say "oh, you WANTED that mail, ok, then we'll return the cost of postage to the sender!" Why? Because if they did that people would game the system, THEY'D SPAM! And it would take way too much bookkeeping and fraud identification etc. Let's take a deep breath and re-examine the assumptions: Full scale spammers send on the order of one billion msgs per day. Which means if I gave your account 1M free msgs/day and could reasonably assure that you can't set up 1,000 such accts then you could not operate as a spammer. Who can't operate with 1M msgs/day? Well, maybe Amazon or similar. But as I said earlier MAYBE THEY SHOULD PAY ALSO! We really need to get over the moral component of spam content (and senders' intentions) and see it for what it is: A free ride anyone would take if available. Ok, a million free per acct might be too high but whatever, we can all go into committee and do studies and determine what the right number should be. I'd tend towards some sort of sliding scale myself, 100K/day free, 1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like that. Why would it work? Because that's how human society works. People who are willing to pay their $10K/mo will demand something be done about freeloaders, enforcement has to be part of the cost overhead. And it'd create an economy for hunting down miscreants. There really is none now, outside of the higher profile DDoS or phishing sort of activities. I claim it wouldn't take much of this to shut down spammers. P.S. And in my vision accepting only email with valid e-postage would be voluntary though I suppose that might be "voluntary" at the provider level. For example someone like gmail at some point (of successful implementation of this scheme) might decide to just block invalid e-postage because hey your gmail acct is free! Let someone else sell you rules you prefer like controlling acceptance of invalid e-postage yourself. -- -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 laszlo at heliacal.net Thu Mar 27 18:21:11 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 27 Mar 2014 18:21:11 +0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5332EB04.9070409@frii.net> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <911CEC5C-2011-4C8D-9CC1-89DF2B4CB2C1@heliacal.net> <5332EB04.9070409@frii.net> Message-ID: Scott, You are exactly right, in the current environment the things I'm suggesting seem unrealistic. My point is that it doesn't have to work the way it does today, with the webmail providers, the mail originators and the spam warriors all scratching each others' backs. There has been a LOT of work done to make webmail easy and everything else practically impossible, even if you do know how it works. What if Google, Apple, Sony or some other household brand, sold a TV with local mail capabilities, instead of pushing everyone to use their hosted services? If it doesn't work because we are blocking it on purpose, customers would demand that we make it work. Since this isn't a well known option today, casual (non tech) users don't know that they should be demanding it. As far as why someone would want an MTA, it doesn't take long to explain the benefits of having control over your own email instead of having a third party reading it all. The problem is that instead users are told they can't have it. MTAs are built into every user operating system and they would work just fine if the email community wasn't going out of their way to exclude them. The lack of rDNS is just one of the many ways to identify and discriminate against end users who haven't bought their way into the club. Spam is not a big problem for everyone. It's at a different scale for individuals and for large sites with many users. -Laszlo On Mar 26, 2014, at 2:58 PM, Scott Buettner wrote: > This is totally ignoring a few facts. > > A: That the overwhelming majority of users don't have the slightest idea what an MTA is, why they would want one, or how to install/configure one. ISP/ESP hosted email is prevalent only partially to do with technical reasons and a lot to do with technical apathy on the part of the user base at large. Web hosting is the same way. A dedicated mailbox appliance would be another cost to the user that they would not understand why they need, and thus would not want. In a hypothetical tech-utopia, where everyone was fluent in bash (or powershell, take your pick), and read RFCs over breakfast instead of the newspaper, this would be an excellent solution. Meanwhile, in reality, technology frightens most people, and they are more than happy to pay someone else to deal with it for them. > > B: The relevant technical reason can be summarized as "good luck getting a residential internet connection with a static IP" > > (If your response includes the words "dynamic DNS" then please see point A) > > (Also I'm just going to briefly touch the fact that this doesn't address spam as a problem at all, and in fact would make that problem overwhelmingly worse, as MTAs would be expected to accept mail from everywhere, and we obviously can't trust end user devices or ISP CPE to be secure against intrusion) > > Scott Buettner > Front Range Internet Inc > NOC Engineer > > On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote: >> Maybe you should focus on delivering email instead of refusing it. Or just keep refusing it and trying to bill people for it, until you make yourself irrelevant. The ISP based email made more sense when most end users - the people that we serve - didn't have persistent internet connections. Today, most users are always connected, and can receive email directly to our own computers, without a middle man. With IPv6 it's totally feasible since unique addressing is no longer a problem - there's no reason why every user can't have their own MTA. The problem is that there are many people who are making money off of email - whether it's the sending of mail or the blocking of it - and so they're very interested in breaking direct email to get 'the users' to rely on them. It should be entirely possible to build 'webmail' into home user CPEs or dedicated mailbox appliances, and let everyone deal with their own email delivery. The idea of having to pay other people to host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering the same ground. It boils down to: we have an old crappy system that works, and we don't want to change, because we've come to rely on the flaws of it and don't want them fixed. In the email case, people have figured out how to make money doing it, so they certainly want to keep their control over it. >> >> -Laszlo >> >> >> On Mar 26, 2014, at 2:07 PM, Lamar Owen wrote: >> >>> On 03/25/2014 10:51 PM, Jimmy Hess wrote: >>>> [snip] >>>> >>>> I would suggest the formation of an "IPv6 SMTP Server operator's club," >>>> with a system for enrolling certain IP address source ranges as "Active >>>> mail servers", active IP addresses and SMTP domain names under the >>>> authority of a member. >>>> >>> ... >>> >>> As has been mentioned, this is old hat. >>> >>> There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. >>> >>> That way? Make e-mail cost; have e-postage. No, I don't want it either. But where is the pain point for spam where this becomes less painful? If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots. This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it. That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one. If spam ceases to be profitable, it will stop. >>> >>> Of course, I reserve the right to be wrong, and this might all just be a pipe dream. (and yes, I've thought about what sort of billing infrastructure nightmare this could be.....) >>> >> > > > From David.Siegel at Level3.com Thu Mar 27 18:58:43 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 27 Mar 2014 18:58:43 +0000 Subject: Education Committee Update Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC06A39422E@USIDCWVEMBX05.corp.global.level3.com> Hi folks, I would like to provide a brief update from the NANOG Education Committee. We have filled several of the open committee positions but are still looking for more volunteers. We need a Director of Instruction and several more "Members at Large." Please contact Betty or myself if you are interested in participating in the group. My thanks go out to those who have already volunteered, as follows: Vice-Chair: Steve Gibbard Program Director: Paul Emmons Technical Director: Brandon Ross Member at Large: Chris Spears Of course, we continue to receive support from Betty Burke, Executive Director and Valerie Wittkop for Project Management. On the instruction front, we have two classes getting lined up for the Bellevue NANOG. David Barak will be joining us again to teach our 3rd Routing Fundamentals class and we are finalizing contracts now for an IPv6 course. Registration will be open soon for both courses so stay tuned. Dave Siegel Chair, Ad-hoc Education Committee (NANOG) From bzs at world.std.com Thu Mar 27 19:06:15 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 27 Mar 2014 15:06:15 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <53342CF5.3090009@ispn.net> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> Message-ID: <21300.30375.863357.496730@world.std.com> On March 27, 2014 at 08:51 blake at ispn.net (Blake Hudson) wrote: > > > The primary issues I see with SMTP as a protocol related to the lack of > authentication and authorization. Take, for instance, the fact that the > SMTP protocol requires a mail from: and rcpt to: address (more or less > for authentication and authorization purposes), but then in the message > allows the sender to specify a completely different set of sender and > recipient information that gets displayed in the mail client. This is mostly a UI issue. The user interface could show anything, custom certainly has been as you describe: Show the message From: and make it tricky (for most people) to get the envelope info. Well, it's not mandatory that an MTA transmit the envelope info into the message headers and, almost worse, different MTAs seem to use different header fields for this. For example in SpamAssassin you are encouraged to set which field it should look at for the envelope sender. But that's not REALLY a problem with SMTP per se. Only in practice, if that's a useful distinction. I won't go point by point but I will say that SMTP has been extended several times -- just throw another verb into the mix to extend it. Which is a very useful observation. SMTP also can transmit which verbs are supported. One can extend a new idea and it's immediately interoperable. I suppose the obvious question is: What's to stop a spammer from putting a totally legitimate key into their spam? You also need some sort of reputation layer. Or maybe that makes it unworkable. I remember at the 2006 MIT Spam Conference where Eric Allman and I were keynotes we got into a bit of a tussle over exactly this during his question period. It was...amusing! -- -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 aaron at heyaaron.com Thu Mar 27 19:11:24 2014 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 27 Mar 2014 12:11:24 -0700 Subject: Remote Hands Spokane, WA? Message-ID: Anyone available for remote hands (installing memory) in Spokane, WA on a Thursday during business hours? -A From blake at ispn.net Thu Mar 27 19:16:48 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 27 Mar 2014 14:16:48 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <21300.30375.863357.496730@world.std.com> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> <21300.30375.863357.496730@world.std.com> Message-ID: <53347920.4000302@ispn.net> Barry Shein wrote the following on 3/27/2014 2:06 PM: > > > I suppose the obvious question is: What's to stop a spammer from > putting a totally legitimate key into their spam? > It's entirely likely that a spammer would try to get a hold of a key due to its value or that someone you've done business with would share keys with a "business" partner . But ideally you'd authorize each sender with a unique key (or some sort of pair/combination). So that 1) you can tell who the spammer sourced the key from and 2) you can revoke the compromised key's authorization to send you subsequent email messages. There's probably some way to generate authorization such that each sender gets a unique key or a generic base is in some way salted or combined with information from the individual you're giving your authorization to such that the result is both unique and identifiable. --Blake From owen at delong.com Thu Mar 27 19:14:23 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 12:14:23 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21300.27326.575281.57423@world.std.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> Message-ID: <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: > > On March 26, 2014 at 22:25 owen at delong.com (Owen DeLong) wrote: >> >> Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. >> >> Thoughts? > > It's a fine idea but too complicated. > > Look, the (paper) post office doesn't say "oh, you WANTED that mail, > ok, then we'll return the cost of postage to the sender!" > > Why? Because if they did that people would game the system, THEY'D > SPAM! How would they benefit from that? SPAM ? Pay, say $0.10/message. Then Claim you wanted the SPAM, get your $0.10/message back for each SPAM you sent to yourself. Or, claim you didn?t want the SPAM and get $0.05/message for each message you received while the original provider keeps the other $0.05. > And it would take way too much bookkeeping and fraud identification etc. Please explain in detail where the fraud potential comes in. By my interpretation, you?d have to somehow get more back than you deposited (not really possible) in order to profit from sending SPAM this way. > Let's take a deep breath and re-examine the assumptions: > > Full scale spammers send on the order of one billion msgs per day. > > Which means if I gave your account 1M free msgs/day and could > reasonably assure that you can't set up 1,000 such accts then you > could not operate as a spammer. Not sure how you enforce these user account requirements or how you avoid duplicative accounts. > Who can't operate with 1M msgs/day? > > Well, maybe Amazon or similar. > > But as I said earlier MAYBE THEY SHOULD PAY ALSO! I, for one, don?t want my Amazon prices increased by a pseudo-tax on the fact that they do a large volume of email communications with their customers. They have enough problems trying to get IPv6 deployed without adding this to their list of problems. > We really need to get over the moral component of spam content (and > senders' intentions) and see it for what it is: A free ride anyone > would take if available. I disagree. I see it as a form of theft of service that only immoral thieves would take if available. > Ok, a million free per acct might be too high but whatever, we can all > go into committee and do studies and determine what the right number > should be. > > I'd tend towards some sort of sliding scale myself, 100K/day free, > 1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like > that. > > Why would it work? > > Because that's how human society works. > > People who are willing to pay their $10K/mo will demand something be > done about freeloaders, enforcement has to be part of the cost > overhead. But who charges these fees and how do they enforce those charges against miscreants that are sending from stolen hosts, bots, fraudulent IP addresses, etc.? > And it'd create an economy for hunting down miscreants. So you?ve got a set of thieves who are stealing services to send vast volumes of email and you want to solve that problem by charging them more for those services that they are stealing (and, by the way, also charging some legitimate users as well). My guess is that the spammers are going to keep stealing and the people now being taxed for something that used to be free are going to object. > P.S. And in my vision accepting only email with valid e-postage would > be voluntary though I suppose that might be "voluntary" at the > provider level. For example someone like gmail at some point (of > successful implementation of this scheme) might decide to just block > invalid e-postage because hey your gmail acct is free! Let someone > else sell you rules you prefer like controlling acceptance of invalid > e-postage yourself. Well, here we get a hint at how you envision this working. There are lots of details that need to be solved in the implementation of such a scheme and I think the devil is prevalent among them. Owen From blake at ispn.net Thu Mar 27 19:36:14 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 27 Mar 2014 14:36:14 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <21299.43001.594066.309143@world.std.com> References: <53325892.2070801@cox.net> <21299.6913.50963.426979@world.std.com> <5333992F.6020300@dcrocker.net> <21299.43001.594066.309143@world.std.com> Message-ID: <53347DAE.7070802@ispn.net> Barry Shein wrote the following on 3/26/2014 11:24 PM: > > Some will blanche at this but the entire spam problem basically arose > from the crap security in Windows systems, particularly prior to maybe > XP/SP2. > > Not sure where all that leads us, however. Better security at those > major exploitation points, in a nutshell. > > And if someone disagrees then please tell me how spammers as we know > them (and related miscreants) can operate without these few sources of > purloined resources. > > Preferably without a big hand-wave like "oh they'll just find > something else!" > > Maybe not! > You're largely right. Botnets are a big source of spam. As a mail server operator, they're the biggest source that I see. They're also easy to block through a number of means (The ISPs they're located on often block port 25, PBL (or similar), rDNS, and other behavior). It sounds like it will likely be a similar matter of blocking residential botnet participants on IPv6 due to the fact that residential ISPs will likely apply similar port 25 policy to IPv6 as they do to IPv4 and no rDNS. However, as more attention is being payed to secure these end stations, spammers are looking at alternative avenues. In recent years, they've been harvesting user credentials through various means and then exploiting these compromised accounts to send email through otherwise legitimate servers. These are the spam messages that are hard to block. And these may be the areas where reputation based services will not be able to keep up in an IPv6 landscape. At least this concentrates the sources of spam (from my server's vantage point) and reduces the attack surface so that the problem is likely addressed more quickly and by someone with a higher level of knowledge than the average (unknowing) botnet participant. Unfortunately, I can't keep Suzie teenager or Joe grandpa from giving his or her password out to a phisher. Fortunately, I can place reasonable limits on their accounts and the number of messages they're allowed to send or the rate at which they're allowed to send messages. If everyone else would just do the same we'd be a lot better off against this kind of attack. --Blake From jhellenthal at dataix.net Thu Mar 27 20:08:57 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Thu, 27 Mar 2014 16:08:57 -0400 Subject: Remote Hands Spokane, WA? In-Reply-To: References: Message-ID: I know a guy that lives out that way if you'd like me to bring him in. -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Mar 27, 2014, at 15:11, "Aaron C. de Bruyn" wrote: > > Anyone available for remote hands (installing memory) in Spokane, WA on a > Thursday during business hours? > > -A -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From mark.tinka at seacom.mu Thu Mar 27 20:39:02 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Mar 2014 22:39:02 +0200 Subject: Link Layer Filtering not supported on popular equipment? In-Reply-To: References: Message-ID: <201403272239.02862.mark.tinka@seacom.mu> On Thursday, March 27, 2014 06:42:12 PM Michael Loftis wrote: > Similar issues with ACLs. There are some options in > Cisco (not certain if any of dell's products have this) > that basically keep ports from talking to eachother, but > allow them to talk to the upstream port (usually a > router that can then enforce deeper ACLs and such). Those would be private VLAN's in classic solutions, and split horizon bridge domains on carrier Ethernet platforms. I find the latter simpler and more elegant, but limited to specific hardware. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bross at pobox.com Thu Mar 27 20:38:53 2014 From: bross at pobox.com (Brandon Ross) Date: Thu, 27 Mar 2014 16:38:53 -0400 (EDT) Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> Message-ID: On Thu, 27 Mar 2014, Owen DeLong wrote: > On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: > > Please explain in detail where the fraud potential comes in. Spammer uses his botnet of zombie machines to send email from each of them to his own domain using the user's legitimate email address as From:. Spammer says it was unsolicited and keeps the full $.10/email that victim users have deposited into this escrow thing. Sounds a lot more profitable than regular spam. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From kauer at biplane.com.au Thu Mar 27 20:55:38 2014 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 28 Mar 2014 07:55:38 +1100 Subject: IPv6 Security In-Reply-To: <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com> References: <20140327005039.GB7867@angus.ind.WPI.EDU> <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> <20140327.085206.74744053.sthaug@nethelp.no> <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com> Message-ID: <1395953738.7560.28.camel@karl> On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote: > What do you think ?Link Layer Address? (RFC 3315, Section 9.1 Type 3) > is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what > this is intended to be. True, it includes an additional 16 bits of media type, > but I don?t see that as being a problem. Though to be fair 3315 also says that the DUID should be treated as an opaque blob, not parsed and bits extracted from it. From section 9: "Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs." Regarding section 9.4, which you refer to: 3315 only uses MACs to *construct* useful DUIDs, not as a means of communicating MACs to clients or servers. Also, an operator cannot RELY on getting a MAC address in a DUID. DUID's *are* different and *do* require new ways of doing things. People will work it out. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From mpalmer at hezmatt.org Thu Mar 27 21:07:47 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 28 Mar 2014 08:07:47 +1100 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: <20140327210747.GQ24282@hezmatt.org> On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote: > The Full-disclosure mailing list was recently... retired, I guess cisco > thought NANOG was the next best place. Nope, they've been sending these things here for as long as I can remember. I have NFI why -- probably hubris, thinking that everyone running a network *must* have some Cisco somewhere. - Matt From randy at psg.com Thu Mar 27 21:27:26 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Mar 2014 06:27:26 +0900 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. this is not about address policy, but arin thinks of itelf as a regulator not a registry. contrast with the ripe community and the ncc, which is not nirvana but is a hell of a lot better. among other key differences, the ncc is engaged with the community through technical and business working groups. e.g. the database working group covers what you think of as whois and the routing registry. the wg developed the darned irr definition and continues to evolve it. consequence? the irr is actively used in two regions in the world, europe and japan (which likes anything ocd:-). the routing wg works with the ops to develop routing technology such as route flap damping. there is a reason that serious ops attend ripe meetings. yes, a whole lot of folk with enable are engaged. for years there has been a wg on the global layer nine issues. the dns wg deals with reverse delegation, root server ops, etc. and guess what, all the dns heavy techs and ops are engaged. there is a wg for discussing what services the ncc offers. the recent simplification and opening of services to legacy and PI holders happened in the ncc services wg, it was about services not addressing policy. and this is aside from daniel's global measurement empire. not sure it is a registry's job to do this, but it is a serious contribution to the internet. the ncc is engaged with its community on the subhects that actually interest operators and affect our daily lives. there is nothing of interest at an arin meeting, a bunch of junior wannabe regulators and vigilantes making an embarrassing mess. i've even taken to skipping nanog, if ras talks i can watch the recording. all the cool kids will be in warsaw. ops vote with our feet. randy From jcurran at arin.net Thu Mar 27 21:56:01 2014 From: jcurran at arin.net (John Curran) Date: Thu, 27 Mar 2014 21:56:01 +0000 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: <0C3EA47A-D825-47DC-B7BA-604BE609C8AF@arin.net> > On Mar 28, 2014, at 5:27 AM, "Randy Bush" wrote: > > john, > > i think your attemt to move the discussion to the arin ppml list > exemplifies one core of the problem. Randy - I offered ppml out of respect to the nanog subscribers, that is all... /John > > > > and this is aside from daniel's global measurement empire. not sure it > is a registry's job to do this, but it is a serious contribution to the > internet. > > the ncc is engaged with its community on the subhects that actually > interest operators and affect our daily lives. > > there is nothing of interest at an arin meeting, a bunch of junior > wannabe regulators and vigilantes making an embarrassing mess. i've > even taken to skipping nanog, if ras talks i can watch the recording. > all the cool kids will be in warsaw. ops vote with our feet. > > ran From jcurran at istaff.org Thu Mar 27 22:01:08 2014 From: jcurran at istaff.org (John Curran) Date: Fri, 28 Mar 2014 06:01:08 +0800 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: And I would welcome discussion of how ARIN (and nanog) can be more like RIPE - that is very much up to this community and its participation far more than ARIN.. /John > On Mar 28, 2014, at 5:27 AM, Randy Bush wrote: > > john, > > i think your attemt to move the discussion to the arin ppml list > exemplifies one core of the problem. this is not about address policy, > but arin thinks of itelf as a regulator not a registry. > > contrast with the ripe community and the ncc, which is not nirvana but > is a hell of a lot better. among other key differences, the ncc is > engaged with the community through technical and business working > groups. > > e.g. the database working group covers what you think of as whois and > the routing registry. the wg developed the darned irr definition and > continues to evolve it. consequence? the irr is actively used in two > regions in the world, europe and japan (which likes anything ocd:-). > > the routing wg works with the ops to develop routing technology such as > route flap damping. there is a reason that serious ops attend ripe > meetings. yes, a whole lot of folk with enable are engaged. > > for years there has been a wg on the global layer nine issues. > > the dns wg deals with reverse delegation, root server ops, etc. and > guess what, all the dns heavy techs and ops are engaged. > > there is a wg for discussing what services the ncc offers. the recent > simplification and opening of services to legacy and PI holders happened > in the ncc services wg, it was about services not addressing policy. > > and this is aside from daniel's global measurement empire. not sure it > is a registry's job to do this, but it is a serious contribution to the > internet. > > the ncc is engaged with its community on the subhects that actually > interest operators and affect our daily lives. > > there is nothing of interest at an arin meeting, a bunch of junior > wannabe regulators and vigilantes making an embarrassing mess. i've > even taken to skipping nanog, if ras talks i can watch the recording. > all the cool kids will be in warsaw. ops vote with our feet. > > randy > From randy at psg.com Thu Mar 27 22:04:02 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Mar 2014 07:04:02 +0900 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: <0C3EA47A-D825-47DC-B7BA-604BE609C8AF@arin.net> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <0C3EA47A-D825-47DC-B7BA-604BE609C8AF@arin.net> Message-ID: hi john, >> i think your attemt to move the discussion to the arin ppml list >> exemplifies one core of the problem. > I offered ppml out of respect to the nanog subscribers, that is all... i will refrain from characterizing the ppml list. needless to say, i do not subscribe. my point is that what arin does should be of interest to nanog subscribers. in theory, the ops are the arin community, the registry serves operations. if it is not of interest to ops, it is not serving the community. [ get out of s'pore yet? drc got delayed a day with a missing part for his plane! ] randy From cb.list6 at gmail.com Thu Mar 27 22:10:17 2014 From: cb.list6 at gmail.com (Cb B) Date: Thu, 27 Mar 2014 15:10:17 -0700 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: On Mar 27, 2014 3:03 PM, "John Curran" wrote: > > And I would welcome discussion of how ARIN (and nanog) can be more like RIPE - that is very much up to this community and its participation far more than ARIN.. > > /John > How about we fold ARIN into RIPE? Why not? I agree with all of Randy's points. I am sure RIPE can easily scale up to take on ARIN services, with fees being reduced for all involved due to economies of scale. CB > > On Mar 28, 2014, at 5:27 AM, Randy Bush wrote: > > > > john, > > > > i think your attemt to move the discussion to the arin ppml list > > exemplifies one core of the problem. this is not about address policy, > > but arin thinks of itelf as a regulator not a registry. > > > > contrast with the ripe community and the ncc, which is not nirvana but > > is a hell of a lot better. among other key differences, the ncc is > > engaged with the community through technical and business working > > groups. > > > > e.g. the database working group covers what you think of as whois and > > the routing registry. the wg developed the darned irr definition and > > continues to evolve it. consequence? the irr is actively used in two > > regions in the world, europe and japan (which likes anything ocd:-). > > > > the routing wg works with the ops to develop routing technology such as > > route flap damping. there is a reason that serious ops attend ripe > > meetings. yes, a whole lot of folk with enable are engaged. > > > > for years there has been a wg on the global layer nine issues. > > > > the dns wg deals with reverse delegation, root server ops, etc. and > > guess what, all the dns heavy techs and ops are engaged. > > > > there is a wg for discussing what services the ncc offers. the recent > > simplification and opening of services to legacy and PI holders happened > > in the ncc services wg, it was about services not addressing policy. > > > > and this is aside from daniel's global measurement empire. not sure it > > is a registry's job to do this, but it is a serious contribution to the > > internet. > > > > the ncc is engaged with its community on the subhects that actually > > interest operators and affect our daily lives. > > > > there is nothing of interest at an arin meeting, a bunch of junior > > wannabe regulators and vigilantes making an embarrassing mess. i've > > even taken to skipping nanog, if ras talks i can watch the recording. > > all the cool kids will be in warsaw. ops vote with our feet. > > > > randy > > > From randy at psg.com Thu Mar 27 22:42:30 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Mar 2014 07:42:30 +0900 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: nanog is a separable game. it is currently very confused between form and substance, making committees for everything. like the bcop thing. two organizations, nanog and isoc, forming organizational structures to create a document store. the ops' doc store is ripe's because the ripe wgs produced work and someone realized they needed a place to stash it. so now nanog and isoc need to flag-plant. the up-side is that it's a great b-ark, keeps them from doing damage. > And I would welcome discussion of how ARIN (and nanog) can be more > like RIPE i purposefully phrased it a bit differently, how can arin engage, get real participation from, and serve its community, the operators. i was stealing examples from ripe. but, for concrete action, how about a half day session at the next nanog meeting on, for example, arin database services, whois and irr. not to try to reach hard conclusions or plans. but to open a dialog to explore what the community gets and wants from these services and how they are provided. or pick another key service. randy From randy at psg.com Thu Mar 27 23:10:47 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Mar 2014 08:10:47 +0900 Subject: Access Lists for Subscriber facing ports? In-Reply-To: References: Message-ID: two think that are simple, enforce bcp38 and ntp packet sizes rndy From bzs at world.std.com Thu Mar 27 23:32:16 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 27 Mar 2014 19:32:16 -0400 Subject: IPv6 isn't SMTP In-Reply-To: <53347920.4000302@ispn.net> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> <21300.30375.863357.496730@world.std.com> <53347920.4000302@ispn.net> Message-ID: <21300.46336.498337.544439@world.std.com> On March 27, 2014 at 14:16 blake at ispn.net (Blake Hudson) wrote: > > Barry Shein wrote the following on 3/27/2014 2:06 PM: > > > > > > I suppose the obvious question is: What's to stop a spammer from > > putting a totally legitimate key into their spam? > > > It's entirely likely that a spammer would try to get a hold of a key due > to its value or that someone you've done business with would share keys > with a "business" partner . But ideally you'd authorize each sender with > a unique key (or some sort of pair/combination). So that 1) you can tell > who the spammer sourced the key from and 2) you can revoke the > compromised key's authorization to send you subsequent email messages. > > There's probably some way to generate authorization such that each > sender gets a unique key or a generic base is in some way salted or > combined with information from the individual you're giving your > authorization to such that the result is both unique and identifiable. Ok, this is a form of whitelisting with some authentication using public key technology. Sure. But is this really the problem you run into much? Someone impersonating a sender you consider whitelisted? I'm sure it happens. But at a systems level I think most of us are talking about the much more nefarious non-stop fire-hose of pure sewage. Some white list, but for many that runs too great a risk of rejecting serendipity, that great job offer from someone who was impressed by a post you made on NANOG, etc. So we get Challenge-Response etc as a workaround, which also has problems. Well, whatever, SPAM IS A BIG SUBJECT and there are a lot of perspectives. P.S. I always figured the problem you describe could be very trivially solved by just agreeing to stick some word in the header like: X-PassCode: swordfish It's not like anyone but the sender is likely to know that unless they really are in your mail stream in which case you have other problems. It would be nice if that were automated but it could be done manually. I have certain Subject: phrases I use with people, some funny, so they know it's almost certainly me. -- -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 clay at bloomcounty.org Fri Mar 28 00:54:46 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Thu, 27 Mar 2014 17:54:46 -0700 Subject: IPv6 isn't SMTP In-Reply-To: <53347920.4000302@ispn.net> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> <21300.30375.863357.496730@world.std.com> <53347920.4000302@ispn.net> Message-ID: <8C103330-4081-4781-8057-31771546332D@bloomcounty.org> On Mar 27, 2014, at 12:16 PM, Blake Hudson wrote: > It's entirely likely that a spammer would try to get a hold of a key due to its value or that someone you've done business with would share keys with a "business" partner . But ideally you'd authorize each sender with a unique key (or some sort of pair/combination). So that 1) you can tell who the spammer sourced the key from and 2) you can revoke the compromised key's authorization to send you subsequent email messages. > > There's probably some way to generate authorization such that each sender gets a unique key or a generic base is in some way salted or combined with information from the individual you're giving your authorization to such that the result is both unique and identifiable. (Not to single you out, but this is a good entry point.) So somewhere between this and the ?every user should have their own MTA? idea, something would need to be done to close the end user usability gap. - ?I just bought something from this boutique website, how do I (or my ISP) know how to let them email me my receipt?? - ?My friend gave his buddy my email address to send a resume for that job opening I have. How do I permit him to send me email?? - ?This .gov entity needs to email me about my (taxes|health care|car registration|?), how do I give them permission?? - ?My long lost high school friend found my email address somewhere (and isn?t using gmail, hotmail, yahoo, ?.), how do I keep her from getting blocked?? All of these end-user questions will have to be answered by any such technology which seeks to solve the spam problem using a manner such as you describe here. And if you?re going to say the solution is ?in addition to my email address, in order to send me mail someone is going to have to know my (key|pass phrase|?)? then anything which currently collects your email address is also going to need to collect ?that?. Therefore how do you control ?that? from getting in the wrong hands in that list of emails someone is selling to spammers? Am I misunderstanding what?s being proposed here? To me the ubiquity of email is its own undoing ? it?s so convenient because you can email anybody, anywhere, from anywhere, but it?s so spammable because you can email anybody, anywhere, from anywhere. -c From tdurack at gmail.com Fri Mar 28 00:58:08 2014 From: tdurack at gmail.com (Tim Durack) Date: Thu, 27 Mar 2014 20:58:08 -0400 Subject: Why IPv6 isn't ready for prime time :-) Message-ID: NANOG arguments on IPv6 SMTP spam filtering. Deutsche Telecom discusses IPv4->IPv6 migration: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf Facebook goes public with their IPv4->IPv6 migration: http://www.internetsociety.org/deploy360/blog/2014/03/facebooks-extremely-impressive-internal-use-of-ipv6/ If you haven't started, you've got some work to do. Y2K/IPv6 consulting gigs? Nice little earner! -- Tim:> From johnl at iecc.com Fri Mar 28 00:58:54 2014 From: johnl at iecc.com (John Levine) Date: 28 Mar 2014 00:58:54 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Message-ID: <20140328005854.21858.qmail@joyce.lan> >What if Google, Apple, Sony or some other household brand, sold a TV with local mail capabilities, instead of pushing >everyone to use their hosted services? It would suck, because real users check their mail from their desktops, their laptops, and their phones. Your TV would not have the sophisticated mail sorting, archiving, and searching of the large mail systems. And, of course, when its cheap SSD flaked, you'd lose all your saved mail. I swear, this whole conversation feels like I've fallen through a wormhole into 1998. From dhc2 at dcrocker.net Fri Mar 28 01:46:58 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 27 Mar 2014 18:46:58 -0700 Subject: IPv6 isn't SMTP In-Reply-To: <53342CF5.3090009@ispn.net> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> Message-ID: <5334D492.8000802@dcrocker.net> On 3/27/2014 6:51 AM, Blake Hudson wrote: > The primary issues I see with SMTP as a protocol related to the lack of > authentication and authorization. Take, for instance, the fact that the > SMTP protocol requires a mail from: and rcpt to: address (more or less > for authentication and authorization purposes), Actually, for neither. Mail from was mislabeled; it merely provides an address to send return notices to, which is why it makes sense to permit it to be different from the rfc5322.From value. And, of course, rcpt to specifies a recipient address. auth/auth functions were tacked on much, much later, which is why their utility is so constrained. (20 years?) > but then in the message > allows the sender to specify a completely different set of sender and > recipient information that gets displayed in the mail client. Yeah. Almost like it is approximating the difference between what is on the outside of a postal envelope versus what is on the letterhead and opening of a piece of paper mail, which also permit such independence... The essential problem with seeing these as 'problems' is confusing 'common' with 'required'. Common scenarios are fine, but so are the variants. The variants often blow apart the simplifying assumption that one can incorrectly believe from the common scenarios. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jcurran at arin.net Fri Mar 28 02:04:30 2014 From: jcurran at arin.net (John Curran) Date: Fri, 28 Mar 2014 02:04:30 +0000 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <0C3EA47A-D825-47DC-B7BA-604BE609C8AF@arin.net> Message-ID: On Mar 28, 2014, at 6:04 AM, Randy Bush wrote: > i will refrain from characterizing the ppml list. needless to say, i do > not subscribe. > > my point is that what arin does should be of interest to nanog > subscribers. in theory, the ops are the arin community, the registry > serves operations. if it is not of interest to ops, it is not serving > the community. I fully agree, but also respect that this community has made some conscience decisions regarding having ARIN be quite registry focused and letting NANOG evolve as as a forum of the operators in the region. I believe that several of the initiatives that you noted from the RIPE region could easily be viewed as falling under either organization. This community should not be disadvantaged by the structure of having a distinct registry and distinct operator forum, but it does mean that we need to be able to sort out _what_ the operators want and then where it gets done. Internet routing registries are a fine example; one could argue that it should be integrated with the number resource registry, but we also have examples of independent routing registries in active use (and I can see some potential reasons why operators might even want there to be a healthy separation between those functions.) If the community has one mind of what routing registry capabilities is wants here, including how it wants it governed and operated, I am quite certain that ARIN will support the direction, regardless of where it ends up being operated and how it ends up being governed. The lack I have noted over the years is lack of clear direction from the community, but that should not be something "ARIN" jumps in and tries to bring about - it needs to be of interest to (and led by) the operators on this list. We agree that ARIN needs to be relevant to the ops community, and I am very open minded to any suggestions you have, but don't exactly think that your examples from RIPE are necessarily where we want ARIN to go as much as things we want to have happen, whether that's ARIN, NANOG, or other associated organizations. On the other hand, your governance examples from RIPE (e.g. "wg for discussing what services the ncc offers") are directly on target, and I will share them on some other lists that may defy characterization by you. > [ get out of s'pore yet? drc got delayed a day with a missing part for > his plane! ] (Getting closer... the last plane was a fail due to fuel pump issues; my dearest friends at United seemed have rerouted me through Hong Kong but omitted a flight onward. Oh well.) Thanks! /John From msa at latt.net Fri Mar 28 02:12:53 2014 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 27 Mar 2014 22:12:53 -0400 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <0C3EA47A-D825-47DC-B7BA-604BE609C8AF@arin.net> Message-ID: <20140328021253.GC21525@puck.nether.net> On Fri, Mar 28, 2014 at 02:04:30AM +0000, John Curran wrote: > Internet routing registries are a fine example; one could argue that > it should be integrated with the number resource registry, but we also > have examples of independent routing registries in active use (and I > can see some potential reasons why operators might even want there to > be a healthy separation between those functions.) Speaking for myself, only here: I'll be happy to let ARIN manage routability of assignments, once they guarantee routability of said assignments. Cheers, --msa From jcurran at arin.net Fri Mar 28 02:15:35 2014 From: jcurran at arin.net (John Curran) Date: Fri, 28 Mar 2014 02:15:35 +0000 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: <639A550F-F704-4EB6-B8A6-51A991FB2894@arin.net> On Mar 28, 2014, at 6:42 AM, Randy Bush wrote: > ... > i purposefully phrased it a bit differently, how can arin engage, get > real participation from, and serve its community, the operators. i was > stealing examples from ripe. > > but, for concrete action, how about a half day session at the next nanog > meeting on, for example, arin database services, whois and irr. not to > try to reach hard conclusions or plans. but to open a dialog to explore > what the community gets and wants from these services and how they are > provided. My earlier message was sent before I saw this, but I think we converged on the important point: ARIN needs to engage in a much better manner with the ops community (more than just an ARIN update preso and registration helpdesk); this should be closer to a "services wg" model. Got it, /John John Curran President and CEO ARIN From LarrySheldon at cox.net Fri Mar 28 02:27:06 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 Mar 2014 21:27:06 -0500 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> Message-ID: <5334DDFA.5020606@cox.net> On 3/27/2014 4:07 PM, Matt Palmer wrote: > On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote: >> The Full-disclosure mailing list was recently... retired, I guess cisco >> thought NANOG was the next best place. > > Nope, they've been sending these things here for as long as I can remember. > I have NFI why -- probably hubris, thinking that everyone running a network > *must* have some Cisco somewhere. There used to be cisco 'wigs with well-known names on NANOG. One of them was probably asked to do it. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From alexander at neilson.net.nz Fri Mar 28 02:44:11 2014 From: alexander at neilson.net.nz (Alexander Neilson) Date: Fri, 28 Mar 2014 15:44:11 +1300 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <5334DDFA.5020606@cox.net> References: <201403261210.17.ios@psirt.cisco.com> <5334DDFA.5020606@cox.net> Message-ID: <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> I wonder if they should be invited to only post a single message with the titles and links to the alerts so that people can follow it up. They should also include a link to their own list that they send the full alerts to. That way there could be some headline alerting to people that there is something in that topic available but avoids sending each alert to the list every time. Depends on compliance with the charter for the list but I think it might be nice list etiquette. Regards Alexander On 28/03/2014, at 3:27 pm, Larry Sheldon wrote: > On 3/27/2014 4:07 PM, Matt Palmer wrote: >> On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote: >>> The Full-disclosure mailing list was recently... retired, I guess cisco >>> thought NANOG was the next best place. >> >> Nope, they've been sending these things here for as long as I can remember. >> I have NFI why -- probably hubris, thinking that everyone running a network >> *must* have some Cisco somewhere. > > There used to be cisco 'wigs with well-known names on NANOG. > > One of them was probably asked to do it. > > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From shrdlu at deaddrop.org Fri Mar 28 03:48:29 2014 From: shrdlu at deaddrop.org (Shrdlu) Date: Thu, 27 Mar 2014 20:48:29 -0700 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> References: <201403261210.17.ios@psirt.cisco.com> <5334DDFA.5020606@cox.net> <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> Message-ID: <5334F10D.70907@deaddrop.org> On 3/27/2014 7:44 PM, Alexander Neilson wrote: > I wonder if they should be invited to only post a single message with > the titles and links to the alerts so that people can follow it up. Why? Personally, I think it's fine. It only happens (at most) every six months (and sometimes more like a year). > Depends on compliance with the charter for the list but I think it > might be nice list etiquette. I'm surprised at the level of concern over this, considering it's an event that has been going on since before most of those posting about this were even on this list. I'm hoping (in vain, I'm sure) that my gently pointing out that those posts are useful to many people, and that their occurrence predates most of you, will make this non-issue die away (and you make me REALLY MISS srh). While I still worked (I don't now; I'm retired), it was nice to have those alerts, because it could be checked against the *things* *that* *should* *be* *patched* for sanity. Even now, there's still Cisco stuff on my toy network, and I *still* care. Could we just stick to the interesting issues of IPv6, and SMTP, and move on? Please? -- You've confused equality of opportunity for equality of outcomes, and have seriously confused justice with equality. (Woodchuck) From randy at psg.com Fri Mar 28 04:57:22 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Mar 2014 13:57:22 +0900 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> References: <201403261210.17.ios@psirt.cisco.com> <5334DDFA.5020606@cox.net> <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> Message-ID: Alexander Neilson wrote: > I wonder if they should be invited to only post a single message with > the titles and links to the alerts so that people can follow it up. i would prefer that the header be in blue, the titles in green, and the urls in magenta, in comic sans, of course randy From LarrySheldon at cox.net Fri Mar 28 05:16:05 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 28 Mar 2014 00:16:05 -0500 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> <5334DDFA.5020606@cox.net> <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> Message-ID: <53350595.2020705@cox.net> On 3/27/2014 11:57 PM, Randy Bush wrote: > Alexander Neilson wrote: >> I wonder if they should be invited to only post a single message with >> the titles and links to the alerts so that people can follow it up. > > i would prefer that the header be in blue, the titles in green, and the > urls in magenta, in comic sans, of course I prefer flat ASCII text. That will shut most of them up. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From alter3d at alter3d.ca Fri Mar 28 05:16:59 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 28 Mar 2014 01:16:59 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: References: <201403261210.17.ios@psirt.cisco.com> <5334DDFA.5020606@cox.net> <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> Message-ID: <533505CB.6000200@alter3d.ca> On 3/28/2014 12:57 AM, Randy Bush wrote: > Alexander Neilson wrote: >> I wonder if they should be invited to only post a single message with >> the titles and links to the alerts so that people can follow it up. > i would prefer that the header be in blue, the titles in green, and the > urls in magenta, in comic sans, of course > > randy > I disagree vehemently. That's far too simple of a system and doesn't convey the necessary information that should be in a summary document. Titles should be either cerise, amaranth or raspberry coloured, depending on the bug's severity, and the headers should be blue-gray, glaucous or steel blue depending on the day of the week the bug was discovered. Some people might whine that those colors are too close to each other, but they can just buy a colorimeter -- that's an operational problem anyways. I can agree to comic sans, as long as it blinks. Actually, we should probably just set up a committee for report styling. We really need an industry standard for this, and one that covers all possible reporting needs for at least the next 20 years. Shouldn't take more than a few weeks. I think I have a TPS report template around here that would be a great starting point.... :p From bzs at world.std.com Fri Mar 28 05:31:00 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 28 Mar 2014 01:31:00 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> Message-ID: <21301.2324.18376.209669@world.std.com> On March 27, 2014 at 12:14 owen at delong.com (Owen DeLong) wrote: > > On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: > > > > > On March 26, 2014 at 22:25 owen at delong.com (Owen DeLong) wrote: > >> > >> Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. > >> > >> Thoughts? > > > > It's a fine idea but too complicated. > > > > Look, the (paper) post office doesn't say "oh, you WANTED that mail, > > ok, then we'll return the cost of postage to the sender!" > > > > Why? Because if they did that people would game the system, THEY'D > > SPAM! > > How would they benefit from that? >From what, being able to send free paper mail? I think that would be considered a benefit by most junk mail advertisers. But see next... > SPAM ? Pay, say $0.10/message. > Then Claim you wanted the SPAM, get your $0.10/message back for each SPAM you sent to yourself. > Or, claim you didn?t want the SPAM and get $0.05/message for each message you received while the > original provider keeps the other $0.05. > > > And it would take way too much bookkeeping and fraud identification etc. > > Please explain in detail where the fraud potential comes in. > > By my interpretation, you?d have to somehow get more back than you deposited (not really possible) in order to profit from sending SPAM this way. Well, it's advertising, so they do. Advertising is a valuable commodity. Free advertising is particularly valuable, ROI with I close to zero. Look, we can get lost in metaphors, but the point is that by the time the post office gets your mail to your doorstep virtually all the cost is sunk. So offering to not charge you because you wanted that mail makes no sense, right? > > Let's take a deep breath and re-examine the assumptions: > > > > Full scale spammers send on the order of one billion msgs per day. > > > > Which means if I gave your account 1M free msgs/day and could > > reasonably assure that you can't set up 1,000 such accts then you > > could not operate as a spammer. > > Not sure how you enforce these user account requirements or how you avoid duplicative accounts. If you want to attach e-postage you have to go get some and that can be a contract which says you don't do that, if you have multiple accounts you split it among your accounts or buy more. And if you do what you describe you understand that it is criminal fraud. Click Agree [ ] before proceeding, or similar. > > > Who can't operate with 1M msgs/day? > > > > Well, maybe Amazon or similar. > > > > But as I said earlier MAYBE THEY SHOULD PAY ALSO! > > I, for one, don?t want my Amazon prices increased by a pseudo-tax on the fact that they do a large volume of email communications with their customers. They have enough problems trying to get IPv6 deployed without adding this to their list of problems. That assumes that spam is free for them, and you. Including "free" as in "stealing your time". Also, companies like Amazon probably wouldn't mind being able to out-capitalize spammers and others in competing for your eyeballs. They could probably put a price on that. They're well aware that when they send you an email that says that some new book related to one you bought is available that the ad is surrounded by dozens if not hundreds of spam messages and likely you'll delete them all without reading. So that's already a cost to them in terms of wasted advertising effort and lost sales. I'd say we need to ask Amazon et al whether they'd see it as an economic plus if by paying a small amount of e-postage they could wipe out or seriously reduce all the chaff? Would that be a net positive or net negative to their bottom line? Although I can certainly understand skepticism about whether this approach would deliver effectively I don't think the business case, the dollar value of reducing spam significantly, is disputable. You'd always rather be the only billboard on the highway rather than just one in a hundred. Even if it costs you more (obviously up to a point.) > > > We really need to get over the moral component of spam content (and > > senders' intentions) and see it for what it is: A free ride anyone > > would take if available. > > I disagree. I see it as a form of theft of service that only immoral thieves would take if available. How can it be a theft of service if we're not charging anything? Well, if they use others' resources it's a theft of those resources, such as botnets, is that what you mean? But by morality I mean that we tend to define spam in terms of generally agreed to be undesirable email content such as questionable herbal cures or other apparent fraud or near-fraud -- I dunno, maybe someone hiring a spammer really believes their herbal hair re-growth tonic works. I assert that the line is getting fuzzier all the time. Even if the product is completely legitimate and maybe there's some business relationship someone can draw it doesn't mean I like being pummeled with hundreds of ads per day (some of that is projection, remember.) But, just as importantly, the people who want to send me an ad would like to see me pummeled with less junk so maybe I pay attention to their ad or communication. Heck, I alreadly almost never read email from what appears to be my bank because it's just too much time and effort to verify that it's legitimate. It'd be just as much effort under this, perhaps, but at least maybe I won't feel like I'm desperately trying to sort through 300 msgs that came in while I was asleep. > > Ok, a million free per acct might be too high but whatever, we can all > > go into committee and do studies and determine what the right number > > should be. > > > > I'd tend towards some sort of sliding scale myself, 100K/day free, > > 1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like > > that. > > > > Why would it work? > > > > Because that's how human society works. > > > > People who are willing to pay their $10K/mo will demand something be > > done about freeloaders, enforcement has to be part of the cost > > overhead. > > But who charges these fees and how do they enforce those charges against miscreants that are sending from stolen hosts, bots, fraudulent IP addresses, etc.? I think it would have some parallels to selling SSL certificates, as a business model. Sending from stolen hosts etc doesn't help them unless they have also broken into your e-postage stash. Which might happen of course but at that point we've reduced it to something like using your user SSL cert. For example if you had to enter a passphrase (other methods are possible) to enable mail sending with e-postage from your email client, to decrypt your e-postage cert, then they'd have to get into that also, not just use your cycles. That's possible but it's another hill for them to climb. Since you probably would value your e-postage at the very least there should be a little widget on your screen (or similar) with something like you have used 323 out of an allocation of 300,000 this month and if that suddenly says 32,323 out of 300,000 and you can't imagine why maybe you'll do something, call someone, some recommended response could be laid out like if that's way out of line then click here. That's not that different from how modern Windows systems pop-up a dialogue which says "XYZ wants to use administrator privilege to install software". That is, encourage the user to be aware of how much email they are sending and give them some reasonable course of action if something doesn't look right. Think of bandwidth caps on mobile phones. If you hit your cap and you don't have a clue why you become interested. If it's due to a virus or similar, even a misbehaving app you downloaded (it happens), you are interested because you're now being charged for bandwidth or whatever happens when you exceed your cap. One reason few are currently interested in their system being botted is because they don't hit a cap, nothing really happens. And there's certainly little support infrastructure to help them fix the problem. If there was some money on the table, like with mobile phone caps, then perhaps there would be some infrastructure for that. Right now there's just excuses from ISPs et al that if someone gets botted oh well, block them or something, or in many cases do nothing because you don't want to annoy a paying customer and it just would increase your support costs when they call demanding to speak to someone. If there were a profitable e-postage infrastructure whose livelihood depended on all this working then maybe that wouldn't be the case. > > > And it'd create an economy for hunting down miscreants. > > So you?ve got a set of thieves who are stealing services to send vast volumes of email and you want to solve that problem by charging them more for those services that they are stealing (and, by the way, also charging some legitimate users as well). > > My guess is that the spammers are going to keep stealing and the people now being taxed for something that used to be free are going to object. I think you're skipping the point about how they'd have to successfully attach e-postage to every piece of email they sent from your system. So it's not the resources, it's the authorization which we're trying to control. Right now every piece of email they send from your botted system is the same as any email you'd send. If there were some sort of e-postage system with some basic security and tracking that becomes much more difficult for the spammer. Or they can use your system to send out a million msgs with no e-postage which, one hopes, will be rejected by receiving systems without delivery, much like fraudulent DKIM or SPF credentials. Which, one hopes, won't be profitable for them any more. > > > P.S. And in my vision accepting only email with valid e-postage would > > be voluntary though I suppose that might be "voluntary" at the > > provider level. For example someone like gmail at some point (of > > successful implementation of this scheme) might decide to just block > > invalid e-postage because hey your gmail acct is free! Let someone > > else sell you rules you prefer like controlling acceptance of invalid > > e-postage yourself. > > Well, here we get a hint at how you envision this working. There are lots of details that need to be solved in the implementation of such a scheme and I think the devil is prevalent among them. I agree, but I hope my efforts indicate it's not entirely half-baked or off the cuff. I don't think it's inherently much more difficult than the SSL certificate ecology thought it has some differences. And it introduces some actual economy in fighting fraud because fraud becomes more like counterfeiting money or real life postage stamps, someone loses money, someone is getting a free ride, and there's money at that point to investigate and prosecute just like we do with counterfeiting. One problem with the current anti-spam economy is that it doesn't particularly encourage fighting spam. If someone makes a living selling anti-spam software or appliances the sudden and complete disappearance of spam is not really good news, unless it's entirely due to their product. But I mean putting spammers out of business big-time. In my model it is good news, it means the model is working so keep buying that e-postage because it's the only thing keeping the barbarians outside the gates. > > Owen > -- -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 owen at delong.com Fri Mar 28 06:14:46 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 23:14:46 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> Message-ID: On Mar 27, 2014, at 1:38 PM, Brandon Ross wrote: > On Thu, 27 Mar 2014, Owen DeLong wrote: > >> On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: >> >> Please explain in detail where the fraud potential comes in. > > Spammer uses his botnet of zombie machines to send email from each of them to his own domain using the user's legitimate email address as From:. Spammer says it was unsolicited and keeps the full $.10/email that victim users have deposited into this escrow thing. > > Sounds a lot more profitable than regular spam. You say this like having a tax on running a botted computer on the internet would be a bad thing. I agree that it would provide a bit of profit to the spammers for a very short period of time, but I bet it would get a lot of bots fixed pretty quick. Owen From owen at delong.com Fri Mar 28 06:17:35 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 23:17:35 -0700 Subject: IPv6 Security In-Reply-To: <1395953738.7560.28.camel@karl> References: <20140327005039.GB7867@angus.ind.WPI.EDU> <32E0870D-86B8-44A7-853C-F261F2252EF6@delong.com> <20140327.085206.74744053.sthaug@nethelp.no> <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com> <1395953738.7560.28.camel@karl> Message-ID: <3ACA1E90-969B-40B6-8974-38E9F9B424B7@delong.com> On Mar 27, 2014, at 1:55 PM, Karl Auer wrote: > On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote: >> What do you think ?Link Layer Address? (RFC 3315, Section 9.1 Type 3) >> is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what >> this is intended to be. True, it includes an additional 16 bits of media type, >> but I don?t see that as being a problem. > > Though to be fair 3315 also says that the DUID should be treated as an > opaque blob, not parsed and bits extracted from it. From section 9: > > "Clients and servers MUST treat DUIDs as opaque values > and MUST only compare DUIDs for equality. Clients and > servers MUST NOT in any other way interpret DUIDs." > > Regarding section 9.4, which you refer to: 3315 only uses MACs to > *construct* useful DUIDs, not as a means of communicating MACs to > clients or servers. Also, an operator cannot RELY on getting a MAC > address in a DUID. > > DUID's *are* different and *do* require new ways of doing things. People > will work it out. Right? The comment wasn?t about getting the Mac address, the comment was about having a DUID that remains the same across reboots and software installations. Using LL (type 3) DUIDs should accomplish that. Linking your IPv4 DHCP System ID and your IPv6 DHCP System ID is a completely different problem which I don?t see much practical purpose for other than by the hostname which could easily be handled in the DDNS registration process. Owen From owen at delong.com Fri Mar 28 06:22:26 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Mar 2014 23:22:26 -0700 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> I, for one, would not want to start having to pay RIPE-level fees. ARIN fees are a much better deal than RIPE fees. Owen On Mar 27, 2014, at 3:10 PM, Cb B wrote: > On Mar 27, 2014 3:03 PM, "John Curran" wrote: >> >> And I would welcome discussion of how ARIN (and nanog) can be more like > RIPE - that is very much up to this community and its participation far > more than ARIN.. >> >> /John >> > > How about we fold ARIN into RIPE? Why not? I agree with all of Randy's > points. I am sure RIPE can easily scale up to take on ARIN services, with > fees being reduced for all involved due to economies of scale. > > CB > >>> On Mar 28, 2014, at 5:27 AM, Randy Bush wrote: >>> >>> john, >>> >>> i think your attemt to move the discussion to the arin ppml list >>> exemplifies one core of the problem. this is not about address policy, >>> but arin thinks of itelf as a regulator not a registry. >>> >>> contrast with the ripe community and the ncc, which is not nirvana but >>> is a hell of a lot better. among other key differences, the ncc is >>> engaged with the community through technical and business working >>> groups. >>> >>> e.g. the database working group covers what you think of as whois and >>> the routing registry. the wg developed the darned irr definition and >>> continues to evolve it. consequence? the irr is actively used in two >>> regions in the world, europe and japan (which likes anything ocd:-). >>> >>> the routing wg works with the ops to develop routing technology such as >>> route flap damping. there is a reason that serious ops attend ripe >>> meetings. yes, a whole lot of folk with enable are engaged. >>> >>> for years there has been a wg on the global layer nine issues. >>> >>> the dns wg deals with reverse delegation, root server ops, etc. and >>> guess what, all the dns heavy techs and ops are engaged. >>> >>> there is a wg for discussing what services the ncc offers. the recent >>> simplification and opening of services to legacy and PI holders happened >>> in the ncc services wg, it was about services not addressing policy. >>> >>> and this is aside from daniel's global measurement empire. not sure it >>> is a registry's job to do this, but it is a serious contribution to the >>> internet. >>> >>> the ncc is engaged with its community on the subhects that actually >>> interest operators and affect our daily lives. >>> >>> there is nothing of interest at an arin meeting, a bunch of junior >>> wannabe regulators and vigilantes making an embarrassing mess. i've >>> even taken to skipping nanog, if ras talks i can watch the recording. >>> all the cool kids will be in warsaw. ops vote with our feet. >>> >>> randy >>> >> From mark.tinka at seacom.mu Fri Mar 28 06:30:32 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 28 Mar 2014 08:30:32 +0200 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: <201403280830.36557.mark.tinka@seacom.mu> On Thursday, March 27, 2014 11:27:26 PM Randy Bush wrote: > e.g. the database working group covers what you think of > as whois and the routing registry. the wg developed the > darned irr definition and continues to evolve it. > consequence? the irr is actively used in two regions in > the world, europe and japan (which likes anything > ocd:-). The RIPE IRR is used very widely in the Africa region, too. Great toolset. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Mar 28 06:34:58 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 28 Mar 2014 08:34:58 +0200 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <5334F10D.70907@deaddrop.org> References: <201403261210.17.ios@psirt.cisco.com> <8B649871-1550-48A9-A60A-1181B93FA5A7@neilson.net.nz> <5334F10D.70907@deaddrop.org> Message-ID: <201403280834.59328.mark.tinka@seacom.mu> On Friday, March 28, 2014 05:48:29 AM Shrdlu wrote: > Why? Personally, I think it's fine. It only happens (at > most) every six months (and sometimes more like a year). I think it's fine too. As I'm sure you know, if you're a Cisco customer, you can subscribe to their internal notification services where you'll get this anyway. That they consolidate the most critical bug information and push it out to the typical operational mailing lists a couple of times a year is not such a problem, I'd say. For some, this could be the only way they find out. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Fri Mar 28 07:06:49 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Mar 2014 00:06:49 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21301.2324.18376.209669@world.std.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> Message-ID: <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> On Mar 27, 2014, at 10:31 PM, Barry Shein wrote: > > On March 27, 2014 at 12:14 owen at delong.com (Owen DeLong) wrote: >> >> On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: >> >>> >>> On March 26, 2014 at 22:25 owen at delong.com (Owen DeLong) wrote: >>>> >>>> Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. >>>> >>>> Thoughts? >>> >>> It's a fine idea but too complicated. >>> >>> Look, the (paper) post office doesn't say "oh, you WANTED that mail, >>> ok, then we'll return the cost of postage to the sender!" >>> >>> Why? Because if they did that people would game the system, THEY'D >>> SPAM! >> >> How would they benefit from that? > >> From what, being able to send free paper mail? I think that would be > considered a benefit by most junk mail advertisers. But see next... > >> SPAM ? Pay, say $0.10/message. >> Then Claim you wanted the SPAM, get your $0.10/message back for each SPAM you sent to yourself. >> Or, claim you didn?t want the SPAM and get $0.05/message for each message you received while the >> original provider keeps the other $0.05. >> >>> And it would take way too much bookkeeping and fraud identification etc. >> >> Please explain in detail where the fraud potential comes in. >> >> By my interpretation, you?d have to somehow get more back than you deposited (not really possible) in order to profit from sending SPAM this way. > > Well, it's advertising, so they do. > > Advertising is a valuable commodity. Free advertising is particularly > valuable, ROI with I close to zero. But it?s only free if you send it to yourself and then approve it. Any message you send to someone else who doesn?t want it isn?t free. > So offering to not charge you because you wanted that mail makes no > sense, right? But this isn?t a charge for the post office and by the time you?re connected to the internet, the cost of receiving the mail and transporting it and the sender sending it is pretty much sunk by some arguments. This is an effort to provide a financial disincentive for spamming. > >>> Let's take a deep breath and re-examine the assumptions: >>> >>> Full scale spammers send on the order of one billion msgs per day. >>> >>> Which means if I gave your account 1M free msgs/day and could >>> reasonably assure that you can't set up 1,000 such accts then you >>> could not operate as a spammer. >> >> Not sure how you enforce these user account requirements or how you avoid duplicative accounts. > > If you want to attach e-postage you have to go get some and that can > be a contract which says you don't do that, if you have multiple > accounts you split it among your accounts or buy more. And if you do > what you describe you understand that it is criminal fraud. Click > Agree [ ] before proceeding, or similar. Because spammers are all on the up and up and never commit fraud in order to send their SPAM, right? >>> Who can't operate with 1M msgs/day? >>> >>> Well, maybe Amazon or similar. >>> >>> But as I said earlier MAYBE THEY SHOULD PAY ALSO! >> >> I, for one, don?t want my Amazon prices increased by a pseudo-tax on the fact that they do a large volume of email communications with their customers. They have enough problems trying to get IPv6 deployed without adding this to their list of problems. > > That assumes that spam is free for them, and you. Including "free" as > in "stealing your time?. No, it assumes that most of the messages I get from Amazon are NOT SPAM. The vast majority of messages I get from Amazon are order confirmations, shipping status reports, etc. Messages related to transactions I have conducted with them. Yes, I get a little bit of SPAM from them and I wouldn?t mind seeing them forced to pay me for those messages, but I certainly don?t want to see them paying for every message they send. >>> We really need to get over the moral component of spam content (and >>> senders' intentions) and see it for what it is: A free ride anyone >>> would take if available. >> >> I disagree. I see it as a form of theft of service that only immoral thieves would take if available. > > How can it be a theft of service if we're not charging anything? I didn?t authorize the spammer to use my computer, systems, disk, network, etc. They simply did so without my authorization. If I had a cost effective way to identify them, track them down, and hold them accountable for this, I would gladly do so. > Well, if they use others' resources it's a theft of those resources, > such as botnets, is that what you mean? Botnets, my mail server, my disk storage, my network, etc. where my mail is processed? All of the above. > But by morality I mean that we tend to define spam in terms of > generally agreed to be undesirable email content such as questionable > herbal cures or other apparent fraud or near-fraud -- I dunno, maybe > someone hiring a spammer really believes their herbal hair re-growth > tonic works. I define SPAM not in terms of content, but in the nature of the relationship between the sender and the recipient. If the recipient has no relationship with the sender and doesn?t want to receive the sender?s message, then in most cases, it?s SPAM. > I assert that the line is getting fuzzier all the time. Yep. If you try to define it on content, the fuzz grows out of control. > Even if the product is completely legitimate and maybe there's some > business relationship someone can draw it doesn't mean I like being > pummeled with hundreds of ads per day (some of that is projection, > remember.) If you ask the sender to stop and they don?t, then their further messages are SPAM. If you can?t find the sender in order to ask them to stop, then their messages are fraudulent SPAM. > But, just as importantly, the people who want to send me an ad would > like to see me pummeled with less junk so maybe I pay attention to > their ad or communication. The spammers would like to see you pummeled with less ?junk? so you can pay attention to their ad, too. Difference is in your definition of ?junk? vs. their definition of ?junk?. > Heck, I alreadly almost never read email from what appears to be my > bank because it's just too much time and effort to verify that it's > legitimate. I just bank with banks that don?t have enough customers to be attractive to spammers? Saves a lot of effort. Also makes for a nicer relationship with the bank. The tellers mostly know who I am and I?m treated like a customer instead of an inconvenience. > It'd be just as much effort under this, perhaps, but at least maybe I > won't feel like I'm desperately trying to sort through 300 msgs that > came in while I was asleep. I wish I could get it down to 300. >> >> So you?ve got a set of thieves who are stealing services to send vast volumes of email and you want to solve that problem by charging them more for those services that they are stealing (and, by the way, also charging some legitimate users as well). >> >> My guess is that the spammers are going to keep stealing and the people now being taxed for something that used to be free are going to object. > > I think you're skipping the point about how they'd have to > successfully attach e-postage to every piece of email they sent from > your system. Why would you assume that once they bot a system, they would be unable to steal the e-postage from said system? > > So it's not the resources, it's the authorization which we're trying > to control. > > Right now every piece of email they send from your botted system is > the same as any email you'd send. I?m not really seeing how this would make a difference in that. > > If there were some sort of e-postage system with some basic security > and tracking that becomes much more difficult for the spammer. Given how most bots become bots, I tend to doubt it. They just have to keystroke log your MUA in a two-step process instead of the one-step process of days of yore. Further, since they?re sending lots and lots of the same spam with identical envelope contents and the only differences are in the SMTP exchange, not the internal contents of the envelope, a replay attack against the same postage would seem pretty trivial. > > Or they can use your system to send out a million msgs with no > e-postage which, one hopes, will be rejected by receiving systems > without delivery, much like fraudulent DKIM or SPF credentials. > > Which, one hopes, won't be profitable for them any more. > >> >>> P.S. And in my vision accepting only email with valid e-postage would >>> be voluntary though I suppose that might be "voluntary" at the >>> provider level. For example someone like gmail at some point (of >>> successful implementation of this scheme) might decide to just block >>> invalid e-postage because hey your gmail acct is free! Let someone >>> else sell you rules you prefer like controlling acceptance of invalid >>> e-postage yourself. >> >> Well, here we get a hint at how you envision this working. There are lots of details that need to be solved in the implementation of such a scheme and I think the devil is prevalent among them. > > I agree, but I hope my efforts indicate it's not entirely half-baked > or off the cuff. Intrigued, but not convinced. Owen From daniel.karrenberg at ripe.net Fri Mar 28 08:10:50 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 28 Mar 2014 09:10:50 +0100 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: > On 27.03.2014, at 22:27, Randy Bush wrote: > > ...and this is aside from daniel's global measurement empire. not sure it > is a registry's job to do this, but it is a serious contribution to the > internet. ... there is the 'measurement analysis and tools' working group http://www.ripe.net/ripe/groups/wg/mat guiding this work, and it even has an 'out-of-area' co-chair to emphasize the *globalness* of our empire ;-) :-) :-) :-) :-) :-) seriously: the ripe ncc was not conceived as a "registry" but as an association of operators where they can organise common activities that require neutrality, expertise and common funding. so whether it is a 'registry job' is irrelevant in our context as long as the community agrees it is useful and the membership of the association agrees to fund it with their fees. the huge overlap between community at large and paying membership keeps this consistent. daniel ---------- Sent from a hand held device. From bross at pobox.com Fri Mar 28 12:27:30 2014 From: bross at pobox.com (Brandon Ross) Date: Fri, 28 Mar 2014 08:27:30 -0400 (EDT) Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> Message-ID: On Thu, 27 Mar 2014, Owen DeLong wrote: > On Mar 27, 2014, at 1:38 PM, Brandon Ross wrote: > >> On Thu, 27 Mar 2014, Owen DeLong wrote: >> >>> On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: >>> >>> Please explain in detail where the fraud potential comes in. >> >> Spammer uses his botnet of zombie machines to send email from each of them to his own domain using the user's legitimate email address as From:. Spammer says it was unsolicited and keeps the full $.10/email that victim users have deposited into this escrow thing. >> >> Sounds a lot more profitable than regular spam. > > You say this like having a tax on running a botted computer on the > internet would be a bad thing. Heh, perhaps not... > I agree that it would provide a bit of profit to the spammers for a very > short period of time, but I bet it would get a lot of bots fixed pretty > quick. I don't think so. The motivations to continue to game the system are much stronger under this scheme because the profits are immediate and direct. A spammer no longer has to just hope that the advertising, phishing or whatever they are up to is acted upon by the user, instead they get a somewhat immediate cash payout that's not dependent on the user. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From tmorizot at gmail.com Fri Mar 28 12:56:08 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Fri, 28 Mar 2014 07:56:08 -0500 Subject: Why IPv6 isn't ready for prime time :-) In-Reply-To: References: Message-ID: On Mar 27, 2014 8:01 PM, "Tim Durack" wrote: > > NANOG arguments on IPv6 SMTP spam filtering. > > Deutsche Telecom discusses IPv4->IPv6 migration: > > https://ripe67.ripe.net/presentations/131-ripe2-2.pdf > > Facebook goes public with their IPv4->IPv6 migration: > > http://www.internetsociety.org/deploy360/blog/2014/03/facebooks-extremely-impressive-internal-use-of-ipv6/ > > If you haven't started, you've got some work to do. Indeed. Having been deeply involved leading the technical side of our transition at my organiati From sander at steffann.nl Fri Mar 28 12:58:51 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Mar 2014 13:58:51 +0100 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> Message-ID: <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> Hi Owen, > I, for one, would not want to start having to pay RIPE-level fees. > > ARIN fees are a much better deal than RIPE fees. Only up to Small... The RIPE NCC membership fee is ?1750 (?$2400 currently) for everybody. The ARIN fees are between $500 and $32000, with category Small at $2000 and Medium at $4000. I personally am glad about this (although in ARIN I would probably be Small) because it doesn't give operators any financial incentive to stingy when giving their customers IPv6 prefixes. If you want to give a million customers a /48 it is not going to cost you more then giving them a /60. IPv6 resources are not such a scarce resource compared to IPv4, so differentiating price based on the amount of integers you need doesn't make much sense in the current world anymore :) But: this is all RIPE NCC members/AGM stuff, independent of the RIPE community and its working groups. (well the RIPE NCC facilitates the RIPE meetings (note: RIPE meeting, not RIPE NCC meeting) and without the help of the NCC the RIPE community wouldn't have such well organised meetings. The NCC only facilitates though, it doesn't control or influence the RIPE working groups) and the structure of the RIPE working groups was what Randy was referring to. Cheers, Sander From tmorizot at gmail.com Fri Mar 28 12:58:56 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Fri, 28 Mar 2014 07:58:56 -0500 Subject: Why IPv6 isn't ready for prime time :-) In-Reply-To: References: Message-ID: Hmmm. Phone accidentally sent email before it was finished. Indeed. Having been deeply involved leading the technical side of our transition at my organization for the past three years, I think those who wait until the IPv6/IPv4 divide is roughly 50/50 or later are going to be in for a world of hurt. From blake at ispn.net Fri Mar 28 13:06:06 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 28 Mar 2014 08:06:06 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <21300.46336.498337.544439@world.std.com> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> <21300.30375.863357.496730@world.std.com> <53347920.4000302@ispn.net> <21300.46336.498337.544439@world.std.com> Message-ID: <533573BE.5090404@ispn.net> Barry Shein wrote the following on 3/27/2014 6:32 PM: > On March 27, 2014 at 14:16 blake at ispn.net (Blake Hudson) wrote: > > > > Barry Shein wrote the following on 3/27/2014 2:06 PM: > > > > > > > > > I suppose the obvious question is: What's to stop a spammer from > > > putting a totally legitimate key into their spam? > > > > > It's entirely likely that a spammer would try to get a hold of a key due > > to its value or that someone you've done business with would share keys > > with a "business" partner . But ideally you'd authorize each sender with > > a unique key (or some sort of pair/combination). So that 1) you can tell > > who the spammer sourced the key from and 2) you can revoke the > > compromised key's authorization to send you subsequent email messages. > > > > There's probably some way to generate authorization such that each > > sender gets a unique key or a generic base is in some way salted or > > combined with information from the individual you're giving your > > authorization to such that the result is both unique and identifiable. > > Ok, this is a form of whitelisting with some authentication using > public key technology. > > Sure. But is this really the problem you run into much? Someone > impersonating a sender you consider whitelisted? > > I'm sure it happens. > > But at a systems level I think most of us are talking about the much > more nefarious non-stop fire-hose of pure sewage. > > Some white list, but for many that runs too great a risk of rejecting > serendipity, that great job offer from someone who was impressed by a > post you made on NANOG, etc. > > So we get Challenge-Response etc as a workaround, which also has > problems. > > Well, whatever, SPAM IS A BIG SUBJECT and there are a lot of > perspectives. > > P.S. I always figured the problem you describe could be very trivially > solved by just agreeing to stick some word in the header like: > > X-PassCode: swordfish > > It's not like anyone but the sender is likely to know that unless they > really are in your mail stream in which case you have other problems. > > It would be nice if that were automated but it could be done manually. > > I have certain Subject: phrases I use with people, some funny, so they > know it's almost certainly me. You're on the right track with what I was proposing. While spoofing can be addressed, it's not the primary goal. The idea was to verify whether an incoming email was authorized or not. Authentication is just a prereq to that. It is up to the recipient to choose what to do with unauthorized mail: Treat them the same as any other, tag them, put them in a separate folder or quarantine, reject them, or send them to the bit bucket. This may be a list, but I wouldn't consider a whitelist unless implemented as such by the user/client. From blake at ispn.net Fri Mar 28 13:08:23 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 28 Mar 2014 08:08:23 -0500 Subject: IPv6 isn't SMTP In-Reply-To: <8C103330-4081-4781-8057-31771546332D@bloomcounty.org> References: <20140326041858.7576.qmail@joyce.lan> <5332CBD2.2030008@vocalabs.com> <533351B9.9050204@ispn.net> <53342CF5.3090009@ispn.net> <21300.30375.863357.496730@world.std.com> <53347920.4000302@ispn.net> <8C103330-4081-4781-8057-31771546332D@bloomcounty.org> Message-ID: <53357447.9020902@ispn.net> Clay Fiske wrote the following on 3/27/2014 7:54 PM: > On Mar 27, 2014, at 12:16 PM, Blake Hudson wrote: > >> It's entirely likely that a spammer would try to get a hold of a key due to its value or that someone you've done business with would share keys with a "business" partner . But ideally you'd authorize each sender with a unique key (or some sort of pair/combination). So that 1) you can tell who the spammer sourced the key from and 2) you can revoke the compromised key's authorization to send you subsequent email messages. >> >> There's probably some way to generate authorization such that each sender gets a unique key or a generic base is in some way salted or combined with information from the individual you're giving your authorization to such that the result is both unique and identifiable. > (Not to single you out, but this is a good entry point.) > > So somewhere between this and the ?every user should have their own MTA? idea, something would need to be done to close the end user usability gap. > > - ?I just bought something from this boutique website, how do I (or my ISP) know how to let them email me my receipt?? > - ?My friend gave his buddy my email address to send a resume for that job opening I have. How do I permit him to send me email?? > - ?This .gov entity needs to email me about my (taxes|health care|car registration|?), how do I give them permission?? > - ?My long lost high school friend found my email address somewhere (and isn?t using gmail, hotmail, yahoo, ?.), how do I keep her from getting blocked?? > > All of these end-user questions will have to be answered by any such technology which seeks to solve the spam problem using a manner such as you describe here. And if you?re going to say the solution is ?in addition to my email address, in order to send me mail someone is going to have to know my (key|pass phrase|?)? then anything which currently collects your email address is also going to need to collect ?that?. Therefore how do you control ?that? from getting in the wrong hands in that list of emails someone is selling to spammers? > > Am I misunderstanding what?s being proposed here? To me the ubiquity of email is its own undoing ? it?s so convenient because you can email anybody, anywhere, from anywhere, but it?s so spammable because you can email anybody, anywhere, from anywhere. > > > -c You're absolutely correct. These are the exact challenges and I'm sure they can be addressed, over time. From owen at delong.com Fri Mar 28 13:22:32 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Mar 2014 06:22:32 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> Message-ID: <715CE67A-5538-48BB-B91B-F4708EA3CD0D@delong.com> On Mar 28, 2014, at 5:27 AM, Brandon Ross wrote: > On Thu, 27 Mar 2014, Owen DeLong wrote: > >> On Mar 27, 2014, at 1:38 PM, Brandon Ross wrote: >> >>> On Thu, 27 Mar 2014, Owen DeLong wrote: >>> >>>> On Mar 27, 2014, at 11:15 AM, Barry Shein wrote: >>>> >>>> Please explain in detail where the fraud potential comes in. >>> >>> Spammer uses his botnet of zombie machines to send email from each of them to his own domain using the user's legitimate email address as From:. Spammer says it was unsolicited and keeps the full $.10/email that victim users have deposited into this escrow thing. >>> >>> Sounds a lot more profitable than regular spam. >> >> You say this like having a tax on running a botted computer on the internet would be a bad thing. > > Heh, perhaps not... > >> I agree that it would provide a bit of profit to the spammers for a very short period of time, but I bet it would get a lot of bots fixed pretty quick. > > I don't think so. The motivations to continue to game the system are much stronger under this scheme because the profits are immediate and direct. A spammer no longer has to just hope that the advertising, phishing or whatever they are up to is acted upon by the user, instead they get a somewhat immediate cash payout that's not dependent on the user. This assumes a different economic model of SPAM that I have been lead to believe exists. My understanding is that the people sending the SPAM get paid immediately and that the people paying them to send it are the ones hoping that the advertising/phishing/etc. are acted on. Owen From owen at delong.com Fri Mar 28 13:26:06 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Mar 2014 06:26:06 -0700 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> Message-ID: <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> On Mar 28, 2014, at 5:58 AM, Sander Steffann wrote: > Hi Owen, > >> I, for one, would not want to start having to pay RIPE-level fees. >> >> ARIN fees are a much better deal than RIPE fees. > > Only up to Small... The RIPE NCC membership fee is ?1750 (?$2400 currently) for everybody. The ARIN fees are between $500 and $32000, with category Small at $2000 and Medium at $4000. I personally am glad about this (although in ARIN I would probably be Small) because it doesn't give operators any financial incentive to stingy when giving their customers IPv6 prefixes. > > If you want to give a million customers a /48 it is not going to cost you more then giving them a /60. IPv6 resources are not such a scarce resource compared to IPv4, so differentiating price based on the amount of integers you need doesn't make much sense in the current world anymore :) > > But: this is all RIPE NCC members/AGM stuff, independent of the RIPE community and its working groups. (well the RIPE NCC facilitates the RIPE meetings (note: RIPE meeting, not RIPE NCC meeting) and without the help of the NCC the RIPE community wouldn't have such well organised meetings. The NCC only facilitates though, it doesn't control or influence the RIPE working groups) and the structure of the RIPE working groups was what Randy was referring to. Compare and contrast the costs of being a PI holding end-user in the RIPE region to those in the ARIN region and the difference becomes much more noticeable. Owen From bross at pobox.com Fri Mar 28 13:30:08 2014 From: bross at pobox.com (Brandon Ross) Date: Fri, 28 Mar 2014 09:30:08 -0400 (EDT) Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <715CE67A-5538-48BB-B91B-F4708EA3CD0D@delong.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <715CE67A-5538-48BB-B91B-F4708EA3CD0D@delong.com> Message-ID: On Fri, 28 Mar 2014, Owen DeLong wrote: > This assumes a different economic model of SPAM that I have been lead to > believe exists. > > My understanding is that the people sending the SPAM get paid > immediately and that the people paying them to send it are the ones > hoping that the advertising/phishing/etc. are acted on. Fine, then the people paying the people who do the spamming have more of an incentive to pay higher rates and more spammers. It doesn't really matter how may layers of abstraction there are, the point is that the main motivator has become more attractive. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From Valdis.Kletnieks at vt.edu Fri Mar 28 13:41:22 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Mar 2014 09:41:22 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "Fri, 28 Mar 2014 06:22:32 -0700." <715CE67A-5538-48BB-B91B-F4708EA3CD0D@delong.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <715CE67A-5538-48BB-B91B-F4708EA3CD0D@delong.com> Message-ID: <42099.1396014082@turing-police.cc.vt.edu> On Fri, 28 Mar 2014 06:22:32 -0700, Owen DeLong said: > This assumes a different economic model of SPAM that I have been lead to > believe exists. > My understanding is that the people sending the SPAM get paid immediately and > that the people paying them to send it are the ones hoping that the advertising/ > phishing/etc. are acted on. Only because we haven't given them a way to monetize it immediately. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From owen at delong.com Fri Mar 28 13:39:26 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Mar 2014 06:39:26 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <715CE67A-5538-48BB-B91B-F4708EA3CD0D@delong.com> Message-ID: On Mar 28, 2014, at 6:30 AM, Brandon Ross wrote: > On Fri, 28 Mar 2014, Owen DeLong wrote: > >> This assumes a different economic model of SPAM that I have been lead to believe exists. >> >> My understanding is that the people sending the SPAM get paid immediately and that the people paying them to send it are the ones hoping that the advertising/phishing/etc. are acted on. > > Fine, then the people paying the people who do the spamming have more of an incentive to pay higher rates and more spammers. It doesn't really matter how may layers of abstraction there are, the point is that the main motivator has become more attractive. Perhaps? But I?m not convinced. Today we have more than sufficient motivation to continue to game the system and virtually no incentive to make the system less open to gaming. While I agree this would increase economic incentives to game the system slightly, it would also add some rather strong incentives to improve security and make the process of gaming much harder. Perhaps this isn?t a good solution, but it certainly cannot be argued that what we are doing so far is working. Owen From sander at steffann.nl Fri Mar 28 14:03:33 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Mar 2014 15:03:33 +0100 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> Message-ID: <9ECE2FC5-0CB9-42A7-BB9E-43B7D0379F1C@steffann.nl> Hi Owen, > Compare and contrast the costs of being a PI holding end-user in the RIPE region to those in the ARIN region and the difference becomes much more noticeable. Yeah, RIPE NCC is definitely much cheaper for PI: no initial registration fee of ?$500. The maintenance cost is $100/year vs ?100/year (?$137) so there is a little difference there. The $37 difference will take at least 13.5 years to make up for the $500 though. And that is just for up to a /22. The $4000 initial fee for a /16 PI would take you more than a hundred years :) So yes: for PI the difference is much more noticeable, in favour of the RIPE NCC :) Cheers, Sander From nick at foobar.org Fri Mar 28 14:20:12 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 28 Mar 2014 14:20:12 +0000 Subject: ARIN board accountability to network operators In-Reply-To: <9ECE2FC5-0CB9-42A7-BB9E-43B7D0379F1C@steffann.nl> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> <9ECE2FC5-0CB9-42A7-BB9E-43B7D0379F1C@steffann.nl> Message-ID: <5335851C.1010102@foobar.org> On 28/03/2014 14:03, Sander Steffann wrote: > Yeah, RIPE NCC is definitely much cheaper for PI: no initial > registration fee of ?$500. The maintenance cost is $100/year vs > ?100/year (?$137) so there is a little difference there. The $37 ?50 per PI assignment from the ripe ncc, no? http://www.ripe.net/ripe/docs/ripe-591 Nick From dhubbard at dino.hostasaurus.com Fri Mar 28 14:21:02 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 28 Mar 2014 10:21:02 -0400 Subject: 3356 leaking routes out 3549 lately? Message-ID: Has anyone had issues with Level 3 leaking advertisements out their Global Crossing AS3356 for customers of 3549, but not accepting the traffic back? We've been encountering this more and more recently, bgpmon always detects it, and all we ever get from them is there's nothing wrong. Today it affected CloudFlare's ability to talk to us. It seems to happen mostly with Europe and Asian peering points. Typically lasts five to ten minutes which makes me think someone working on merging the two networks is doing some 'no one will notice this' changes in the middle of the night. David From sander at steffann.nl Fri Mar 28 15:20:25 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Mar 2014 16:20:25 +0100 Subject: ARIN board accountability to network operators In-Reply-To: <5335851C.1010102@foobar.org> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> <9ECE2FC5-0CB9-42A7-BB9E-43B7D0379F1C@steffann.nl> <5335851C.1010102@foobar.org> Message-ID: <44E5487C-2A73-4D05-A425-FB0D0B55BA37@steffann.nl> Oops. /me was confused. ?50 indeed! Met vriendelijke groet, Sander Steffann > Op 28 mrt. 2014 om 15:20 heeft Nick Hilliard het volgende geschreven: > >> On 28/03/2014 14:03, Sander Steffann wrote: >> Yeah, RIPE NCC is definitely much cheaper for PI: no initial >> registration fee of ?$500. The maintenance cost is $100/year vs >> ?100/year (?$137) so there is a little difference there. The $37 > > ?50 per PI assignment from the ripe ncc, no? > > http://www.ripe.net/ripe/docs/ripe-591 > > Nick > > From johnl at iecc.com Fri Mar 28 16:49:58 2014 From: johnl at iecc.com (John Levine) Date: 28 Mar 2014 16:49:58 -0000 Subject: Why IPv6 isn't ready for prime time : -) In-Reply-To: Message-ID: <20140328164958.27435.qmail@joyce.lan> >Indeed. Having been deeply involved leading the technical side of our >transition at my organiati Yeah, IPv6 can be like that. Helpfully, John From Lee at asgard.org Fri Mar 28 17:02:53 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 28 Mar 2014 13:02:53 -0400 Subject: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal) In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> Message-ID: On 3/27/14 6:42 PM, "Randy Bush" wrote: >nanog is a separable game. it is currently very confused between form >and substance, making committees for everything. like the bcop thing. >two organizations, nanog and isoc, forming organizational structures to >create a document store. the ops' doc store is ripe's because the ripe >wgs produced work and someone realized they needed a place to stash it. I like this example, but not sure how it could apply here. Need a NANOG document series? It wouldn't be an ARIN document series, would it? Or did I miss the point of your example? > >i purposefully phrased it a bit differently, how can arin engage, get >real participation from, and serve its community, the operators. i was >stealing examples from ripe. > >but, for concrete action, how about a half day session at the next nanog >meeting on, for example, arin database services, whois and irr. not to >try to reach hard conclusions or plans. but to open a dialog to explore >what the community gets and wants from these services and how they are >provided. I like this example. I also appreciate the policy hour, where NANOG attendees get a few minutes on ARIN proposals. In another message you complimented the RIPE Atlas project. I like the work from APNIC's labs, too. I also like LACNIC's development projects, FRIDA, +RAICES, and education efforts. Would these kinds of efforts be in scope for ARIN? Does ARIN need a Chief Scientist (a la Karrenberg or Huston)? Or is that a NANOG role, since it might include things outside of management of number resources? I think North American operators are missing some advantages of the closely coordinated RIR/NOG operations in other regions, and I would like to see them closer together here. Unfortunately, it is not clear to me that the examples above are in charter for either NANOG or ARIN. I'd be happy to re-charter either, but that's probably a topic for NANOG-futures. > >or pick another key service. DNS? DNSsec? Security? > >randy Lee From johnl at iecc.com Fri Mar 28 17:07:07 2014 From: johnl at iecc.com (John Levine) Date: 28 Mar 2014 17:07:07 -0000 Subject: anti-spam WKBIs, was why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Message-ID: <20140328170707.27559.qmail@joyce.lan> >You say this like having a tax on running a botted computer on the internet would be a bad thing. > >I agree that it would provide a bit of profit to the spammers for a very short period of time, but I bet it would get >a lot of bots fixed pretty quick. What would actually happen is that the users would refuse to pay their ISPs for their bot mail, the ISPs would refuse to pay the recipients, and the whole thing would collapse. Like I said in my decade old white paper, the problems when real money are involved will be worse than the ones they purport to solve. On the other hand, if you plan to go ahead with this WKBI, I'll let Phil Raymond know. He'd love to do something with that patent. R's, John From nick at wiredmedium.com Fri Mar 28 17:15:54 2014 From: nick at wiredmedium.com (Nick) Date: Fri, 28 Mar 2014 12:15:54 -0500 Subject: WISP or other options In-Reply-To: <53344BEA.9020404@talkunafraid.co.uk> References: <53339B53.9040700@wiredmedium.com> <53344BEA.9020404@talkunafraid.co.uk> Message-ID: <5335AE4A.2040100@wiredmedium.com> Thanks for all the ideas. Right now, Im talking with Maxwifi. Go the route of letting them deal with everything. Im still exploring other cheaper options: A) 3G/4G wireless service. A Orange rep is building a data plan to support 160 devices and to find out data usage in the area and available bandwidth. B) Getting wireless service from the near by datacenter(~6 miles away in South Gyle). Can anyone recommended a good 3G/4G router? The follow link looks good. http://www.proroute.co.uk/proroute-4g-routers/proroute-h820-4g-router/ Would it be better to run one 4G route or bond many of cheap hotspot? Thanks, Nick Poulakos From cscora at apnic.net Fri Mar 28 18:12:50 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Mar 2014 04:12:50 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201403281812.s2SIComv029202@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Mar, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 489473 Prefixes after maximum aggregation: 192590 Deaggregation factor: 2.54 Unique aggregates announced to Internet: 241381 Total ASes present in the Internet Routing Table: 46469 Prefixes per ASN: 10.53 Origin-only ASes present in the Internet Routing Table: 35716 Origin ASes announcing only one prefix: 16381 Transit ASes present in the Internet Routing Table: 6035 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1863 Unregistered ASNs in the Routing Table: 476 Number of 32-bit ASNs allocated by the RIRs: 6256 Number of 32-bit ASNs visible in the Routing Table: 4718 Prefixes from 32-bit ASNs in the Routing Table: 15266 Number of bogon 32-bit ASNs visible in the Routing Table: 50 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 444 Number of addresses announced to Internet: 2662858628 Equivalent to 158 /8s, 183 /16s and 255 /24s Percentage of available address space announced: 71.9 Percentage of allocated address space announced: 71.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.0 Total number of prefixes smaller than registry allocations: 170530 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 116226 Total APNIC prefixes after maximum aggregation: 34666 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 118899 Unique aggregates announced from the APNIC address blocks: 49753 APNIC Region origin ASes present in the Internet Routing Table: 4908 APNIC Prefixes per ASN: 24.23 APNIC Region origin ASes announcing only one prefix: 1230 APNIC Region transit ASes present in the Internet Routing Table: 855 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 879 Number of APNIC addresses announced to Internet: 729984896 Equivalent to 43 /8s, 130 /16s and 175 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 166997 Total ARIN prefixes after maximum aggregation: 83020 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 168430 Unique aggregates announced from the ARIN address blocks: 78330 ARIN Region origin ASes present in the Internet Routing Table: 16204 ARIN Prefixes per ASN: 10.39 ARIN Region origin ASes announcing only one prefix: 6115 ARIN Region transit ASes present in the Internet Routing Table: 1671 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 77 Number of ARIN addresses announced to Internet: 1067831936 Equivalent to 63 /8s, 165 /16s and 210 /24s Percentage of available ARIN address space announced: 56.5 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, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 123204 Total RIPE prefixes after maximum aggregation: 62152 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 127271 Unique aggregates announced from the RIPE address blocks: 80443 RIPE Region origin ASes present in the Internet Routing Table: 17648 RIPE Prefixes per ASN: 7.21 RIPE Region origin ASes announcing only one prefix: 8286 RIPE Region transit ASes present in the Internet Routing Table: 2863 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2678 Number of RIPE addresses announced to Internet: 657612420 Equivalent to 39 /8s, 50 /16s and 94 /24s Percentage of available RIPE address space announced: 95.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, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 55383 Total LACNIC prefixes after maximum aggregation: 10055 LACNIC Deaggregation factor: 5.51 Prefixes being announced from the LACNIC address blocks: 61471 Unique aggregates announced from the LACNIC address blocks: 28188 LACNIC Region origin ASes present in the Internet Routing Table: 2082 LACNIC Prefixes per ASN: 29.52 LACNIC Region origin ASes announcing only one prefix: 547 LACNIC Region transit ASes present in the Internet Routing Table: 422 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1070 Number of LACNIC addresses announced to Internet: 154037760 Equivalent to 9 /8s, 46 /16s and 110 /24s Percentage of available LACNIC address space announced: 91.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12290 Total AfriNIC prefixes after maximum aggregation: 2658 AfriNIC Deaggregation factor: 4.62 Prefixes being announced from the AfriNIC address blocks: 12958 Unique aggregates announced from the AfriNIC address blocks: 4292 AfriNIC Region origin ASes present in the Internet Routing Table: 709 AfriNIC Prefixes per ASN: 18.28 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 151 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 14 Number of AfriNIC addresses announced to Internet: 53079552 Equivalent to 3 /8s, 41 /16s and 238 /24s Percentage of available AfriNIC address space announced: 52.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2972 11582 896 Korea Telecom 17974 2776 903 78 PT Telekomunikasi Indonesia 7545 2229 320 118 TPG Telecom Limited 4755 1843 396 197 TATA Communications formerly 9829 1621 1288 35 National Internet Backbone 4808 1360 2227 386 CNCGROUP IP network China169 9583 1316 102 533 Sify Limited 9498 1247 312 79 BHARTI Airtel Ltd. 7552 1228 1082 13 Viettel Corporation 24560 1123 384 177 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3009 3688 53 BellSouth.net Inc. 22773 2410 2938 140 Cox Communications Inc. 1785 2193 696 130 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1695 1675 576 Charter Communications 4323 1632 1089 414 tw telecom holdings, inc. 701 1485 11158 756 MCI Communications Services, 30036 1393 301 548 Mediacom Communications Corp 6983 1328 800 308 ITC^Deltacom 22561 1304 402 232 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1717 544 15 OJSC "Vimpelcom" 34984 1548 263 278 TELLCOM ILETISIM HIZMETLERI A 20940 1267 479 950 Akamai International B.V. 13188 1048 100 33 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 966 370 41 Bezeq International-Ltd 6849 862 361 34 JSC "Ukrtelecom" 6830 763 2329 426 Liberty Global Operations B.V 12479 715 797 56 France Telecom Espana SA 35228 555 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3633 1947 96 NET Servi?os de Comunica??o S 10620 2804 449 192 Telmex Colombia S.A. 18881 1917 972 21 Global Village Telecom 7303 1751 1172 228 Telecom Argentina S.A. 8151 1397 2922 407 Uninet S.A. de C.V. 6503 1158 434 61 Axtel, S.A.B. de C.V. 7738 912 1754 40 Telemar Norte Leste S.A. 27947 860 113 48 Telconet S.A 11830 847 364 15 Instituto Costarricense de El 3816 785 319 128 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1637 240 6 Sudanese Mobile Telephone (ZA 24863 947 280 26 Link Egypt (Link.NET) 6713 603 701 28 Office National des Postes et 8452 522 958 13 TE-AS 24835 303 144 9 Vodafone Data 36992 284 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29571 218 22 18 Cote d'Ivoire Telecom 37054 215 23 11 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3633 1947 96 NET Servi?os de Comunica??o S 6389 3009 3688 53 BellSouth.net Inc. 4766 2972 11582 896 Korea Telecom 10620 2804 449 192 Telmex Colombia S.A. 17974 2776 903 78 PT Telekomunikasi Indonesia 22773 2410 2938 140 Cox Communications Inc. 7545 2229 320 118 TPG Telecom Limited 1785 2193 696 130 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1917 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3009 2956 BellSouth.net Inc. 17974 2776 2698 PT Telekomunikasi Indonesia 10620 2804 2612 Telmex Colombia S.A. 22773 2410 2270 Cox Communications Inc. 7545 2229 2111 TPG Telecom Limited 4766 2972 2076 Korea Telecom 1785 2193 2063 PaeTec Communications, Inc. 18881 1917 1896 Global Village Telecom 18566 2048 1870 MegaPath Corporation 8402 1717 1702 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:16 /9:12 /10:30 /11:90 /12:255 /13:478 /14:952 /15:1660 /16:12892 /17:6788 /18:11531 /19:24017 /20:33896 /21:36568 /22:52176 /23:45672 /24:260264 /25:791 /26:883 /27:422 /28:13 /29:20 /30:8 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 6389 1695 3009 BellSouth.net Inc. 22773 1647 2410 Cox Communications Inc. 36998 1599 1637 Sudanese Mobile Telephone (ZA 8402 1394 1717 OJSC "Vimpelcom" 30036 1231 1393 Mediacom Communications Corp 11492 1178 1226 CABLE ONE, INC. 1785 1168 2193 PaeTec Communications, Inc. 6983 1044 1328 ITC^Deltacom 34984 1017 1548 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1011 2:694 3:3 4:15 5:918 6:19 8:722 12:1842 13:4 14:973 15:13 16:3 17:31 18:21 20:35 23:763 24:1728 25:1 27:1769 31:1523 32:40 33:2 34:5 36:127 37:1829 38:944 39:4 40:195 41:3129 42:244 44:18 46:2166 47:18 49:676 50:917 52:12 54:47 55:9 57:29 58:1176 59:601 60:380 61:1529 62:1263 63:1984 64:4354 65:2256 66:4164 67:2046 68:1019 69:3317 70:842 71:452 72:1970 74:2627 75:315 76:404 77:1363 78:1041 79:717 80:1326 81:1143 82:700 83:758 84:742 85:1300 86:435 87:1195 88:520 89:1774 90:149 91:5796 92:668 93:1713 94:2066 95:1514 96:538 97:349 98:1080 99:46 100:50 101:832 103:4516 105:534 106:166 107:576 108:559 109:2036 110:981 111:1285 112:663 113:843 114:876 115:1107 116:1057 117:875 118:1368 119:1333 120:376 121:795 122:1911 123:1296 124:1461 125:1485 128:658 129:318 130:351 131:651 132:359 133:159 134:318 135:74 136:253 137:321 138:351 139:166 140:211 141:359 142:558 143:424 144:500 145:103 146:607 147:434 148:907 149:343 150:161 151:598 152:424 153:219 154:237 155:469 156:336 157:339 158:219 159:880 160:346 161:477 162:1283 163:222 164:680 165:616 166:280 167:603 168:1029 169:124 170:1296 171:191 172:23 173:1593 174:684 175:605 176:1476 177:2827 178:1966 179:636 180:1679 181:1039 182:1528 183:514 184:722 185:1441 186:2836 187:1489 188:1875 189:1429 190:7436 191:132 192:7180 193:5473 194:4009 195:3371 196:1377 197:1118 198:4986 199:5633 200:6065 201:2657 202:8967 203:8928 204:4654 205:2703 206:2938 207:2957 208:4004 209:3731 210:3096 211:1699 212:2224 213:2077 214:895 215:85 216:5514 217:1686 218:587 219:320 220:1282 221:594 222:352 223:606 End of report From juliao at braga.eti.br Fri Mar 28 15:08:31 2014 From: juliao at braga.eti.br (Juliao Braga) Date: Fri, 28 Mar 2014 12:08:31 -0300 Subject: 2nd. Call for Papers and Participation - I Workshop pre-IETF (Side Event to CSBC 2014) Message-ID: <5335906F.4030509@braga.eti.br> From blake at ispn.net Fri Mar 28 18:48:43 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 28 Mar 2014 13:48:43 -0500 Subject: Access Lists for Subscriber facing ports? In-Reply-To: References: Message-ID: <5335C40B.9070207@ispn.net> Shawn L wrote the following on 3/27/2014 7:44 AM: > With all of the new worms / denial of service / exploits, etc. that are > coming out, I'm wondering what others are using for access-lists on > residential subscriber-facing ports. > > We've always taken the stance of 'allow unless there is a compelling reason > not to', but with everything that is coming out lately, I'm not sure that's > the correct position any more. > > thanks By default on all devices and customers we enforce BCP 38 as close to the subscriber as possible (as well as any other L2/L3 abuse mitigation techniques that the equipment supports well), and possibly again at the network border. On residential accounts we only consider blocking TCP/UDP ports < 1024 and even then that typically means blocking just SMB (135-139, 445). With SMB blocking becoming a largely irrelevent need given the move to more secure Windows versions, OS firewalls, and firewall enabled CPEs. In the context of an ISP, I very strongly believe in a policy of non-blocking and neutrality. If there's an issue with telco provided CPE that is running services accessible via the WAN (DNS, Telnet, etc), that's an issue best addressed at the CPE level, although temproary ACLs could be applied upstream. If a customer is running their own vulnerable equipment, we may try to notify him or her, but if it does not impact service to other subscribers then we won't go through too many hoops to educate them. --Blake From chip at 2bithacker.net Fri Mar 28 19:42:12 2014 From: chip at 2bithacker.net (Chip Marshall) Date: Fri, 28 Mar 2014 15:42:12 -0400 Subject: 3356 leaking routes out 3549 lately? In-Reply-To: References: Message-ID: <20140328194212.GB43550@2bithacker.net> On 2014-03-28, David Hubbard sent: > Has anyone had issues with Level 3 leaking advertisements out their > Global Crossing AS3356 for customers of 3549, but not accepting the > traffic back? We've been encountering this more and more recently, > bgpmon always detects it, and all we ever get from them is there's > nothing wrong. Today it affected CloudFlare's ability to talk to us. > It seems to happen mostly with Europe and Asian peering points. > Typically lasts five to ten minutes which makes me think someone working > on merging the two networks is doing some 'no one will notice this' > changes in the middle of the night. I'm not sure if it's the same thing, but I've had a few alerts from Renesys lately seeing a path to my AS via GLBX 3549 that shouldn't exist, as we only have connections with Level 3 3356. For example, Renesys reports "x 3549 33517" where it should only be able to see "x 3356 33517" or maybe "x 3549 3356 33517". (Due to Renesys policy, I can't know what x is) -- Chip Marshall http://2bithacker.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From dougb at dougbarton.us Fri Mar 28 20:01:17 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 28 Mar 2014 13:01:17 -0700 Subject: arin representation In-Reply-To: References: <8581605B-9860-463A-A3E6-1073B17D1DF7@arin.net> <9578293AE169674F9A048B2BC9A081B4B5421B35@MUNPRDMBXA1.medline.com> <246F3F8A-3034-4F0A-B7E5-6DF22656CAFB@arin.net> Message-ID: <5335D50D.9080802@dougbarton.us> On 3/24/2014 9:03 PM, Owen DeLong wrote: > [0] As a member of the nominating committee in question, I will disagree with > your claim that our declining to nominate you constitutes rigging the election. > While I can?t disclose the details due to NDA restrictions on the NomCom, > I will say that in my experience having served on the NomCom several times, > they consider each potential nominee and do not take their duties lightly. There is a simple way to solve this problem and indemnify the nomcom against all further such claims. Let anyone volunteer for a spot on the ballot. Let the membership decide who should be elected. Doug From surfer at mauigateway.com Fri Mar 28 20:11:36 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 28 Mar 2014 13:11:36 -0700 Subject: Cisco Security Advisory Message-ID: <20140328131136.BE8B4580@m0048139.ppops.net> On 3/27/2014 7:44 PM, Alexander Neilson wrote: > I wonder if they should be invited to only post a single message with > the titles and links to the alerts so that people can follow it up. ---------------------------------------------------------- If a person is on multiple of *NOG mailing lists a lot of these're received. For example, I got well over 30 of them this round. It'd be nice to get something brief like this: ---------------------------------------------- The Semiannual Cisco IOS Software Security Advisory has been released. For information please goto this URL: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html Advisory titles: - Session Initiation Protocol Denial of Service Vulnerability - Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks Denial of Service Vulnerability - Internet Key Exchange Version 2 Denial of Service Vulnerability - Network Address Translation Vulnerabilities - SSL VPN Denial of Service Vulnerability - Crafted IPv6 Packet Denial of Service Vulnerability ----------------------------------------------- Not everyone uses cisco and not everyone needs to see every vulnerability detail email multiple times. Imagine if all vendors started doing what cisco is doing. :-( scott From jared at puck.nether.net Fri Mar 28 20:29:17 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 28 Mar 2014 16:29:17 -0400 Subject: arin representation In-Reply-To: <965c5c80351802153e9cbed38e5e0d2f.squirrel@66.201.44.180> References: <965c5c80351802153e9cbed38e5e0d2f.squirrel@66.201.44.180> Message-ID: <57CC7A0E-E988-4971-8BCE-845D533E9BDD@puck.nether.net> On Mar 25, 2014, at 12:53 PM, Bob Evans wrote: > Like every governing body, it's easy to criticize it. However, if it were > some big monopoly with giant hidden agendas accomplished behind closed > doors, I wouldn't see networks like Verizon disappointed at an ARIN > meeting as their perspective was being over ruled by the majority. I have > seen this at a meeting when Verizon decided to go purchase IPv4 space in > the marketplace as they could not obtain what they tried to justify. It > would have been a huge chunk of what remained. The IPv4 marketplace grew > even more that week. > > I like term limits for every governing body - except when it's a company I > built with my money. :-) I've seen term limits significantly harm organizations due to the churn that can happen as a result. Folks aren't as invested long-term as a consequence. This can clearly cut both ways resulting in some positions being protected longer than they should, or allowing the entire "vote the bums out" crowd to cause unstable behavior afterwards. I believe there are things that ARIN could do better but don't have the time to invest in the process to correct these. I do take time to lobby those who I know that are involved in the process and express my opinion of the ways that ARIN could do a better service for the community. - Jared From jared at puck.nether.net Fri Mar 28 20:31:46 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 28 Mar 2014 16:31:46 -0400 Subject: 3356 leaking routes out 3549 lately? In-Reply-To: <20140328194212.GB43550@2bithacker.net> References: <20140328194212.GB43550@2bithacker.net> Message-ID: On Mar 28, 2014, at 3:42 PM, Chip Marshall wrote: > On 2014-03-28, David Hubbard sent: >> Has anyone had issues with Level 3 leaking advertisements out their >> Global Crossing AS3356 for customers of 3549, but not accepting the >> traffic back? We've been encountering this more and more recently, >> bgpmon always detects it, and all we ever get from them is there's >> nothing wrong. Today it affected CloudFlare's ability to talk to us. >> It seems to happen mostly with Europe and Asian peering points. >> Typically lasts five to ten minutes which makes me think someone working >> on merging the two networks is doing some 'no one will notice this' >> changes in the middle of the night. > > I'm not sure if it's the same thing, but I've had a few alerts > from Renesys lately seeing a path to my AS via GLBX 3549 that > shouldn't exist, as we only have connections with Level 3 3356. > > For example, Renesys reports "x 3549 33517" where it should only > be able to see "x 3356 33517" or maybe "x 3549 3356 33517". > > (Due to Renesys policy, I can't know what x is) It's been a few years i think now since the "level-crossing" merger so I'm certainly not surprised to see them doing work on this front. This often happens during integration work, and networks of that scale I would imagine tools that detect routing leaks need to account for this merger activity. I can see I need to update my tools :) http://puck.nether.net/bgp/leakinfo.cgi?search=do&search_prefix=&search_aspath=3549_3356&search_asn=&recent=1000 http://puck.nether.net/bgp/leakinfo.cgi?search=do&search_prefix=&search_aspath=3356_3549&search_asn=&recent=1000 From bzs at world.std.com Fri Mar 28 21:15:25 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 28 Mar 2014 17:15:25 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> Message-ID: <21301.58989.363630.385662@world.std.com> On March 28, 2014 at 00:06 owen at delong.com (Owen DeLong) wrote: > > Advertising is a valuable commodity. Free advertising is particularly > > valuable, ROI with I close to zero. > > But it?s only free if you send it to yourself and then approve it. Any message you send to someone else who doesn?t want it isn?t free. I thought the suggestion was that a recipient (email, or by analogy postal) could indicate they wanted an email which would cancel the postage attached, that is, no charge to sender if they wanted it. So if a spammer or junk mailer could, say, trick you into accepting mail in those schemes then they get free advertising, no postage anyhow. We're getting lost in the metaphors methinks. > > > So offering to not charge you because you wanted that mail makes no > > sense, right? > > But this isn?t a charge for the post office and by the time you?re connected to the internet, the cost of receiving the mail and transporting it and the sender sending it is pretty much sunk by some arguments. FIRST: There's a typo/thinko in my sentence! Should be: So offering to not charge THE SENDER because THE RECIPIENT wanted that mail makes no sense, right? SECOND: In response, someone has to scale resources to match volume. But maybe my typo/thinko confused this because you know that, sorry. > > This is an effort to provide a financial disincentive for spamming. Did I say that or you? I agree! Possibly with myself. Which judging by my just previous comments is not always a given. > > If you want to attach e-postage you have to go get some and that can > > be a contract which says you don't do that, if you have multiple > > accounts you split it among your accounts or buy more. And if you do > > what you describe you understand that it is criminal fraud. Click > > Agree [ ] before proceeding, or similar. > > Because spammers are all on the up and up and never commit fraud in order to send their SPAM, right? I'm trying to create an economics around enforcement. But it's helpful to convince the relatively honest public that what you describe is a serious crime tantamount to counterfeiting. And we don't want to be in a situation like we were in 1996 where we were debating whether Spam is even a crime. Enforcement is your usual avoidance, detection, recovery, sort of affair. But there has to be an economics pushing it or it gets mostly ignored (except for people complaining about spam.) Compare and contrast for example spamming vs RIAA style enforcement of copyright violations. Spamming? The occasional shutdown of a botnet tho those may be more motivated by DDoS and phishing. Copyright? Megaupload, wham, Bit torrents, wham, site takedowns, RIAA lawsuits, wham wham wham. Lawyers, guns, and money. What's the difference? Clear monied interests in the latter. > > >>> Who can't operate with 1M msgs/day? > >>> > >>> Well, maybe Amazon or similar. > >>> > >>> But as I said earlier MAYBE THEY SHOULD PAY ALSO! > >> > >> I, for one, don?t want my Amazon prices increased by a pseudo-tax on the fact that they do a large volume of email communications with their customers. They have enough problems trying to get IPv6 deployed without adding this to their list of problems. > > > > That assumes that spam is free for them, and you. Including "free" as > > in "stealing your time?. > > No, it assumes that most of the messages I get from Amazon are NOT SPAM. And I'm arguing we need to change our attitudes on this. This whole idea that because the recipient wants it it isn't "spam" is wearing thin. Just like my analogy with the post office, they wouldn't deliver mail for free just because the recipient wanted it. It's a fundamentally broken idea and spam is its bastard offspring. > The vast majority of messages I get from Amazon are order confirmations, shipping status reports, etc. Messages related to transactions I have conducted with them. Yes, I get a little bit of SPAM from them and I wouldn?t mind seeing them forced to pay me for those messages, but I certainly don?t want to see them paying for every message they send. The vast majority of paper mail I get from my bank accounts is useful and informative and often legally important. But every one of them has postage attached. But maybe there could be some way to reverse charges like you can with fedex and similar. When you sign up with Amazon et al you also enter your (free) e-postage cert (whatever, some cookie) giving them permission to charge against it for some list of mutually agreeable emailings like order confirms and maybe even marketing materials. There are some implementation details involved but it doesn't strike me as a crazy idea. > > >>> We really need to get over the moral component of spam content (and > >>> senders' intentions) and see it for what it is: A free ride anyone > >>> would take if available. > >> > >> I disagree. I see it as a form of theft of service that only immoral thieves would take if available. > > > > How can it be a theft of service if we're not charging anything? > > I didn?t authorize the spammer to use my computer, systems, disk, network, etc. They simply did so without my authorization. If I had a cost effective way to identify them, track them down, and hold them accountable for this, I would gladly do so. Do you mean sending (making you a bot) or receiving spam? I'm saying the notion of who you did authorize to send you email is getting fuzzier and fuzzier and may no longer be a completely useful distinction. That should have been predictable. Create a fuzzy hurtle and it will get hurtled. Accept that "it's not spam if I have a business relationship with the sender" and that "business relationship" definition will get stretched. For example, Buy an auto insurance policy from Liberty Mutual and you just gave permission for every Liberty Mutual insurance agent in the world to hawk you life insurance, home owner's insurance, etc etc etc. over email. I don't think merely tightening the definition fixes that. Money talks, bull**** walks. The main reason dump trucks filled with paper mail don't back up to your house every morning is because that would cost the SENDERs too much real money, so they have to focus and target. But email? That's free, for all practical purposes. > > Well, if they use others' resources it's a theft of those resources, > > such as botnets, is that what you mean? > > Botnets, my mail server, my disk storage, my network, etc. where my mail is processed? All of the above. > > > But by morality I mean that we tend to define spam in terms of > > generally agreed to be undesirable email content such as questionable > > herbal cures or other apparent fraud or near-fraud -- I dunno, maybe > > someone hiring a spammer really believes their herbal hair re-growth > > tonic works. > > I define SPAM not in terms of content, but in the nature of the relationship between the sender and the recipient. If the recipient has no relationship with the sender and doesn?t want to receive the sender?s message, then in most cases, it?s SPAM. Yeah, well, if you ever get an unexpected email (truly) from Bank of America for example offering great CD rates and can't imagine why they sent it have a ball calling the FTC and filing a CAN-SPAM violation. Maybe something would happen, I can't say for sure. But I suspect they'd round file it because hey that's BANK OF AMERICA not SPAMMERS and you're just a KOOK! Extrapolate to any company the FTC has heard of and respects. That's what I mean by a moralistic component. But if BoA was fudging their postal meters and the post office noticed it'd be Book 'Em Dan-O before the next commercial break. > > > I assert that the line is getting fuzzier all the time. > > Yep. If you try to define it on content, the fuzz grows out of control. > > > Even if the product is completely legitimate and maybe there's some > > business relationship someone can draw it doesn't mean I like being > > pummeled with hundreds of ads per day (some of that is projection, > > remember.) > > If you ask the sender to stop and they don?t, then their further messages are SPAM. In theory. Ever try to enforce that if you got a subsequent email? Particularly against a well known company? No. Because no one has even tried (oh there must be one I suppose.) > If you can?t find the sender in order to ask them to stop, then their messages are fraudulent SPAM. I've read CAN-SPAM. > > > But, just as importantly, the people who want to send me an ad would > > like to see me pummeled with less junk so maybe I pay attention to > > their ad or communication. > > The spammers would like to see you pummeled with less ?junk? so you can pay attention to their ad, too. Difference is in your definition of ?junk? vs. their definition of ?junk?. Well, the difference I'm advocating is that Amazon (e.g.) can pay real do-re-mi for postage, the spammers can't. Beyond that I don't really need a definition of "spam" per se, at least that's what's hoped. We the people just have to make sure that anyone sending me an email follows the e-postage rules. No spammer can afford to pay even minimal e-postage. The best they can hope for is to fraud any e-postage system. Viola, it removes the moral judgement component of whether or not I really wanted this email. Or reduces the issue probably into the noise. (some elision...) > >> > >> So you?ve got a set of thieves who are stealing services to send vast volumes of email and you want to solve that problem by charging them more for those services that they are stealing (and, by the way, also charging some legitimate users as well). > >> > >> My guess is that the spammers are going to keep stealing and the people now being taxed for something that used to be free are going to object. > > > > I think you're skipping the point about how they'd have to > > successfully attach e-postage to every piece of email they sent from > > your system. > > Why would you assume that once they bot a system, they would be unable to steal the e-postage from said system? I think we can make that too difficult. But at least we'd have a trail in that case, like when the user's e-postage meter runs out and they can't send any more email this month and might pursue that if unexpected. > > > > > So it's not the resources, it's the authorization which we're trying > > to control. > > > > Right now every piece of email they send from your botted system is > > the same as any email you'd send. > > I?m not really seeing how this would make a difference in that. Make it difficult to use your e-postage meter even if they get some (virus) software on to your system. For example, maybe you have to enter a passphrase to enable the e-postage meter with an idle-timeout, or any similar method, we've all seen many. Heck you could use a USB or similar dongle which has to be plugged in to send email. Sure, people would leave them in, until their e-postage meter was run out unexpectedly and they can't send any more email for the rest of the month, or actually would have to buy further allocation for real $$$. > > > > > If there were some sort of e-postage system with some basic security > > and tracking that becomes much more difficult for the spammer. > > Given how most bots become bots, I tend to doubt it. They just have to > keystroke log your MUA in a two-step process instead of the one-step > process of days of yore. > > Further, since they?re sending lots and lots of the same spam with identical > envelope contents and the only differences are in the SMTP exchange, not the > internal contents of the envelope, a replay attack against the same postage > would seem pretty trivial. But now it's running down your e-postage meter. And it's positively id'd on the receiving end, it has your e-postage meter id on it. It does add a lot of hoops to jump through and evade. > > > > > Or they can use your system to send out a million msgs with no > > e-postage which, one hopes, will be rejected by receiving systems > > without delivery, much like fraudulent DKIM or SPF credentials. > > > > Which, one hopes, won't be profitable for them any more. > > > >> > >>> P.S. And in my vision accepting only email with valid e-postage would > >>> be voluntary though I suppose that might be "voluntary" at the > >>> provider level. For example someone like gmail at some point (of > >>> successful implementation of this scheme) might decide to just block > >>> invalid e-postage because hey your gmail acct is free! Let someone > >>> else sell you rules you prefer like controlling acceptance of invalid > >>> e-postage yourself. > >> > >> Well, here we get a hint at how you envision this working. There are lots of details that need to be solved in the implementation of such a scheme and I think the devil is prevalent among them. > > > > I agree, but I hope my efforts indicate it's not entirely half-baked > > or off the cuff. > > Intrigued, but not convinced. That's progress! And I thank you! Many in this community hear the word "e-postage" and just mentally shut down. > > Owen > -- -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 cidr-report at potaroo.net Fri Mar 28 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Mar 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201403282200.s2SM00xn067913@wattle.apnic.net> This report has been generated at Fri Mar 28 21:13:59 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-03-14 494294 278866 22-03-14 495055 279654 23-03-14 495459 279808 24-03-14 495254 277341 25-03-14 492381 277631 26-03-14 492485 277939 27-03-14 492416 277972 28-03-14 492834 278168 AS Summary 46632 Number of ASes in routing system 19077 Number of ASes announcing only one prefix 3626 Largest number of prefixes announced by an AS AS28573: 119829504 Largest address span announced by an AS (/32s) AS4134 : 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'). --- 28Mar14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 493014 278159 214855 43.6% All ASes AS6389 3008 56 2952 98.1% AS28573 3626 797 2829 78.0% AS17974 2777 160 2617 94.2% AS4766 2972 905 2067 69.5% AS18881 1917 35 1882 98.2% AS1785 2194 370 1824 83.1% AS18566 2048 565 1483 72.4% AS36998 1637 175 1462 89.3% AS4323 2943 1520 1423 48.4% AS10620 2804 1478 1326 47.3% AS7303 1750 456 1294 73.9% AS4755 1843 615 1228 66.6% AS7545 2233 1092 1141 51.1% AS7552 1229 121 1108 90.2% AS22561 1304 247 1057 81.1% AS6983 1328 315 1013 76.3% AS22773 2413 1449 964 40.0% AS4808 1359 425 934 68.7% AS9829 1621 716 905 55.8% AS24560 1123 297 826 73.6% AS18101 918 163 755 82.2% AS7738 912 161 751 82.3% AS8151 1405 654 751 53.5% AS701 1484 755 729 49.1% AS855 759 56 703 92.6% AS4788 1000 306 694 69.4% AS6147 784 113 671 85.6% AS4780 1030 366 664 64.5% AS9808 967 317 650 67.2% AS8551 966 321 645 66.8% Total 52354 15006 37348 71.3% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 41.78.120.0/23 AS22351 41.78.236.0/24 AS37290 41.78.237.0/24 AS37290 41.78.238.0/24 AS37290 41.78.239.0/24 AS37290 41.190.72.0/23 AS37451 41.190.74.0/23 AS37451 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 62.61.221.0/24 AS24974 63.247.0.0/19 AS226 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 64.185.225.0/24 AS27431 64.185.226.0/24 AS27431 64.185.227.0/24 AS27431 64.185.228.0/24 AS27431 64.185.229.0/24 AS27431 64.185.230.0/24 AS27431 64.185.231.0/24 AS27431 64.185.232.0/24 AS27431 64.185.233.0/24 AS27431 64.185.234.0/24 AS27431 64.185.235.0/24 AS27431 64.185.236.0/24 AS27431 64.185.237.0/24 AS27431 64.185.238.0/24 AS27431 64.185.239.0/24 AS27431 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 65.75.217.0/24 AS10494 65.111.1.0/24 AS32258 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 66.187.240.0/20 AS14552 66.205.224.0/19 AS16526 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 66.251.133.0/24 AS33227 66.251.134.0/24 AS33227 66.251.136.0/21 AS33227 66.251.140.0/24 AS33227 66.251.141.0/24 AS33227 66.251.142.0/24 AS33227 66.254.188.0/22 AS3356 67.21.144.0/22 AS174 67.21.148.0/22 AS174 71.19.134.0/23 AS3313 72.19.0.0/19 AS16526 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 74.118.132.0/22 AS5117 74.121.24.0/22 AS36263 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 91.195.66.0/23 AS3356 91.197.36.0/22 AS43359 91.199.185.0/24 AS29076 91.209.115.0/24 AS31103 91.214.65.0/24 AS30822 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 91.239.157.0/24 AS24958 93.190.10.0/24 AS47254 95.215.140.0/22 AS48949 102.2.88.0/22 AS38456 103.23.36.0/22 AS17557 103.31.236.0/22 AS17941 103.244.236.0/22 AS58794 110.232.188.0/22 AS17557 116.206.72.0/24 AS6461 116.206.85.0/24 AS6461 116.206.103.0/24 AS6461 117.120.56.0/21 AS4755 121.46.0.0/16 AS4134 124.64.0.0/10 AS4847 163.47.23.0/24 AS2907 166.93.0.0/16 AS23537 172.85.0.0/24 AS29571 172.85.1.0/24 AS29571 172.85.2.0/24 AS29571 172.85.3.0/24 AS29571 172.86.0.0/24 AS29571 172.86.1.0/24 AS29571 172.86.2.0/24 AS29571 172.87.0.0/24 AS29571 172.88.0.0/24 AS29571 172.102.0.0/22 AS4812 172.116.0.0/24 AS7018 176.111.168.0/22 AS50586 190.3.160.0/21 AS27975 190.107.238.0/24 AS27765 190.124.252.0/22 AS7303 192.9.0.0/16 AS11479 192.25.10.0/24 AS5714 192.25.11.0/24 AS5714 192.25.13.0/24 AS5714 192.25.14.0/24 AS5714 192.75.23.0/24 AS2579 192.75.239.0/24 AS23498 192.84.24.0/24 AS4323 192.101.70.0/24 AS701 192.101.71.0/24 AS701 192.101.72.0/24 AS702 192.104.61.0/24 AS1785 192.124.252.0/22 AS680 192.131.233.0/24 AS7018 192.149.81.0/24 AS14454 192.154.32.0/19 AS81 192.154.64.0/19 AS81 192.166.32.0/20 AS702 192.188.208.0/20 AS721 192.241.20.0/24 AS7381 192.241.21.0/24 AS7381 192.252.252.0/24 AS7018 193.9.59.0/24 AS1257 193.16.145.0/24 AS31392 193.22.86.0/24 AS24751 193.22.224.0/20 AS3322 193.22.238.0/23 AS62383 193.26.213.0/24 AS31641 193.28.14.0/24 AS34309 193.33.6.0/23 AS3356 193.33.106.0/23 AS42444 193.33.252.0/23 AS3356 193.36.229.0/24 AS15404 193.46.200.0/24 AS34243 193.84.187.0/24 AS16276 193.109.217.0/24 AS13069 193.111.229.0/24 AS3356 193.142.249.0/24 AS12389 193.149.2.0/23 AS15919 193.164.152.0/24 AS3356 193.178.196.0/22 AS15657 193.186.193.0/24 AS158 193.186.199.0/24 AS8437 193.188.252.0/24 AS8697 193.200.244.0/24 AS3356 193.201.244.0/24 AS702 193.201.245.0/24 AS702 193.201.246.0/24 AS702 193.202.8.0/21 AS6824 193.202.9.0/24 AS6824 193.223.103.0/24 AS3248 193.227.109.0/24 AS3356 193.227.236.0/23 AS3356 193.243.166.0/24 AS44093 194.0.116.0/24 AS21437 194.0.117.0/24 AS21437 194.6.252.0/24 AS21202 194.9.8.0/23 AS2863 194.9.8.0/24 AS2863 194.59.46.0/24 AS9145 194.63.152.0/22 AS3356 194.79.36.0/22 AS3257 194.88.226.0/23 AS3356 194.99.67.0/24 AS9083 194.113.27.0/24 AS12518 194.126.152.0/23 AS3356 194.126.219.0/24 AS34545 194.126.233.0/24 AS31235 194.150.214.0/23 AS30880 194.156.179.0/24 AS3209 194.187.24.0/22 AS8856 194.213.8.0/24 AS42845 195.8.48.0/23 AS3356 195.8.48.0/24 AS3356 195.39.252.0/23 AS29004 195.42.232.0/22 AS15657 195.47.242.0/24 AS9050 195.69.100.0/24 AS29174 195.69.101.0/24 AS29174 195.69.102.0/24 AS29174 195.69.103.0/24 AS29174 195.85.194.0/24 AS3356 195.85.201.0/24 AS3356 195.90.98.0/23 AS57511 195.110.0.0/23 AS3356 195.128.240.0/23 AS21202 195.149.119.0/24 AS3356 195.189.174.0/23 AS3356 195.216.234.0/24 AS31309 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 195.244.18.0/23 AS3356 196.2.224.0/22 AS24863 196.3.182.0/24 AS37004 196.3.183.0/24 AS37004 196.13.201.0/24 AS2018 196.13.202.0/24 AS2018 196.13.203.0/24 AS2018 196.13.204.0/24 AS2018 196.22.8.0/24 AS27822 196.22.11.0/24 AS16422 196.45.0.0/21 AS26625 196.45.10.0/24 AS26625 196.216.129.0/24 AS36886 196.216.130.0/24 AS36886 196.216.131.0/24 AS36886 198.23.26.0/24 AS4390 198.72.78.0/23 AS3967 198.74.11.0/24 AS14573 198.74.13.0/24 AS14573 198.74.38.0/24 AS16966 198.74.39.0/24 AS16966 198.74.40.0/24 AS16966 198.97.72.0/21 AS721 198.97.96.0/19 AS721 198.97.192.0/20 AS721 198.97.240.0/20 AS721 198.161.239.0/24 AS852 198.163.214.0/24 AS21804 198.163.215.0/24 AS6327 198.163.216.0/24 AS6327 198.168.0.0/16 AS701 198.176.208.0/24 AS4318 198.176.209.0/24 AS4318 198.176.210.0/24 AS4318 198.176.211.0/24 AS4318 198.180.198.0/24 AS23715 198.252.165.0/24 AS20115 198.252.166.0/24 AS20115 198.252.167.0/24 AS20115 198.252.168.0/24 AS20115 198.252.169.0/24 AS20115 199.30.138.0/24 AS23319 199.30.139.0/24 AS23319 199.30.143.0/24 AS8100 199.68.72.0/24 AS174 199.85.9.0/24 AS852 199.88.52.0/22 AS17018 199.91.240.0/21 AS174 199.116.200.0/21 AS22830 199.120.150.0/24 AS30036 199.121.0.0/16 AS721 199.123.16.0/20 AS721 199.188.28.0/22 AS46802 200.1.112.0/24 AS29754 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 202.53.138.0/24 AS4058 202.58.113.0/24 AS19161 202.94.1.0/24 AS4808 202.158.251.0/24 AS9255 202.174.125.0/24 AS9498 203.0.0.0/16 AS7545 203.83.16.0/21 AS17828 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 204.10.88.0/21 AS3356 204.10.94.0/23 AS30097 204.15.208.0/22 AS13706 204.16.96.0/24 AS19972 204.16.97.0/24 AS19972 204.16.98.0/24 AS19972 204.16.99.0/24 AS19972 204.69.144.0/24 AS27283 204.106.16.0/24 AS4323 204.187.11.0/24 AS51113 204.225.173.0/24 AS6407 205.159.44.0/24 AS40157 205.207.66.0/24 AS15290 205.211.160.0/24 AS30045 206.81.112.0/20 AS32618 206.197.184.0/24 AS23304 206.221.176.0/24 AS27431 206.221.177.0/24 AS27431 206.221.178.0/24 AS27431 206.221.179.0/24 AS27431 206.221.180.0/24 AS27431 206.221.181.0/24 AS27431 206.221.182.0/24 AS27431 206.221.183.0/24 AS27431 206.221.184.0/24 AS27431 206.221.185.0/24 AS27431 206.221.186.0/24 AS27431 206.221.187.0/24 AS27431 206.221.188.0/24 AS27431 206.221.189.0/24 AS27431 206.221.190.0/24 AS27431 206.221.191.0/24 AS27431 207.2.120.0/21 AS6221 207.174.131.0/24 AS26116 207.174.132.0/23 AS26116 207.174.152.0/23 AS26116 207.174.154.0/24 AS26116 207.174.155.0/24 AS26116 207.174.200.0/24 AS22658 207.231.96.0/19 AS11194 207.254.128.0/21 AS30689 207.254.128.0/24 AS30689 207.254.136.0/21 AS30689 208.67.132.0/22 AS701 208.68.180.0/22 AS4323 208.69.192.0/23 AS6461 208.69.195.0/24 AS6461 208.74.224.0/22 AS174 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.166.0/24 AS4323 208.83.53.0/24 AS40569 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 208.85.212.0/22 AS32618 208.89.32.0/24 AS27431 208.89.33.0/24 AS27431 208.89.34.0/24 AS27431 208.89.35.0/24 AS27431 208.91.164.0/22 AS46099 209.177.64.0/20 AS6461 209.193.112.0/20 AS209 209.209.51.0/24 AS18687 209.212.63.0/24 AS16467 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 216.152.24.0/22 AS22773 216.170.96.0/24 AS4565 216.170.101.0/24 AS4565 216.170.104.0/24 AS4565 216.170.105.0/24 AS4565 216.203.80.0/20 AS27021 216.203.80.0/21 AS27021 216.203.87.0/24 AS27021 216.203.88.0/21 AS27021 216.203.95.0/24 AS53490 216.234.132.0/24 AS14545 Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 28 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Mar 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201403282200.s2SM028J067922@wattle.apnic.net> BGP Update Report Interval: 20-Mar-14 -to- 27-Mar-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4837 41011 1.4% 60.8 -- CHINA169-BACKBONE CNCGROUP China169 Backbone 2 - AS8402 35505 1.2% 18.7 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 35504 1.2% 22.6 -- BSNL-NIB National Internet Backbone 4 - AS29571 31812 1.1% 170.1 -- CITelecom-AS 5 - AS25184 28844 1.0% 225.3 -- AFRANET AFRANET Co. Tehran, Iran 6 - AS45169 24876 0.9% 1658.4 -- GLOBAL-DESCON-AS-AP Descon Limited 7 - AS28573 24765 0.9% 6.7 -- NET Servi?os de Comunica??o S.A. 8 - AS13118 22468 0.8% 488.4 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS41691 20828 0.7% 867.8 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - AS7552 20276 0.7% 17.6 -- VIETEL-AS-AP Viettel Corporation 11 - AS50710 19542 0.7% 86.9 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 12 - AS36998 18568 0.6% 11.3 -- SDN-MOBITEL 13 - AS8151 18305 0.6% 13.0 -- Uninet S.A. de C.V. 14 - AS35819 18279 0.6% 36.0 -- MOBILY-AS Etihad Etisalat Company (Mobily) 15 - AS17974 18025 0.6% 6.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS48159 16354 0.6% 89.9 -- TIC-AS Telecommunication Infrastructure Company 17 - AS4538 16280 0.6% 30.4 -- ERX-CERNET-BKB China Education and Research Network Center 18 - AS17557 15697 0.5% 130.8 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 19 - AS9808 15203 0.5% 15.7 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 20 - AS45899 14515 0.5% 39.3 -- VNPT-AS-VN VNPT Corp TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS20450 14151 0.5% 7075.5 -- THL16-ASN - Trojan Hosting, LLC. 2 - AS54465 8022 0.3% 2674.0 -- QPM-AS-1 - QuickPlay Media Inc. 3 - AS45169 24876 0.9% 1658.4 -- GLOBAL-DESCON-AS-AP Descon Limited 4 - AS60345 995 0.0% 995.0 -- NBITI-AS Nahjol Balagheh International Research Institution 5 - AS41691 20828 0.7% 867.8 -- SUMTEL-AS-RIPE Summa Telecom LLC 6 - AS14340 10962 0.4% 783.0 -- SALESFORCE - Salesforce.com, Inc. 7 - AS47714 750 0.0% 750.0 -- DRIESSEN-AS Driessen Aerospace Group NV 8 - AS55746 637 0.0% 637.0 -- WITT-AS-AP Western Institute of Technology at Taranaki, 9 - AS16561 3008 0.1% 501.3 -- ARIBANETWORK Ariba Inc. Autonomous System 10 - AS13118 22468 0.8% 488.4 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS11054 11226 0.4% 488.1 -- LIVEPERSON LivePerson, Inc 12 - AS57201 481 0.0% 481.0 -- EDF-AS Estonian Defence Forces 13 - AS47918 934 0.0% 467.0 -- GIGABASE Gigabase ltd 14 - AS22688 897 0.0% 448.5 -- DOLGENCORP - Dollar General Corporation 15 - AS3 441 0.0% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology 16 - AS27828 6947 0.2% 434.2 -- Universidad Mayor de San Andres 17 - AS35463 850 0.0% 425.0 -- PSM-AS Pulawska Spoldzielnia Mieszkaniowa 18 - AS12131 6528 0.2% 408.0 -- IJ-NET - Internet Junction Corporation 19 - AS62431 403 0.0% 403.0 -- NCSC-IE-AS National Cyber Security Centre 20 - AS45703 767 0.0% 383.5 -- BKPM-AS-ID Badan Koordinasi Penanaman Modal (BKPM) TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22255 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 89.221.206.0/24 20666 0.7% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 3 - 121.52.144.0/24 15121 0.5% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 4 - 192.58.232.0/24 9987 0.3% AS6629 -- NOAA-AS - NOAA 5 - 216.109.107.0/24 9868 0.3% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 6 - 78.109.192.0/20 9246 0.3% AS25184 -- AFRANET AFRANET Co. Tehran, Iran 7 - 66.210.60.0/24 8066 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC. 8 - 206.152.15.0/24 8008 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 9 - 205.247.12.0/24 7498 0.2% AS6459 -- TRANSBEAM - I-2000, Inc. 10 - 42.83.48.0/20 7412 0.2% AS18135 -- BTV BTV Cable television 11 - 199.187.118.0/24 6233 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 12 - 74.231.237.0/24 6085 0.2% AS20450 -- THL16-ASN - Trojan Hosting, LLC. 13 - 200.23.126.0/24 5524 0.2% AS8151 -- Uninet S.A. de C.V. 14 - 96.43.153.0/24 5520 0.2% AS14340 -- SALESFORCE - Salesforce.com, Inc. AS2687 -- ASATTCA AT&T Global Network Services - AP 15 - 96.43.152.0/24 5420 0.2% AS14340 -- SALESFORCE - Salesforce.com, Inc. AS2687 -- ASATTCA AT&T Global Network Services - AP 16 - 120.28.62.0/24 4634 0.1% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 17 - 222.127.0.0/24 4478 0.1% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 18 - 65.90.49.0/24 4135 0.1% AS3356 -- LEVEL3 Level 3 Communications 19 - 210.90.39.0/24 4014 0.1% AS4766 -- KIXS-AS-KR Korea Telecom 20 - 2.93.235.0/24 2949 0.1% AS8402 -- CORBINA-AS OJSC "Vimpelcom" Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From randy at psg.com Fri Mar 28 22:13:48 2014 From: randy at psg.com (Randy Bush) Date: Sat, 29 Mar 2014 07:13:48 +0900 Subject: ARIN board accountability to network operators In-Reply-To: <5335851C.1010102@foobar.org> References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> <9ECE2FC5-0CB9-42A7-BB9E-43B7D0379F1C@steffann.nl> <5335851C.1010102@foobar.org> Message-ID: >> Yeah, RIPE NCC is definitely much cheaper for PI: no initial >> registration fee of ?$500. The maintenance cost is $100/year vs >> ?100/year (?$137) so there is a little difference there. The $37 > ?50 per PI assignment from the ripe ncc, no? > http://www.ripe.net/ripe/docs/ripe-591 guys, you are following an arin policy weenie's red herring. this was not about fees. it was about arin's board being it's own governance review committee and having no term limits, arin forcing folk to sign contracts with clauses saying arin can change the Ts&Cs unilaterally and arbitrarily, ... randy From bill at herrin.us Fri Mar 28 22:16:11 2014 From: bill at herrin.us (William Herrin) Date: Fri, 28 Mar 2014 18:16:11 -0400 Subject: why IPv6 isn't ready for prime time Message-ID: Apropos nothing, I tried to bring up IPv6 with another service provider today (this being the fourth I've attempted with only one success) but all I'm getting is: %BGP-3-NOTIFICATION: sent to neighbor xxxx:xxxx:1000:A000::6 2/7 (unsupported/disjoint capability) 0 bytes :( -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jay+NANOG at tp.org Fri Mar 28 23:51:49 2014 From: jay+NANOG at tp.org (Jay Moran) Date: Fri, 28 Mar 2014 19:51:49 -0400 Subject: ARIN board accountability to network operators In-Reply-To: References: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net> <15167BFF-E3A3-4BAC-8F1A-77827308E51B@delong.com> <4D5D8453-B562-4AA4-B22C-9FF93418E829@steffann.nl> <7AF4D303-E188-417B-BFA3-6A8D799F419F@delong.com> <9ECE2FC5-0CB9-42A7-BB9E-43B7D0379F1C@steffann.nl> <5335851C.1010102@foobar.org> Message-ID: On Fri, Mar 28, 2014 at 6:13 PM, Randy Bush wrote: > ....arin forcing folk to sign > contracts with clauses saying arin can change the Ts&Cs unilaterally and > arbitrarily, ... > Exactly! -- Jay From rdrake at direcpath.com Sat Mar 29 00:20:24 2014 From: rdrake at direcpath.com (Robert Drake) Date: Fri, 28 Mar 2014 20:20:24 -0400 Subject: Cisco Security Advisory In-Reply-To: <20140328131136.BE8B4580@m0048139.ppops.net> References: <20140328131136.BE8B4580@m0048139.ppops.net> Message-ID: <533611C8.9010608@direcpath.com> On 3/28/2014 4:11 PM, Scott Weeks wrote: > If a person is on multiple of *NOG mailing lists a lot of these're > received. For example, I got well over 30 of them this round. It'd be > nice to get something brief like this: > > > ---------------------------------------------- > The Semiannual Cisco IOS Software Security Advisory has been released. > > For information please goto this URL: > http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html > > Advisory titles: > - Session Initiation Protocol Denial of Service Vulnerability > - Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks Denial of Service Vulnerability > - Internet Key Exchange Version 2 Denial of Service Vulnerability > - Network Address Translation Vulnerabilities > - SSL VPN Denial of Service Vulnerability > - Crafted IPv6 Packet Denial of Service Vulnerability > ----------------------------------------------- > > Not everyone uses cisco and not everyone needs to see every vulnerability > detail email multiple times. Imagine if all vendors started doing what > cisco is doing. I hate that it's spam for some and relevant for others, but in the NSP world you can almost be certain that someone is going to have at least some Cisco equipment (even companies who are known to dislike Cisco enough to avoid them religiously have bought other companies who might have Cisco gear) Having the vulnerability in the subject draws attention to the problems and makes people less likely to ignore it. When I see keywords of technologies I'm using, like IPv6 or 6500 I tend to read through carefully to see if I'm vulnerable. Because it can be difficult and time consuming to see if all your gear is vulnerable, If it's a bug in or then I'm not as diligent. I guess I might be selfish because seeing 5 advisories at once is like a giant line break in NANOG discussions, so it's harder to tune it out and skip the emails :) They could Bcc: all the lists they are sending to in one set of emails so the message-id is the same, then you could filter duplicates at least. Or they could do the summary email like you guys want, whichever makes people happy. :) > :-( > > scott > :-( Robert From surfer at mauigateway.com Sat Mar 29 00:34:13 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 28 Mar 2014 17:34:13 -0700 Subject: Cisco Security Advisory Message-ID: <20140328173413.BE8EF9E0@m0005312.ppops.net> --- rdrake at direcpath.com wrote: From: Robert Drake because seeing 5 advisories at once is like a giant line break in NANOG discussions, so it's harder to tune it out and skip the emails :) They could Bcc: all the lists they are sending to in one set of emails so the message-id is the same, then you could filter duplicates at least. Or they could do the summary email like you guys want, whichever makes people happy. :) ------------------------------------------------------------ You got 5 (actually 6 this time) perhaps because you're only on NANOG. I got over 30 this time and once when there were 9 vulnerabilities I got almost 50 emails from cisco. scott From mark.tinka at seacom.mu Sat Mar 29 05:43:43 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 29 Mar 2014 07:43:43 +0200 Subject: Cisco Security Advisory In-Reply-To: <20140328173413.BE8EF9E0@m0005312.ppops.net> References: <20140328173413.BE8EF9E0@m0005312.ppops.net> Message-ID: <201403290743.48889.mark.tinka@seacom.mu> On Saturday, March 29, 2014 02:34:13 AM Scott Weeks wrote: > You got 5 (actually 6 this time) perhaps because you're > only on NANOG. I got over 30 this time and once when > there were 9 vulnerabilities I got almost 50 emails from > cisco. I've always known that Cisco will submit their notices to multiple lists, including their own. So when I see it on one list, I already know to expect it on others. Given how easy they are to "identify", I immediately delete them from other lists which I've decided is not the primary list I want to learn them on. It does help that they stack them up in one batch, so you don't even need to think about it much. But clearly, this is one of those issues where you have a good amount of folk on either side of the fence. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From LarrySheldon at cox.net Sat Mar 29 05:48:48 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 29 Mar 2014 00:48:48 -0500 Subject: Cisco Security Advisory In-Reply-To: References: <20140328173413.BE8EF9E0@m0005312.ppops.net> Message-ID: <53365EC0.60502@cox.net> On 3/29/2014 12:43 AM, Mark Tinka wrote: > But clearly, this is one of those issues where you have a > good amount of folk on either side of the fence. I wonder what the ratio of "I don't want that info here" (for various values of "here") to "Geeeeeez! WHY didn't somebody tell me" is. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From randy at psg.com Sat Mar 29 06:03:36 2014 From: randy at psg.com (Randy Bush) Date: Sat, 29 Mar 2014 15:03:36 +0900 Subject: Cisco Security Advisory In-Reply-To: <201403290743.48889.mark.tinka@seacom.mu> References: <20140328173413.BE8EF9E0@m0005312.ppops.net> <201403290743.48889.mark.tinka@seacom.mu> Message-ID: > But clearly, this is one of those issues where you have a > good amount of folk on either side of the fence. and the discussion is about the size of five years of cisco notices and just as hard to delete welcome to nanog randy From mansaxel at besserwisser.org Sat Mar 29 07:15:08 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 29 Mar 2014 08:15:08 +0100 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> Message-ID: <20140329071508.GJ10032@besserwisser.org> Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Thu, Mar 27, 2014 at 10:32:42AM -0400 Quoting John R. Levine (johnl at iecc.com): > >Ergo, ad hominem. Please quit doing that. > >As a side note I happen to run my own mail server without spam filters > >-- it works for me. I might not be the norm, but then again, is there > >really a norm? (A norm that transcends SMTP RFC reach, that is -- > > I know a lot of people who run a lot of mail systems, and let's just > say you're so far out in the long tail we need a telescope to see > you. I will not debate with people who resort to humiliation techniques when questioned. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I feel like a wet parking meter on Darvon! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From patrick at ianai.net Sat Mar 29 15:06:11 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 29 Mar 2014 11:06:11 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140329071508.GJ10032@besserwisser.org> References: <20140325233557.6311.qmail@joyce.lan> <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> <20140329071508.GJ10032@besserwisser.org> Message-ID: <99E849E6-C7B3-4A92-B02B-018CB7FD484D@ianai.net> Composed on a virtual keyboard, please forgive typos. > On Mar 29, 2014, at 3:15, M?ns Nilsson wrote: > Quoting John R. Levine (johnl at iecc.com): >>> Ergo, ad hominem. Please quit doing that. >>> As a side note I happen to run my own mail server without spam filters >>> -- it works for me. I might not be the norm, but then again, is there >>> really a norm? (A norm that transcends SMTP RFC reach, that is -- >> >> I know a lot of people who run a lot of mail systems, and let's just >> say you're so far out in the long tail we need a telescope to see >> you. > > I will not debate with people who resort to humiliation techniques > when questioned. I will not argue whether you were humiliated as that is something only you can decide. However, John was still factually correct. No big deal, lots of people are humiliated by facts. Although I admit I didn't find the quote above terribly humiliating myself. Also, realize that John has already done more to stop spam in his career then you and your thousand closest friends ever will. (E.g. Look up abuse.net.) Again not humiliation, just a fact. Feel free to plonk me as well. I won't be humiliated. :-) -- TTFN, patrick From owen at delong.com Sat Mar 29 15:28:32 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Mar 2014 08:28:32 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21301.58989.363630.385662@world.std.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> Message-ID: On Mar 28, 2014, at 2:15 PM, Barry Shein wrote: > > On March 28, 2014 at 00:06 owen at delong.com (Owen DeLong) wrote: >>> Advertising is a valuable commodity. Free advertising is particularly >>> valuable, ROI with I close to zero. >> >> But it?s only free if you send it to yourself and then approve it. Any message you send to someone else who doesn?t want it isn?t free. > > I thought the suggestion was that a recipient (email, or by analogy > postal) could indicate they wanted an email which would cancel the > postage attached, that is, no charge to sender if they wanted it. Yes, but you?d have to say ?I wanted this? effectively after receiving and opening the mail, knowing what was inside, not before. > So if a spammer or junk mailer could, say, trick you into accepting > mail in those schemes then they get free advertising, no postage > anyhow. Sure, but how would they trick you into saying ?I wanted this advertising? once you?ve actually seen that it is advertising. > We're getting lost in the metaphors methinks. I don?t think so, I think we?re having differing visions of how it would work in detail. >>> So offering to not charge you because you wanted that mail makes no >>> sense, right? >> >> But this isn?t a charge for the post office and by the time you?re connected to the internet, the cost of receiving the mail and transporting it and the sender sending it is pretty much sunk by some arguments. > > FIRST: There's a typo/thinko in my sentence! > > Should be: > > So offering to not charge THE SENDER because THE RECIPIENT wanted > that mail makes no sense, right? > > SECOND: > > In response, someone has to scale resources to match volume. > > But maybe my typo/thinko confused this because you know that, sorry. Yes, but those costs are essentially already sunk in existing internet access. The cost of transmission is already paid by all parties involved. This wouldn?t be intended to subsidize that. The reason for splitting the postage between the recipient and the recipient ISP was to aid in recovery of the costs of administering the postage process. >> This is an effort to provide a financial disincentive for spamming. > > Did I say that or you? I agree! > > Possibly with myself. Which judging by my just previous comments is > not always a given. I said it, but I?m glad we are in agreement. >>> If you want to attach e-postage you have to go get some and that can >>> be a contract which says you don't do that, if you have multiple >>> accounts you split it among your accounts or buy more. And if you do >>> what you describe you understand that it is criminal fraud. Click >>> Agree [ ] before proceeding, or similar. >> >> Because spammers are all on the up and up and never commit fraud in order to send their SPAM, right? > > I'm trying to create an economics around enforcement. > > But it's helpful to convince the relatively honest public that what > you describe is a serious crime tantamount to counterfeiting. Yes, that would be very helpful. > And we don't want to be in a situation like we were in 1996 where we > were debating whether Spam is even a crime. Sadly, we seem to be in a situation where we have no good legal definition of the crime and where the criminal definition of SPAM has been so badly watered down by regulators as to neuter any attempts to regulate it out of existence or prosecute it criminally. Worse, even if it is a crime in jurisdiction A, it becomes very difficult to prosecute a spammer in jurisdiction B for sending SPAM to a recipient in jurisdiction A. > Enforcement is your usual avoidance, detection, recovery, sort of > affair. But there has to be an economics pushing it or it gets mostly > ignored (except for people complaining about spam.) Yep. > Compare and contrast for example spamming vs RIAA style enforcement of > copyright violations. I would not say that RIAA is the shining example to emulate, but, yes for this particular concept, I think you have the right idea. >> No, it assumes that most of the messages I get from Amazon are NOT SPAM. > > And I'm arguing we need to change our attitudes on this. > > This whole idea that because the recipient wants it it isn't "spam" is > wearing thin. Please present your definition of SPAM. I don?t see how a shipping notification, a transaction receipt, etc. could possibly be considered SPAM. > Just like my analogy with the post office, they wouldn't deliver mail > for free just because the recipient wanted it. That postage is already being paid for email? You pay for internet access and so do the spammers, so the idea that your proposed e-postage is a payment related to the delivery of the mail is absurd from the beginning. >> The vast majority of messages I get from Amazon are order confirmations, shipping status reports, etc. Messages related to transactions I have conducted with them. Yes, I get a little bit of SPAM from them and I wouldn?t mind seeing them forced to pay me for those messages, but I certainly don?t want to see them paying for every message they send. > > The vast majority of paper mail I get from my bank accounts is useful > and informative and often legally important. > > But every one of them has postage attached. Yes, but you aren?t paying the USPS a fee for you to have a mailbox that the mailman drives by whether you receive mail or not and neither is your bank. I certainly don?t want to start double-paying for spam (or legitimate email for that matter). Further, if someone sends me something I don?t want, I can mark it ?refused, return to sender? and the post office is obliged to do so and I don?t pay anything for it. >> I didn?t authorize the spammer to use my computer, systems, disk, network, etc. They simply did so without my authorization. If I had a cost effective way to identify them, track them down, and hold them accountable for this, I would gladly do so. > > Do you mean sending (making you a bot) or receiving spam? Receiving. > I'm saying the notion of who you did authorize to send you email is > getting fuzzier and fuzzier and may no longer be a completely useful > distinction. How so? If I actually signed up with you to receive your mail, then I opted in and you have my permission on record. If I bought something from you, then I signed up to receive emails RELATED TO THAT TRANSACTION and you have that permission on record. If I checked the box to receive other emails from you, then you have that permission on record. If you don?t have my permission on record, then you don?t have my permission. Seems pretty simple and clear and predictable to me. Now, you might be able to get my retroactive permission by paying to ask, and if I agree, your ?permission fee? is refunded. OTOH, if I say ?no?, then you don?t get your money back. > That should have been predictable. Create a fuzzy hurtle and it will > get hurtled. I?m not seeing the fuzziness you claim is present. > Accept that "it's not spam if I have a business relationship with the > sender" and that "business relationship" definition will get > stretched. See above. I have a _MUCH_ narrower definition of what should be accepted. > For example, Buy an auto insurance policy from Liberty Mutual and you > just gave permission for every Liberty Mutual insurance agent in the > world to hawk you life insurance, home owner's insurance, etc etc etc. > over email. No, I didn?t. See above. >> I define SPAM not in terms of content, but in the nature of the relationship between the sender and the recipient. If the recipient has no relationship with the sender and doesn?t want to receive the sender?s message, then in most cases, it?s SPAM. > > Yeah, well, if you ever get an unexpected email (truly) from Bank of > America for example offering great CD rates and can't imagine why they > sent it have a ball calling the FTC and filing a CAN-SPAM violation. If such a thing happened and it actually came from BofA, then, yes, it would. However, BofA is smart enough to keep such SPAMvertising at arms length and you have to track down the spammer that actually sent the email under contract to BofA, not BofA themselves. It would be nice if CAN-SPAM were expanded to affect the advertiser and/or advertised product instead of just the entity actually sending the SPAM, but so far, that has not happened. > > Maybe something would happen, I can't say for sure. > > But I suspect they'd round file it because hey that's BANK OF AMERICA > not SPAMMERS and you're just a KOOK! No, more likely they?d review the headers and point out to me that there?s no evidence it was actually sent BY BofA, because most likely it wasn?t sent by BofA, but by someone they may or may not have contracted. > Extrapolate to any company the FTC has heard of and respects. Really more a matter of how those companies keep their SPAM at arms length and circumvent the intent of the law than their reputation with the FTC. > That's what I mean by a moralistic component. > > But if BoA was fudging their postal meters and the post office noticed > it'd be Book 'Em Dan-O before the next commercial break. Indeed, the mailing agency that BofA hires to send out their postal spam pays full postage and can?t really avoid that. But postage is related to the cost of delivering the mail. What you are proposing as e-postage isn?t. > >> >>> I assert that the line is getting fuzzier all the time. >> >> Yep. If you try to define it on content, the fuzz grows out of control. >> >>> Even if the product is completely legitimate and maybe there's some >>> business relationship someone can draw it doesn't mean I like being >>> pummeled with hundreds of ads per day (some of that is projection, >>> remember.) >> >> If you ask the sender to stop and they don?t, then their further messages are SPAM. > > In theory. > > Ever try to enforce that if you got a subsequent email? > > Particularly against a well known company? > > No. Because no one has even tried (oh there must be one I suppose.) See above. >> If you can?t find the sender in order to ask them to stop, then their messages are fraudulent SPAM. > > I've read CAN-SPAM. I wasn?t specifically talking about CAN-SPAM, but it does include provisions like this, yes. >>> But, just as importantly, the people who want to send me an ad would >>> like to see me pummeled with less junk so maybe I pay attention to >>> their ad or communication. >> >> The spammers would like to see you pummeled with less ?junk? so you can pay attention to their ad, too. Difference is in your definition of ?junk? vs. their definition of ?junk?. > > Well, the difference I'm advocating is that Amazon (e.g.) can pay real > do-re-mi for postage, the spammers can?t. I think you underestimate the available budget for SPAMming. > Beyond that I don't really need a definition of "spam" per se, at > least that's what's hoped. > > We the people just have to make sure that anyone sending me an email > follows the e-postage rules. Now you need to ask, am I going to pay a fee to participate actively in the IETF or the policy development process at ARIN for each and every message I send? > No spammer can afford to pay even minimal e-postage. You are dreaming. > The best they can hope for is to fraud any e-postage system. More than likely they will be able to do so, yes. > Viola, it removes the moral judgement component of whether or not I > really wanted this email. True, but it also creates many negative unintended consequences. > Or reduces the issue probably into the noise. Unlikely to reduce any issue, IMHO. >> Why would you assume that once they bot a system, they would be unable to steal the e-postage from said system? > > I think we can make that too difficult. > > But at least we'd have a trail in that case, like when the user's > e-postage meter runs out and they can't send any more email this month > and might pursue that if unexpected. Not sure how that constitutes a trail so much as an increased workload for the users and their ISPs. Might help reduce the bots, but I tend to doubt it. >>> So it's not the resources, it's the authorization which we're trying >>> to control. >>> >>> Right now every piece of email they send from your botted system is >>> the same as any email you'd send. >> >> I?m not really seeing how this would make a difference in that. > > Make it difficult to use your e-postage meter even if they get some > (virus) software on to your system. > > For example, maybe you have to enter a passphrase to enable the > e-postage meter with an idle-timeout, or any similar method, we've all > seen many. That?s what key loggers are for. You can?t protect a booted system from itself. Dreaming that you can is kind of amusing. > Heck you could use a USB or similar dongle which has to be plugged in > to send email. That might work, but how long before those are compromised? > Sure, people would leave them in, until their e-postage meter was run > out unexpectedly and they can't send any more email for the rest of > the month, or actually would have to buy further allocation for real > $$$. Actually, rolling code dongles that simulate keyboards for authentication codes might be a good choice here? Hit the button each time you need to enter postage. That might actually be a secure solution. But you?re still left with the chilling effect on voluntary participation in governance and other activities through email. > >> >>> >>> If there were some sort of e-postage system with some basic security >>> and tracking that becomes much more difficult for the spammer. >> >> Given how most bots become bots, I tend to doubt it. They just have to >> keystroke log your MUA in a two-step process instead of the one-step >> process of days of yore. >> >> Further, since they?re sending lots and lots of the same spam with identical >> envelope contents and the only differences are in the SMTP exchange, not the >> internal contents of the envelope, a replay attack against the same postage >> would seem pretty trivial. > > But now it's running down your e-postage meter. How so? I?m just replaying the original e-postage. Reusing the same stamp over and over again as it were. > And it's positively id'd on the receiving end, it has your e-postage > meter id on it. Yes, the spammer is able to use one of my stamps a few million times and then what? > It does add a lot of hoops to jump through and evade. Not really, no. > That's progress! > > And I thank you! Many in this community hear the word "e-postage" and > just mentally shut down. Meh? I try to keep an open mind. Owen From mysidia at gmail.com Sat Mar 29 17:59:36 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 29 Mar 2014 12:59:36 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21301.58989.363630.385662@world.std.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> Message-ID: On Fri, Mar 28, 2014 at 4:15 PM, Barry Shein wrote: > On March 28, 2014 at 00:06 owen at delong.com (Owen DeLong) wrote: > [snip] > I thought the suggestion was that a recipient (email, or by analogy > postal) could indicate they wanted an email which would cancel the > postage attached, that is, no charge to sender if they wanted it. > > So if a spammer or junk mailer could, say, trick you into accepting > mail in those schemes then they get free advertising, no postage > anyhow. > *Postage schemes as proposed with end users email clients 'attaching postage' simply not workable Not in IPv4. Not in IPv6. Not in IPng Not in any conceivable future version of IP. *Believe end users being served by mail servers WON'T tolerate postage, or the extra difficulty in configuring their email client, even from a free service. Spam is a serious problem, and different mail users don't agree on exactly what messages are spam, BUT from end users' perspective: they all tend to agree that it is their provider's job to have made all the spam go away, but delivered all goodmail with 100% accuracy. Moreover, mail users expect, this should be 100% transparent, requiring no extra work from the mail user. Confirming that a message was OKAY, or that it was spam is definitely outside the compass of your average mail user. Therefore.... it would almost definitely be e-mail mailbox providers footing the bill on behalf of their subscribers in any 'charge postage' scheme that ever had a reasonable chance of working. Must be completely transparent to end users. Any treatment for spam ultimately needs to have some conceivable way of being implemented to be less harmful and annoying than the disease. Therefore: Must not have any significant burdens for at least 95% of legitimate users, and the burden of the 5% of legitimate users must be low and worth it. Email hosting providers still just have to use the flat rate monthly service fee to recover their costs, AND costs have to be low enough that free mail providers can still work -- supported by advertising : users will revolt against SP, if there are extra charges. Therefore "Postage must be optional". Perhaps, by separating mail into multiple classes, and requiring postage only for certain classes. Such as "Unpostaged Email" --- Extreme spam filtering, likely deliverability issues (what we have today) "Bulk Class Email" --- subject to reduced spam filtering, reduced postage, Only available to authorized SMTP senders. "First class Email" --- Intended for private correspondence, greater postage, reduced spam filtering "Priority Email" --- Intended for extremely urgent messages, high postage, for time sensitive matters very little or no spam filtering. And the process by which SMTP operators could reach agreement to charge each other for traffic, and on what rate should be standard, is difficult to conceive..... Postage would incentivize SMTP operators: to scrutinize users' traffic and limit abuse or excessive mail outflow from any one user. But who could say... that a particularly lucrative spam campaign won't come from the spammer attached with the proper postage? > In theory SMTP providers could do this... exchange postage between SMTP operators and completely hide it from end users, but the problem is it requires agreement... and consistent rules, otherwise e-mail perhaps becomes too expensive: or not sufficiently predictably inexpensive. Now.... if SMTP providers charge each other postage... postage SPENT should be offset by postage RECEIVED. When e-mail conversations are mostly symmetrical --- for example: two users e-mailing each other, then the ratio of messages OUT to messages IN should be pretty close to 1.0, or at least not 1000 to 1; Which means.... the two SMTP servers could charge each other postage, but the postage spent is offset by postage received. This would be different for commercial bulk mailers ("legitimate" or otherwise), AND as a result --- they would pay. Shifting some costs back from sender to receiver of the message. And... perhaps the commercial mailers _should_ bear costs. As commercial mailings create support costs (when false positive'd by spam filters), And... additional storage cost (before the user downloads their message from their POP3 mailbox). Also large-scale bulk mail consumes bandwidth, memory, and processing power. So... how could it work technically... One possibility: a SMTP server proves postage deposited, by each presenting a cryptocurrency wallet address in the HELO banner and the 250 reply; for the smtp transaction to proceed, the sending server needs to be challenged to prove it has the balance to pay --- and challenged then to provide the signed transaction in the form of a "Temporary deposit". Probably through SMTP Extension verbs. For example: "250 Hello: new SMTP server at IP address Xyz. Before you can start sending me mail, except to abuse or postmaster, or clearly marked BULK class mail: you need to introduce yourself with an AUTH message and provide a Base64 signed transaction paying out a minimum of a $0.002 deposit. to unique address [blahblah]. Deposit forfeit if not used to send First class Email within 48 hours, or upon any abuse complaint. After this SMTP server receives confirmation of your deposit; this SMTP server will track your balance by your IP address, and you will be allowed to send mail from this IP, as long as your balance is not negative. The cost of postage will be subtracted from your deposit. Note, that every time you place a new deposit, $0.0001 will be subtracted as an introduction fee. Every future SMTP connection you make to this server is $0.000001 times the number of simultaneous connections. After the introduction, The first 100 valid recipients and the first 10 invalid recipients or 500 kilobytes of First class traffic per SMTP IP address are free for the first 100 times you connect to my SMTP port. Beyond this, every time you present a RCPT TO with an invalid e-mail address, or address with an unauthorized recipient domain, $0.0005 will be deducted. Every time you present a RCPT TO, $0.000001 will be be immediately deducted. Every time you complete DATA stage, the charge will be $0.000001 times the number of RCPT TO lines for successfully accepted recipients every 1 Kilobyte after the first 250 Kilobytes of message data received. If the entire delivery fails due to a connection timeout, only 1 recipient is charged for received data. SPECIAL MAIL CLASSES: Bulk Solicited Mail - 1/1000 the normal postage rate per recipient for first 250Kb. - Identify by specifying 'Precedence: Bulk' in the message header. Must prepay the standard postage for the first 1000 recipients. Excess postage refunded after no spam complaints for 48 hours. Priority Mail - 10000x the normal postage rate per recipient. - Charged if Subject line contains the word PRIORITY or the message contains a X-Priority, Importance, or X-Priority Header indicating high priority. Urgent Mail - 100000x the normal postage rate per recipient. - Subject line contains the word URGENT, or the message contains a Disposition-Notification-To or Return-Receipt-To header or the message contains a X-Priority, Importance, or X-Priority Header indicating high priority, " So there may be a $0.002 cost to send a 250 Kilobyte message to 1000 recipients. Or $0.10 to send to 100000 local recipients. In the event of a user sending mail to a free mailing list, well.... The mailing list provider is likely to require whatever fee is needed to offset the number of members in the mailing list. We're getting lost in the metaphors methinks. > -- -JH From hank at efes.iucc.ac.il Sat Mar 29 18:51:20 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 29 Mar 2014 21:51:20 +0300 Subject: 3356 leaking routes out 3549 lately? In-Reply-To: <20140328194212.GB43550@2bithacker.net> References: Message-ID: <5.1.1.6.2.20140329214955.052de4a0@efes.iucc.ac.il> At 15:42 28/03/2014 -0400, Chip Marshall wrote: I have seen prefix leaking via AS3356 as well in the past year. -Hank >On 2014-03-28, David Hubbard sent: > > Has anyone had issues with Level 3 leaking advertisements out their > > Global Crossing AS3356 for customers of 3549, but not accepting the > > traffic back? We've been encountering this more and more recently, > > bgpmon always detects it, and all we ever get from them is there's > > nothing wrong. Today it affected CloudFlare's ability to talk to us. > > It seems to happen mostly with Europe and Asian peering points. > > Typically lasts five to ten minutes which makes me think someone working > > on merging the two networks is doing some 'no one will notice this' > > changes in the middle of the night. > >I'm not sure if it's the same thing, but I've had a few alerts >from Renesys lately seeing a path to my AS via GLBX 3549 that >shouldn't exist, as we only have connections with Level 3 3356. > >For example, Renesys reports "x 3549 33517" where it should only >be able to see "x 3356 33517" or maybe "x 3549 3356 33517". > >(Due to Renesys policy, I can't know what x is) > >-- >Chip Marshall >http://2bithacker.net/ From bzs at world.std.com Sat Mar 29 20:31:42 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 29 Mar 2014 16:31:42 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> Message-ID: <21303.11694.671771.160140@world.std.com> On March 29, 2014 at 08:28 owen at delong.com (Owen DeLong) wrote: > > So if a spammer or junk mailer could, say, trick you into accepting > > mail in those schemes then they get free advertising, no postage > > anyhow. > > Sure, but how would they trick you into saying ?I wanted this advertising? once you?ve actually seen that it is advertising. I dunno, but they trick people all the time, isn't that what the entire phishing industry is based on? I guess the real point is that this idea that one would be sorting through their email saying don't charge for this one I want it, charge for this one, I don't, etc is not a good idea. As I said earlier what might work is when you sign up for some email (list, advertising, customer account) you can also enter some sort of cookie which the sender can use to charge against your epostage quota. But I think it introduces all sorts of complexities for not much gain. Needs more thinking, including "is this really a problem that needs to be solved?" > > > We're getting lost in the metaphors methinks. > > I don?t think so, I think we?re having differing visions of how it would work in detail. Well, that's always the problem at some point. Lacking a specific, detailed proposal one tries to work out how it might work, look for inherent flaws in the idea, show stoppers. This is basically brainstorming. > > >>> So offering to not charge you because you wanted that mail makes no > >>> sense, right? > >> > >> But this isn?t a charge for the post office and by the time you?re connected to the internet, the cost of receiving the mail and transporting it and the sender sending it is pretty much sunk by some arguments. > > > > FIRST: There's a typo/thinko in my sentence! > > > > Should be: > > > > So offering to not charge THE SENDER because THE RECIPIENT wanted > > that mail makes no sense, right? > > > > SECOND: > > > > In response, someone has to scale resources to match volume. > > > > But maybe my typo/thinko confused this because you know that, sorry. > > Yes, but those costs are essentially already sunk in existing internet access. The cost of transmission is already paid by all parties involved. This wouldn?t be intended to subsidize that. The reason for splitting the postage between the recipient and the recipient ISP was to aid in recovery of the costs of administering the postage process. What about the costs of anti-spam technology? And all the other problems spam incurs? I thought that's why we were here. (trying to elide a lot...) > > Please present your definition of SPAM. I don?t see how a shipping notification, a transaction receipt, etc. could possibly be considered SPAM. My whole point is I don't WANT to have a definition of spam, except as a bad memory. I'm trying to figure out how to change the ecology/economics so spam is difficult, a minor problem. > > > Just like my analogy with the post office, they wouldn't deliver mail > > for free just because the recipient wanted it. > > That postage is already being paid for email? You pay for internet access and so do the spammers, so the idea that your proposed e-postage is a payment related to the delivery of the mail is absurd from the beginning. Again, we're talking about spam and the harm it does, the costs it incurs. And phishing etc. That's sort of like saying my car can drive down the road perfectly well with some gasoline etc, why do I need to pay taxes for police? > > >> The vast majority of messages I get from Amazon are order confirmations, shipping status reports, etc. Messages related to transactions I have conducted with them. Yes, I get a little bit of SPAM from them and I wouldn?t mind seeing them forced to pay me for those messages, but I certainly don?t want to see them paying for every message they send. > > > > The vast majority of paper mail I get from my bank accounts is useful > > and informative and often legally important. > > > > But every one of them has postage attached. > > Yes, but you aren?t paying the USPS a fee for you to have a mailbox that the mailman drives by whether you receive mail or not and neither is your bank. I certainly don?t want to start double-paying for spam (or legitimate email for that matter). Recipients wouldn't pay in my scheme. If you mean that legitimate senders have to pay and somehow recover that cost, well, we all pay for police and other security. Security is often like that. When you pay for a prison you pay to house prisoners, any benefit to you is at best abstract (they're not on the streets etc.) > > Further, if someone sends me something I don?t want, I can mark it ?refused, return to sender? and the post office is obliged to do so and I don?t pay anything for it. This is probably getting off-track, but are you sure about that with the USPS? You can mark it NSA (no such addressee) or NFA (no forwarding address) or NSA/NFA or even put a forwarding address which may or may not do anything since the recipient is supposed to set that up with the post office (e.g., when they move.) But I never heard of taking all my junk mail for example and handing it back to a letter carrier saying "Here, I don't want this!" I think they'd say "throw it in the trash!" > >> I didn?t authorize the spammer to use my computer, systems, disk, network, etc. They simply did so without my authorization. If I had a cost effective way to identify them, track them down, and hold them accountable for this, I would gladly do so. > > > > Do you mean sending (making you a bot) or receiving spam? > > Receiving. Well, truth be told you didn't really authorize many people who send you email to use your resources. So we're back to the definition of spam problem. Which is exactly what I'm trying to get away from. > > > I'm saying the notion of who you did authorize to send you email is > > getting fuzzier and fuzzier and may no longer be a completely useful > > distinction. > > How so? If I actually signed up with you to receive your mail, then I opted in and you have my permission on record. > If I bought something from you, then I signed up to receive emails RELATED TO THAT TRANSACTION and you have that permission on record. > If I checked the box to receive other emails from you, then you have that permission on record. > If you don?t have my permission on record, then you don?t have my permission. Seems pretty simple and clear and predictable to me. > > Now, you might be able to get my retroactive permission by paying to ask, and if I agree, your ?permission fee? is refunded. OTOH, if I say ?no?, then you don?t get your money back. "Related to that transaction"? Is that in CAN-SPAM? Where did that limitation come from? How is that defined? You mean when Network Solutions bombards me with email about each new TLD they're violating CAN-SPAM? I never asked for that. I do have some domains with them, I think they're using that for a "legitimate business relationship". Legitimate businesses (perhaps other than NetSol :-) do tend to restrain themselves and know recipients might get annoyed if they overdo their welcome and opt-out or even block them entirely. An example of the line getting fuzzy is when my frequent flyer sources (airlines etc) constantly hawk credit cards at me under the excuse that I'll get 50,000 free miles or some such. So it sort of sounds related to the frequent flyer program. But I think they're just hawking Amex cards and getting a commission for each one they sell. > > > That should have been predictable. Create a fuzzy hurtle and it will > > get hurtled. > > I?m not seeing the fuzziness you claim is present. > > > Accept that "it's not spam if I have a business relationship with the > > sender" and that "business relationship" definition will get > > stretched. > > See above. I have a _MUCH_ narrower definition of what should be accepted. Wait. Are we talking about what you think should be ok, or what the current law (as it were, but CAN-SPAM for example) thinks is ok, or what common practice seems to think is ok, or how it should work under the regime I'm describing? As I said, I'm trying to come up with a spam-definition-neutral approach. > > > For example, Buy an auto insurance policy from Liberty Mutual and you > > just gave permission for every Liberty Mutual insurance agent in the > > world to hawk you life insurance, home owner's insurance, etc etc etc. > > over email. > > No, I didn?t. See above. Again, I think CAN-SPAM etc would agree with my description within reason. > >> I define SPAM not in terms of content, but in the nature of the relationship between the sender and the recipient. If the recipient has no relationship with the sender and doesn?t want to receive the sender?s message, then in most cases, it?s SPAM. > > > > Yeah, well, if you ever get an unexpected email (truly) from Bank of > > America for example offering great CD rates and can't imagine why they > > sent it have a ball calling the FTC and filing a CAN-SPAM violation. > > If such a thing happened and it actually came from BofA, then, yes, it would. And I'm saying good luck getting whoever it is enforces CAN-SPAM to agree, unless it just happens to be on their radar for some reason. > > However, BofA is smart enough to keep such SPAMvertising at arms length and you have to track down the spammer that actually sent the email under contract to BofA, not BofA themselves. It would be nice if CAN-SPAM were expanded to affect the advertiser and/or advertised product instead of just the entity actually sending the SPAM, but so far, that has not happened. There are limits to Agency Law. You can't hire someone to break the law and then say it's entirely their problem. Well, there are all sorts of hard cases, but laying it out sometimes surprises people (like, yes you can be held responsible for the actions of a hired bodyguard, even if their behavior was way out of line. They sell insurance for that kind of thing.) > > > > > Maybe something would happen, I can't say for sure. > > > > But I suspect they'd round file it because hey that's BANK OF AMERICA > > not SPAMMERS and you're just a KOOK! > > No, more likely they?d review the headers and point out to me that there?s no evidence it was actually sent BY BofA, because most likely it wasn?t sent by BofA, but by someone they may or may not have contracted. Well, now we're really just moving the goalpost and changing the scenario. > > > Extrapolate to any company the FTC has heard of and respects. > > Really more a matter of how those companies keep their SPAM at arms length and circumvent the intent of the law than their reputation with the FTC. > > > That's what I mean by a moralistic component. > > > > But if BoA was fudging their postal meters and the post office noticed > > it'd be Book 'Em Dan-O before the next commercial break. > > Indeed, the mailing agency that BofA hires to send out their postal spam pays full postage and can?t really avoid that. > > But postage is related to the cost of delivering the mail. What you are proposing as e-postage isn?t. Of course it is. If your email won't be accepted without proper postage attached then that's the cost of having your email delivered. Just because the work can't be expressed in Newtons over Distance doesn't mean it's not valuable. Ok, I think a lot of the rest of this could be answered by: It would be interesting to ask a spammer or ex-spammer what they thought about the scheme. Beyond that we're just guessing as to whether what's proposed would alter their behavior. And I gotta go eat some lunch! -- -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 johnl at iecc.com Sat Mar 29 22:37:24 2014 From: johnl at iecc.com (John Levine) Date: 29 Mar 2014 22:37:24 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21303.11694.671771.160140@world.std.com> Message-ID: <20140329223724.3994.qmail@joyce.lan> >But I think it introduces all sorts of complexities for not much >gain. Needs more thinking, including "is this really a problem that >needs to be solved?" Don't forget "Vanquish was a complete failure, so why would this be any different?" and "do I want Phil Raymond to sue me for violating the patent on this exact scheme?" R's, John PS: You must have met him at one of the spam conferences. I met him a few times. From LarrySheldon at cox.net Sat Mar 29 23:58:31 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 29 Mar 2014 18:58:31 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> Message-ID: <53375E27.10809@cox.net> On 3/29/2014 12:59 PM, Jimmy Hess wrote: > *Postage schemes as proposed with end users email clients 'attaching > postage' simply not workable Not in IPv4. Not in IPv6. Not in IPng > Not in any conceivable future version of IP. And I insist that we are all wasting our time trying to make SMTP and its supporting protocols (and their kin under IPX/SPC, Sperrylink, UUCP, et alia) are not at the transport layer and nothing at the transport layer is responsible for nor rich with solutions for their problems. IF the overriding problem is due to an inability to identify and authenticate the identification of the sender, then let us work on establishing a protocol for identifying the sender and authenticating the identification of the sender and permitting the receiver to accept or deny acceptance of traffic by reference to that identification. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From bzs at world.std.com Sun Mar 30 00:38:30 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 29 Mar 2014 20:38:30 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140329223724.3994.qmail@joyce.lan> References: <21303.11694.671771.160140@world.std.com> <20140329223724.3994.qmail@joyce.lan> Message-ID: <21303.26502.281987.205590@world.std.com> On March 29, 2014 at 22:37 johnl at iecc.com (John Levine) wrote: > >But I think it introduces all sorts of complexities for not much > >gain. Needs more thinking, including "is this really a problem that > >needs to be solved?" > > Don't forget "Vanquish was a complete failure, so why would this be > any different?" and "do I want Phil Raymond to sue me for violating > the patent on this exact scheme?" That was a specific reply by me to a specific suggestion of a mechanism refunding e-postage to the sender if one wanted an e-mail or leaving the charge if not. As I said I think it's overly complex in implementation and not of much benefit. I don't see where Vanquish does any of this from the product site tho I could look at the patents, they might cover more than they used in products of course. HOWEVER: a) If you really were referring to the context of that remark, refunding postage to desired senders, not much problem since I don't see that as useful anyhow. b) If there's some broader context, well, patents can get licensed and otherwise negotiated so I don't know why anyone would be suing anyone. This reminds me of when I was working on a Rock & Roll 50th Anniversary site and we'd put up materials licensed for use by the site. And I'd get this non-stop stream of YOU WILL GET SUED! emails from people who merely visited the site, many DEMANDING we immediately produce proof to them that the material was properly licensed or take it down IMMEDIATELY! And they would be CHECKING! etc. Some would even phone the office and scream at me. None were owners or had any interest in the materials which, as I said, were all properly licensed. There was never any actual problem, not a hint. Gratuitous anecdote: The only (very tiny, funny) problem we ever had was when Elvis Presley Enterprises (which is, yes, that Elvis Presley) printed up T-shirts using some of our slogans which we clearly marked as TM. I sent them a letter offering a $0 license to print as many T-shirts as they like if they just mentioned us in their ads in some friendly way once in a while...LET'S TALK! I mean, hey, this is Elvis Presley Enterprises! Respect to The King. I got back this amazing letter from what must have been a strip mall lawyer, the stationery was truly cheesy (it had logs on it, some sort of good ol' boy western theme I guess), asserting that we had no rights in those slogans because we were NOT in the T-shirt/Apparel business (i.e., USPTO category.) I dropped the matter because it was just too silly to even respond to and figured if it ever seemed to make a difference I'd worry about it. They didn't seem to be selling too many of those T-shirts anyhow, and now they'd been informed and had acknowledged notice which is half the game. Nothing came of it. Not much came of the site either, unfortunately tho I did get to meet a lot of interesting people. Bo Diddley called me once to tell me how great he thought it all was and could he help! > R's, > John > > PS: You must have met him at one of the spam conferences. I met him a > few times. Maybe, I'm looking at his picture and his face doesn't ring a bell but he seems to be here in the Boston area so if there were a mutual interest I suppose a meeting would be easy enough. -- -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 mpetach at netflight.com Sun Mar 30 01:05:39 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 29 Mar 2014 18:05:39 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140326165952.13291.qmail@joyce.lan> References: <5332DF1A.9040001@pari.edu> <20140326165952.13291.qmail@joyce.lan> Message-ID: On Wed, Mar 26, 2014 at 9:59 AM, John Levine wrote: > >That way? Make e-mail cost; have e-postage. > > Gee, I wondered how long it would take for this famous bad idea to > reappear. > > I wrote a white paper ten years ago explaining why e-postage is a > bad idea, and there is no way to make it work. Nothing of any > importance has changed since then. > > http://www.taugh.com/epostage.pdf > > R's, > John > > PS: Yes, I've heard of Bitcoins. > > Good lord. I love your page about how a micropayment handling system would have to be so immense it couldn't possibly be built, because otherwise someone would have built one by now. The numbers you list in your argument against a micropayment system being able to function are a fraction of the number of transactions Facebook deals with in updating newsfeeds for the billion+ users on their system.[0] You're postulating needing something 100x the size of the credit card processing system, which does 100,000,000 transactions/day. Facebook's presentation talks about doing billions *per second*, which if I do the math right, puts it conservatively at almost 900,000x the scale of the credit card processing system; certainly well beyond the threshold of what you considered necessary to handle email micropayment transactions. I suspect your notion of "Creating a transaction system large enough for e-postage would be prohibitively expensive." is no longer true. Matt [0] https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala From johnl at iecc.com Sun Mar 30 02:34:56 2014 From: johnl at iecc.com (John R. Levine) Date: 29 Mar 2014 22:34:56 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21303.26502.281987.205590@world.std.com> References: <21303.11694.671771.160140@world.std.com> <20140329223724.3994.qmail@joyce.lan> <21303.26502.281987.205590@world.std.com> Message-ID: > > Don't forget "Vanquish was a complete failure, so why would this be > > any different?" and "do I want Phil Raymond to sue me for violating > > the patent on this exact scheme?" > > That was a specific reply by me to a specific suggestion of a > mechanism refunding e-postage to the sender if one wanted an e-mail or > leaving the charge if not. > > As I said I think it's overly complex in implementation and not of > much benefit. > > I don't see where Vanquish does any of this from the product site tho > I could look at the patents, they might cover more than they used in > products of course. Really, this is a WKBI from 1997. Look at the patent if you don't believe me. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl at iecc.com Sun Mar 30 02:40:48 2014 From: johnl at iecc.com (John R. Levine) Date: 29 Mar 2014 22:40:48 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <5332DF1A.9040001@pari.edu> <20140326165952.13291.qmail@joyce.lan> Message-ID: > The numbers you list in your argument against a micropayment > system being able to function are a fraction of the number of > transactions Facebook deals with in updating newsfeeds for > the billion+ users on their system.[0] ... which is completely irrelevant because they don't have a double spending problem. Sheesh. It's easy to scale up stuff that is trivially parallelizable.* Also, I wrote that ten years ago. Add an extra zero or two to the numbers if you want, but it doesn't make any difference. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly * - a term of art, look it up From bzs at world.std.com Sun Mar 30 03:00:36 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 29 Mar 2014 23:00:36 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53375E27.10809@cox.net> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> <53375E27.10809@cox.net> Message-ID: <21303.35028.233266.814468@world.std.com> Although that's useful for some situations it's a not at the heart of the spam problem, or is just one small facet at best. People you don't know, like perhaps me right now, will send you email which isn't spam, and which presumably you're ok with receiving. So, it's not the overriding problem with spam. On March 29, 2014 at 18:58 LarrySheldon at cox.net (Larry Sheldon) wrote: > On 3/29/2014 12:59 PM, Jimmy Hess wrote: > > > *Postage schemes as proposed with end users email clients 'attaching > > postage' simply not workable Not in IPv4. Not in IPv6. Not in IPng > > Not in any conceivable future version of IP. > > And I insist that we are all wasting our time trying to make SMTP and > its supporting protocols (and their kin under IPX/SPC, Sperrylink, UUCP, > et alia) are not at the transport layer and nothing at the transport > layer is responsible for nor rich with solutions for their problems. > > IF the overriding problem is due to an inability to identify and > authenticate the identification of the sender, then let us work on > establishing a protocol for identifying the sender and authenticating > the identification of the sender and permitting the receiver to accept > or deny acceptance of traffic by reference to that identification. > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) -- -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 johnl at iecc.com Sun Mar 30 03:31:41 2014 From: johnl at iecc.com (John Levine) Date: 30 Mar 2014 03:31:41 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <53375E27.10809@cox.net> Message-ID: <20140330033141.4861.qmail@joyce.lan> >IF the overriding problem is due to an inability to identify and >authenticate the identification of the sender, then let us work on >establishing a protocol for identifying the sender and authenticating >the identification of the sender and permitting the receiver to accept >or deny acceptance of traffic by reference to that identification. We've got DKIM, SPF, S/MIME, and PGP. What more do you want? R's, John From bzs at world.std.com Sun Mar 30 04:11:48 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 30 Mar 2014 00:11:48 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <21303.11694.671771.160140@world.std.com> <20140329223724.3994.qmail@joyce.lan> <21303.26502.281987.205590@world.std.com> Message-ID: <21303.39300.804622.225416@world.std.com> On March 29, 2014 at 22:34 johnl at iecc.com (John R. Levine) wrote: > > > Don't forget "Vanquish was a complete failure, so why would this be > > > any different?" and "do I want Phil Raymond to sue me for violating > > > the patent on this exact scheme?" > > > > That was a specific reply by me to a specific suggestion of a > > mechanism refunding e-postage to the sender if one wanted an e-mail or > > leaving the charge if not. > > > > As I said I think it's overly complex in implementation and not of > > much benefit. > > > > I don't see where Vanquish does any of this from the product site tho > > I could look at the patents, they might cover more than they used in > > products of course. > > Really, this is a WKBI from 1997. Look at the patent if you don't believe > me. I don't know what "WKBI" means and google turns up nothing. I'll guess "Well Known Bad Idea"? Since I said that I found the idea described above uninteresting I wonder what is a "WKBI" from 1997? The idea I rejected? Also, I remember ideas being shot down on the ASRG (Anti-Spam Research Group) list primarily because they would take ten years to gain acceptance. Over ten years ago. Maybe they were bad ideas for other reasons. Some certainly were. But there's this tone of off-the-cuff dismissal, oh that would take TEN YEARS to gain traction, or that's a WKBI, which I don't find convincing. I read your paper, for example, and said it's a nice paper. But I don't find it compelling to the degree you seem to want it to be because it mostly makes a bunch of assumptions about how an e-postage system would work and proceeds to argue that the particular model you describe (and some variants) creates impossible or impractical hurdles. But what if it worked differently? At some point you're just reacting to the term "e-postage" and whatever it happens to mean to you, right? You can't really say you've exhaustively worked out every possibility which might be labelled "e-postage". Only a particular interpretation, a fairly specific model, or a few. When people talked of "virtual currency" over the years, often arguing that it's too hard a problem, how many described bitcoin with its cryptographic mining etc? Bitcoin might well be a lousy solution. But there it is nonetheless, and despite the pile of papers which argued that this sort of thing was impossible or nearly so. Note: Yes, I can also argue that Bitcoin is not truly a virtual currency. Sometimes a problem is like the Gordian Knot of ancient lore which no one could untie. And then Alexander The Great swung his sword and the crowds cried "cheat!" but he then became King of Asia just as prophesized. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly -- -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 johnl at iecc.com Sun Mar 30 04:47:36 2014 From: johnl at iecc.com (John Levine) Date: 30 Mar 2014 04:47:36 -0000 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21303.39300.804622.225416@world.std.com> Message-ID: <20140330044736.5192.qmail@joyce.lan> >When people talked of "virtual currency" over the years, often arguing >that it's too hard a problem, how many described bitcoin with its >cryptographic mining etc? None, but it shouldn't be hard to look at the way bitcoin works and realize why it'd be phenomenally ill suited for e-postage, just for technical reasons. I told Satoshi so in 2009. R's, John PS: Sometimes a WKBI really is a WKBI. From owen at delong.com Sun Mar 30 06:26:25 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Mar 2014 23:26:25 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21303.11694.671771.160140@world.std.com> References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> <21303.11694.671771.160140@world.std.com> Message-ID: On Mar 29, 2014, at 1:31 PM, Barry Shein wrote: > > On March 29, 2014 at 08:28 owen at delong.com (Owen DeLong) wrote: >>> So if a spammer or junk mailer could, say, trick you into accepting >>> mail in those schemes then they get free advertising, no postage >>> anyhow. >> >> Sure, but how would they trick you into saying ?I wanted this advertising? once you?ve actually seen that it is advertising. > > I dunno, but they trick people all the time, isn't that what the > entire phishing industry is based on? > > I guess the real point is that this idea that one would be sorting > through their email saying don't charge for this one I want it, charge > for this one, I don't, etc is not a good idea. I was envisioning a system more where you white-listed your known contacts up front, then only needed to say ?refund this one and add to white-list? or ?refund this one? when confronted with one that wasn?t already white-listed that you didn?t feel was spam. >>> We're getting lost in the metaphors methinks. >> >> I don?t think so, I think we?re having differing visions of how it would work in detail. > > Well, that's always the problem at some point. Lacking a specific, > detailed proposal one tries to work out how it might work, look for > inherent flaws in the idea, show stoppers. > > This is basically brainstorming. Yep? Wasn?t a criticism, merely an effort to home in on a more accurate problem description for the communications failures so we weren?t trying to solve the incorrect cause. >>>>> So offering to not charge you because you wanted that mail makes no >>>>> sense, right? >>>> >>>> But this isn?t a charge for the post office and by the time you?re connected to the internet, the cost of receiving the mail and transporting it and the sender sending it is pretty much sunk by some arguments. >>> >>> FIRST: There's a typo/thinko in my sentence! >>> >>> Should be: >>> >>> So offering to not charge THE SENDER because THE RECIPIENT wanted >>> that mail makes no sense, right? >>> >>> SECOND: >>> >>> In response, someone has to scale resources to match volume. >>> >>> But maybe my typo/thinko confused this because you know that, sorry. >> >> Yes, but those costs are essentially already sunk in existing internet access. The cost of transmission is already paid by all parties involved. This wouldn?t be intended to subsidize that. The reason for splitting the postage between the recipient and the recipient ISP was to aid in recovery of the costs of administering the postage process. > > What about the costs of anti-spam technology? And all the other > problems spam incurs? I thought that's why we were here. Reality is those costs are pretty much sunk at this point as well, mostly embedded into the price of internet access and mail services as they exist today. Sure, there might be some long term reductions in those costs if this worked out, but at what relative price? >> Please present your definition of SPAM. I don?t see how a shipping notification, a transaction receipt, etc. could possibly be considered SPAM. > > My whole point is I don't WANT to have a definition of spam, except as > a bad memory. > > I'm trying to figure out how to change the ecology/economics so spam > is difficult, a minor problem. I get what you want, but I don?t see it as a solution due to the negative consequences described elsewhere in the thread. >>> Just like my analogy with the post office, they wouldn't deliver mail >>> for free just because the recipient wanted it. >> >> That postage is already being paid for email? You pay for internet access and so do the spammers, so the idea that your proposed e-postage is a payment related to the delivery of the mail is absurd from the beginning. > > Again, we're talking about spam and the harm it does, the costs it > incurs. And phishing etc. > > That's sort of like saying my car can drive down the road perfectly > well with some gasoline etc, why do I need to pay taxes for police? I often find myself wondering exactly that? Usually after trying to get some service or other that the police are supposed to be providing. Nonetheless, I get your point. OTOH, the city council, as a body, doesn?t pay taxes for police. Neither does the city, which owns quite a fleet of vehicles. So, what is your equivalent in this regime to the ?tax exempt organization?? >>>> The vast majority of messages I get from Amazon are order confirmations, shipping status reports, etc. Messages related to transactions I have conducted with them. Yes, I get a little bit of SPAM from them and I wouldn?t mind seeing them forced to pay me for those messages, but I certainly don?t want to see them paying for every message they send. >>> >>> The vast majority of paper mail I get from my bank accounts is useful >>> and informative and often legally important. >>> >>> But every one of them has postage attached. >> >> Yes, but you aren?t paying the USPS a fee for you to have a mailbox that the mailman drives by whether you receive mail or not and neither is your bank. I certainly don?t want to start double-paying for spam (or legitimate email for that matter). > > Recipients wouldn't pay in my scheme. OK, turn it around and you aren?t paying a separate fee for the mailman to drive by your place each day to see if you have any outgoing mail, either. > If you mean that legitimate senders have to pay and somehow recover > that cost, well, we all pay for police and other security. Security is > often like that. When you pay for a prison you pay to house prisoners, > any benefit to you is at best abstract (they're not on the streets > etc.) I don?t pay the USPS any separate taxes to support the postal inspectors. That?s rolled up into the postage. >> Further, if someone sends me something I don?t want, I can mark it ?refused, return to sender? and the post office is obliged to do so and I don?t pay anything for it. > > This is probably getting off-track, but are you sure about that with > the USPS? Yes. For most mail, you can. Third Class and Bulk, not so much, they?ll tell you to throw it away. I don?t pay anything for that, either. If I really want to get rid of a junk mailer (at least one who is dumb enough to send me postage-paid reply mechanisms), I?ll package up a brick, attach the reply label they provided and send it off. (lead weights, shot-bags, etc. can also be effective candidates). I?ve only used this tactic a few times, but it?s never taken more than two heavy replies to get the flow of crap to stop abruptly. > You can mark it NSA (no such addressee) or NFA (no forwarding address) > or NSA/NFA or even put a forwarding address which may or may not do > anything since the recipient is supposed to set that up with the post > office (e.g., when they move.) Yep. They?ll take it back and either forward it if they can or send it to the dead letter office. > But I never heard of taking all my junk mail for example and handing > it back to a letter carrier saying "Here, I don't want this!" I think > they'd say "throw it in the trash!? Specifically doesn?t work with third-class and bulk. They are the only exceptions. >>>> I didn?t authorize the spammer to use my computer, systems, disk, network, etc. They simply did so without my authorization. If I had a cost effective way to identify them, track them down, and hold them accountable for this, I would gladly do so. >>> >>> Do you mean sending (making you a bot) or receiving spam? >> >> Receiving. > > Well, truth be told you didn't really authorize many people who send > you email to use your resources. If I wanted the email, then I retroactively authorize(d) them, authorized them by implication, or authorized them through other mechanisms. > So we're back to the definition of spam problem. Again, I don?t see that as a hard problem. > Which is exactly what I'm trying to get away from. I?m aware of that. However, I don?t see you getting around several rather nasty unintended consequences that way. >>> I'm saying the notion of who you did authorize to send you email is >>> getting fuzzier and fuzzier and may no longer be a completely useful >>> distinction. >> >> How so? If I actually signed up with you to receive your mail, then I opted in and you have my permission on record. >> If I bought something from you, then I signed up to receive emails RELATED TO THAT TRANSACTION and you have that permission on record. >> If I checked the box to receive other emails from you, then you have that permission on record. >> If you don?t have my permission on record, then you don?t have my permission. Seems pretty simple and clear and predictable to me. >> >> Now, you might be able to get my retroactive permission by paying to ask, and if I agree, your ?permission fee? is refunded. OTOH, if I say ?no?, then you don?t get your money back. > > "Related to that transaction"? Is that in CAN-SPAM? Where did that > limitation come from? How is that defined? Forget current law. I?m talking about the criteria I would want to set if we were to overhaul the system and do this right. > You mean when Network Solutions bombards me with email about each new > TLD they're violating CAN-SPAM? I never asked for that. I do have some > domains with them, I think they're using that for a "legitimate > business relationship?. No, I never brought CAN-SPAM into this, that?s your idea. I?m talking about the criteria that could easily be used to define SPAM consistently in a way that isn?t fuzzy, doesn?t have the problems currently created by CAN-SPAM (a law written by spammers for spammers), etc. > Legitimate businesses (perhaps other than NetSol :-) do tend to > restrain themselves and know recipients might get annoyed if they > overdo their welcome and opt-out or even block them entirely. > > An example of the line getting fuzzy is when my frequent flyer sources > (airlines etc) constantly hawk credit cards at me under the excuse > that I'll get 50,000 free miles or some such. So it sort of sounds > related to the frequent flyer program. And by allowing the user to do one of: Whitelist the airline Accept each message they want (refunded, others airline pays) Decline all messages (airline pays) You could decide for yourself which messages from the airline you don?t consider SPAM, with the added benefit that you get a small amount of money for each message you don?t actively claim isn?t SPAM. > But I think they're just hawking Amex cards and getting a commission > for each one they sell. Of course they are, and I would not mark any of those messages as ?accepted? and it would cost them for each one they sent. >>> That should have been predictable. Create a fuzzy hurtle and it will >>> get hurtled. >> >> I?m not seeing the fuzziness you claim is present. >> >>> Accept that "it's not spam if I have a business relationship with the >>> sender" and that "business relationship" definition will get >>> stretched. >> >> See above. I have a _MUCH_ narrower definition of what should be accepted. > > Wait. Are we talking about what you think should be ok, or what the > current law (as it were, but CAN-SPAM for example) thinks is ok, or > what common practice seems to think is ok, or how it should work under > the regime I'm describing? How it should work under the alternative regime I am describing. > As I said, I'm trying to come up with a spam-definition-neutral > approach. I know, but I believe that approach to be fundamentally flawed and I am trying very hard to propose an alternative I believe could be more functional. >>> For example, Buy an auto insurance policy from Liberty Mutual and you >>> just gave permission for every Liberty Mutual insurance agent in the >>> world to hawk you life insurance, home owner's insurance, etc etc etc. >>> over email. >> >> No, I didn?t. See above. > > Again, I think CAN-SPAM etc would agree with my description within > reason. I?m sure it would, but I?m not talking about CAN-SPAM and I?m not sure why you brought it into the discussion. >>>> I define SPAM not in terms of content, but in the nature of the relationship between the sender and the recipient. If the recipient has no relationship with the sender and doesn?t want to receive the sender?s message, then in most cases, it?s SPAM. >>> >>> Yeah, well, if you ever get an unexpected email (truly) from Bank of >>> America for example offering great CD rates and can't imagine why they >>> sent it have a ball calling the FTC and filing a CAN-SPAM violation. >> >> If such a thing happened and it actually came from BofA, then, yes, it would. > > And I'm saying good luck getting whoever it is enforces CAN-SPAM to > agree, unless it just happens to be on their radar for some reason. CAN-SPAM is a rathole. Please drop it. It?s not furthering our discussion. >> However, BofA is smart enough to keep such SPAMvertising at arms length and you have to track down the spammer that actually sent the email under contract to BofA, not BofA themselves. It would be nice if CAN-SPAM were expanded to affect the advertiser and/or advertised product instead of just the entity actually sending the SPAM, but so far, that has not happened. > > There are limits to Agency Law. You can't hire someone to break the > law and then say it's entirely their problem. Ah, but BofA didn?t hire them to break the law. BofA hired them to send the SPAM to the list they promised BofA was entirely opt-in users who chose to receive their mails. The fact that they lied to BofA means BofA doesn?t have any liability. The fact that BofA profits from this lie without consequences means that BofA has no incentive to go after them for a refund or avoid using their services in the future. > Well, there are all sorts of hard cases, but laying it out sometimes > surprises people (like, yes you can be held responsible for the > actions of a hired bodyguard, even if their behavior was way out of > line. They sell insurance for that kind of thing.) Sure, but the spammers happily cover BofA?s ass contractually and then say ?oops? or ?we lied? or whatever they have to in order to get BofA off the hook. Then, nobody gets punished and business as usual. >>> Maybe something would happen, I can't say for sure. >>> >>> But I suspect they'd round file it because hey that's BANK OF AMERICA >>> not SPAMMERS and you're just a KOOK! >> >> No, more likely they?d review the headers and point out to me that there?s no evidence it was actually sent BY BofA, because most likely it wasn?t sent by BofA, but by someone they may or may not have contracted. > > Well, now we're really just moving the goalpost and changing the > scenario. No, I?m pointing out how organizations like BofA actually do this and you?re talking about some fictitious scenario that doesn?t happen in real life. Yes, BofA and SPAM-Inc. move the goalpost and change the scenario, but that?s also why most telco-contracted backhoe operating companies have numbers in their name? Ho-Co #1 cut someone?s fiber, so they sold their substantial assets to Ho-Co #2 for a song to pay their legal fees, then went chapter 13 before the case could make it to court. >>> Extrapolate to any company the FTC has heard of and respects. >> >> Really more a matter of how those companies keep their SPAM at arms length and circumvent the intent of the law than their reputation with the FTC. >> >>> That's what I mean by a moralistic component. >>> >>> But if BoA was fudging their postal meters and the post office noticed >>> it'd be Book 'Em Dan-O before the next commercial break. >> >> Indeed, the mailing agency that BofA hires to send out their postal spam pays full postage and can?t really avoid that. >> >> But postage is related to the cost of delivering the mail. What you are proposing as e-postage isn?t. > > Of course it is. If your email won't be accepted without proper > postage attached then that's the cost of having your email delivered. No, that?s a protection racket/extortion scheme. I?m talking about the cost of moving the mail from point A to point B. You?re talking about the cost of not having my nice email meet with an accident on the information superhighway. > Just because the work can't be expressed in Newtons over Distance > doesn't mean it's not valuable. See above. > Ok, I think a lot of the rest of this could be answered by: > > It would be interesting to ask a spammer or ex-spammer what they > thought about the scheme. LoL > Beyond that we're just guessing as to whether what's proposed would > alter their behavior. True, but first we have to get past ?would the community accept it generally? and I think your proposal (and probably mine) fail the smell test there. If it can?t get implemented, it doesn?t matter how much the spammers would hate it. > And I gotta go eat some lunch! Bon apetit. Owen From hammani.b at gmail.com Sun Mar 30 15:36:55 2014 From: hammani.b at gmail.com (hammani.b at gmail.com) Date: Sun, 30 Mar 2014 11:36:55 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140330033141.4861.qmail@joyce.lan> References: <53375E27.10809@cox.net> <20140330033141.4861.qmail@joyce.lan> Message-ID: <20140330153655.6594710.20690.3465@gmail.com> Sent from my BlackBerry 10 smartphone on the Rogers network. ? Original Message ? From: John Levine Sent: Saturday, March 29, 2014 11:35 PM To: nanog at nanog.org Subject: Re: why IPv6 isn't ready for prime time, SMTP edition >IF the overriding problem is due to an inability to identify and >authenticate the identification of the sender, then let us work on >establishing a protocol for identifying the sender and authenticating >the identification of the sender and permitting the receiver to accept >or deny acceptance of traffic by reference to that identification. We've got DKIM, SPF, S/MIME, and PGP. What more do you want? R's, John From johnl at iecc.com Sun Mar 30 16:09:12 2014 From: johnl at iecc.com (John R. Levine) Date: 30 Mar 2014 12:09:12 -0400 Subject: Can I borrow some MTA address traces? Message-ID: As noted about a zillion messages ago, one of the concerns about IPv6 mail is whether DNSBLs will be workable, with one of the questions being whether the lookups will blow away DNS caches. As far as I can tell, there is basically no research on DNS cache behavior other than a few very old papers that said for normal loads, a reasonable sized cache is big enough to work. For the DNSBL stuff I'm doing some simulations, which need data to drive the lookups. The data is really simple, a sequence of pairs: [ IP address, timestamp ] IPv4 traces are currently more useful than IPv6, since v6 doesn't have the botnet traffic that makes the DNSBL lookups interesting. Traces from medium sized systems, say a million connections a day, would be great. If you consider the IP addresses confidential you can hash them, although real ones would be better so I can test tweaks that treat known high volume senders (gmail etc.) differently. Thanks. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly PS: I hope it's OK if we take a break from reinventing patented anti-spam techniques that have failed repeatedly before to talk about something else. From bzs at world.std.com Sun Mar 30 17:03:07 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 30 Mar 2014 13:03:07 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140330044736.5192.qmail@joyce.lan> References: <21303.39300.804622.225416@world.std.com> <20140330044736.5192.qmail@joyce.lan> Message-ID: <21304.20043.753022.886555@world.std.com> On March 30, 2014 at 04:47 johnl at iecc.com (John Levine) wrote: > >When people talked of "virtual currency" over the years, often arguing > >that it's too hard a problem, how many described bitcoin with its > >cryptographic mining etc? > > None, but it shouldn't be hard to look at the way bitcoin works and > realize why it'd be phenomenally ill suited for e-postage, just for > technical reasons. I told Satoshi so in 2009. I wasn't suggesting bitcoin was a model for e-postage, only that a lot of papers were written saying systems like bitcoin were more or less impossible (usually based on the double-spending problem.) But bitcoin seems to have gained quite a bit of traction nonetheless though it may well still be a bad idea. The problem is the world is a very sloppy place and tends to function in spite of proofs that "bumblebees can't fly" etc. when there's a need. > R's, > John > > PS: Sometimes a WKBI really is a WKBI. -- -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 joelja at bogus.com Sun Mar 30 17:16:13 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 30 Mar 2014 10:16:13 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21304.20043.753022.886555@world.std.com> References: <21303.39300.804622.225416@world.std.com> <20140330044736.5192.qmail@joyce.lan> <21304.20043.753022.886555@world.std.com> Message-ID: <5338515D.3040507@bogus.com> On 3/30/14, 10:03 AM, Barry Shein wrote: > > The problem is the world is a very sloppy place and tends to function > in spite of proofs that "bumblebees can't fly" etc. when there's a > need. which is fortunately, mythology based on catastrophically bad modeling so your analogy is spot on. > > R's, > > John > > > > PS: Sometimes a WKBI really is a WKBI. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From bzs at world.std.com Sun Mar 30 17:59:35 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 30 Mar 2014 13:59:35 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325172328.5224.qmail@joyce.lan> <5332DF1A.9040001@pari.edu> <21300.27326.575281.57423@world.std.com> <5FFF626E-D993-4B35-AD7B-E43C93DE4D6F@delong.com> <21301.2324.18376.209669@world.std.com> <85D6865D-3EEA-468F-AEA0-F634BEE2E23D@delong.com> <21301.58989.363630.385662@world.std.com> <21303.11694.671771.160140@world.std.com> Message-ID: <21304.23431.563472.289158@world.std.com> On March 29, 2014 at 23:26 owen at delong.com (Owen DeLong) wrote: > > On Mar 29, 2014, at 1:31 PM, Barry Shein wrote: > > > > > On March 29, 2014 at 08:28 owen at delong.com (Owen DeLong) wrote: > >>> So if a spammer or junk mailer could, say, trick you into accepting > >>> mail in those schemes then they get free advertising, no postage > >>> anyhow. > >> > >> Sure, but how would they trick you into saying ?I wanted this advertising? once you?ve actually seen that it is advertising. > > > > I dunno, but they trick people all the time, isn't that what the > > entire phishing industry is based on? > > > > I guess the real point is that this idea that one would be sorting > > through their email saying don't charge for this one I want it, charge > > for this one, I don't, etc is not a good idea. > > I was envisioning a system more where you white-listed your known contacts up front, > then only needed to say ?refund this one and add to white-list? or ?refund this one? when > confronted with one that wasn?t already white-listed that you didn?t feel was spam. Introducing a refunding system adds a lot of complexity for not much advantage. Think through the mechanics of this whitelisting system, i.e., the bookkeeping and msgs back and forth. (eliding some stuff we mostly agree on) > > > > What about the costs of anti-spam technology? And all the other > > problems spam incurs? I thought that's why we were here. > > Reality is those costs are pretty much sunk at this point as well, mostly embedded into the price of internet access and mail services as they exist today. Sure, there might be some long term reductions in those costs if this worked out, but at what relative price? What about the "attention" costs, when nobody for example looks at an Amazon mail or even a useful msg from their bank because they're too busy deleting everything that isn't absolute top-priority (like from a relative or lover.) They're just swamped. Anyhow, I guess either spam is a big problem or it isn't. Everything I say is based on the premise that spam is a big problem. If it isn't then we are truly wasting our time here. > > >> Please present your definition of SPAM. I don?t see how a shipping notification, a transaction receipt, etc. could possibly be considered SPAM. > > > > My whole point is I don't WANT to have a definition of spam, except as > > a bad memory. > > > > I'm trying to figure out how to change the ecology/economics so spam > > is difficult, a minor problem. > > I get what you want, but I don?t see it as a solution due to the negative consequences described elsewhere in the thread. Well, if you don't see spam as much of a problem then surely most anti-spam proposals are going to seem too costly, right? > > > > That's sort of like saying my car can drive down the road perfectly > > well with some gasoline etc, why do I need to pay taxes for police? > > I often find myself wondering exactly that? Usually after trying to get some service or other that the police are supposed to be providing. > > Nonetheless, I get your point. OTOH, the city council, as a body, doesn?t pay taxes for police. Neither does the city, which owns quite a fleet of vehicles. So, what is your equivalent in this regime to the ?tax exempt organization?? Maybe I haven't had enough coffee yet but I truly don't understand what you're asking here. > > > > Recipients wouldn't pay in my scheme. > > OK, turn it around and you aren?t paying a separate fee for the mailman to drive by your place each day to see if you have any outgoing mail, either. You must live in some low-density population area, here in Boston the letter carriers won't take outgoing mail. I tried one day and the guy just sneered "put it in a box, that's all I'd do with it!" Obviously there are people emptying those mailboxes but it's...where are we going with this? > > > If you mean that legitimate senders have to pay and somehow recover > > that cost, well, we all pay for police and other security. Security is > > often like that. When you pay for a prison you pay to house prisoners, > > any benefit to you is at best abstract (they're not on the streets > > etc.) > > I don?t pay the USPS any separate taxes to support the postal inspectors. That?s rolled up into the postage. > > >> Further, if someone sends me something I don?t want, I can mark it ?refused, return to sender? and the post office is obliged to do so and I don?t pay anything for it. > > > > This is probably getting off-track, but are you sure about that with > > the USPS? > > Yes. For most mail, you can. Third Class and Bulk, not so much, they?ll tell you to throw it away. I don?t pay anything for that, either. Ok, nothing stops you in this scheme from returning an email to the sender. Maybe it could even be made free, probably just like any Mailer-Daemon bounce. What I don't think is a good idea is the sender getting their postage back. That's a lot of bookkeeping and I don't see any reason to bother. > > If I really want to get rid of a junk mailer (at least one who is dumb enough to send me postage-paid reply mechanisms), I?ll package up a brick, attach the reply label they provided and send it off. (lead weights, shot-bags, etc. can also be effective candidates). I?ve only used this tactic a few times, but it?s never taken more than two heavy replies to get the flow of crap to stop abruptly. I believe the USPS now throws those away. The return postage only covers a first-class letter or whatever. > > > You can mark it NSA (no such addressee) or NFA (no forwarding address) > > or NSA/NFA or even put a forwarding address which may or may not do > > anything since the recipient is supposed to set that up with the post > > office (e.g., when they move.) > > Yep. They?ll take it back and either forward it if they can or send it to the dead letter office. If it's first-class mail, that's one reason first-class costs more. > > > But I never heard of taking all my junk mail for example and handing > > it back to a letter carrier saying "Here, I don't want this!" I think > > they'd say "throw it in the trash!? > > Specifically doesn?t work with third-class and bulk. They are the only exceptions. Big exception since that's almost all of what bulk paper mailers use! > > "Related to that transaction"? Is that in CAN-SPAM? Where did that > > limitation come from? How is that defined? > > Forget current law. I?m talking about the criteria I would want to set if we were to overhaul the system and do this right. I think it's very important to eliminate any definition of spam from the system. That's just a rat hole. You stop spam by making it too expensive for spammers to operate in any effective manner. True story: I remember when I was about 16 years old I went into this place in Greenwich Village, still there I believe, "The Cafe Wha?". They didn't serve alcohol so it was someplace a 16 year old could get out of the rain and hear some live music. At the door was a guy with a coffee can, "Cover Charge: 25c" Even way back then 25c wasn't much money, about the price of a couple of packs of gum. I asked the guy: Why a 25c cover charge? He said: It keeps out the riff-raff. It keeps out the RIFF-RAFF???? 25 CENTS? He yelled back: YOU'D BE SURPRISED! Well, surely he knew his business. We're trying to keep out the riff-raff while not overburdening the honest. Maybe I should dub this the "Cafe Wha? Proposal" in their honor. > > > You mean when Network Solutions bombards me with email about each new > > TLD they're violating CAN-SPAM? I never asked for that. I do have some > > domains with them, I think they're using that for a "legitimate > > business relationship?. > > No, I never brought CAN-SPAM into this, that?s your idea. I?m talking about the criteria that could easily be used to define SPAM consistently in a way that isn?t fuzzy, doesn?t have the problems currently created by CAN-SPAM (a law written by spammers for spammers), etc. Permission to speak frankly: You want a moral component, you want this to identify the good from the bad. You keep coming back to that. I LONG AGO STOPPED CARING! I just want the spam to stop. And I think when you make that leap and let go of the moral or judgemental aspect solutions start to appear. I don't want to make better people out of spammers. I don't want to put them behind bars. I don't want to punish them. I don't want to reward the righteous (except by default, less spam!) I just want to put spammers out of business! I want to change the ecology so it makes it impossible for them to operate in any effective manner. I keep saying "effective" because sure you might get the occasional spam anyhow, particularly in the beginning as they try to save their business model, but I want to run them out of town. > > > Legitimate businesses (perhaps other than NetSol :-) do tend to > > restrain themselves and know recipients might get annoyed if they > > overdo their welcome and opt-out or even block them entirely. > > > > An example of the line getting fuzzy is when my frequent flyer sources > > (airlines etc) constantly hawk credit cards at me under the excuse > > that I'll get 50,000 free miles or some such. So it sort of sounds > > related to the frequent flyer program. > > And by allowing the user to do one of: > > Whitelist the airline > Accept each message they want (refunded, others airline pays) > Decline all messages (airline pays) Whitelist shmitelist. You're turning this into a two-way system with active feedback which is EXACTLY what I say is to be avoided. > You could decide for yourself which messages from the airline you don?t consider SPAM, with the added benefit that you get a small amount of money for each message you don?t actively claim isn?t SPAM. Easier to just toss the ones you don't want. Think this thru, you really want to look at each msg and decide if it's spam or not and if so perform some function...? Sure, some people do that sometimes, report spam, but really life is too short. I say put the spammers out of business. > > > But I think they're just hawking Amex cards and getting a commission > > for each one they sell. > > Of course they are, and I would not mark any of those messages as ?accepted? and it would cost them for each one they sent. Active feedback, bookkeeping, unnecessary. > > > As I said, I'm trying to come up with a spam-definition-neutral > > approach. > > I know, but I believe that approach to be fundamentally flawed and I am trying very hard to propose an alternative I believe could be more functional. Ya know, I can't go thru these supposed fundamental flaws one by one, show they arise from misunderstandings etc, and then come back to "I believe your approach to be fundamentally flawed". Doesn't leave me much to respond to. > > Ah, but BofA didn?t hire them to break the law. BofA hired them to send the SPAM to the list they promised BofA was entirely opt-in users who chose to receive their mails. The fact that they lied to BofA means BofA doesn?t have any liability. The fact that BofA profits from this lie without consequences means that BofA has no incentive to go after them for a refund or avoid using their services in the future. Actually, that's not true, speak to someone who understands agency law. BoA might be able to in turn sue them for breaching a contract but BoA can still be held liable. Those aren't mutually exclusive. Really, that's agency law 101. I realize people think about it for a minute and say "that's ridiculous!" but that's exactly how it works. And why business liability insurance covers events like that, or should. Intent is not a factor which tends to be the source of a lot of "folk" law beliefs like this. > > Well, there are all sorts of hard cases, but laying it out sometimes > > surprises people (like, yes you can be held responsible for the > > actions of a hired bodyguard, even if their behavior was way out of > > line. They sell insurance for that kind of thing.) > > Sure, but the spammers happily cover BofA?s ass contractually and then say ?oops? or ?we lied? or whatever they have to in order to get BofA off the hook. Then, nobody gets punished and business as usual. Review agency law. BoA can be held liable. BoA can in turn sue the spammer, if they like, to recover. That avoids precisely what you're suggesting, transferring liability to a judgement-proof entity. Yes that can still be done in many cases but not as you describe. But why are we here exactly? > > >>> Maybe something would happen, I can't say for sure. > >>> > >>> But I suspect they'd round file it because hey that's BANK OF AMERICA > >>> not SPAMMERS and you're just a KOOK! > >> > >> No, more likely they?d review the headers and point out to me that there?s no evidence it was actually sent BY BofA, because most likely it wasn?t sent by BofA, but by someone they may or may not have contracted. > > > > Well, now we're really just moving the goalpost and changing the > > scenario. > > No, I?m pointing out how organizations like BofA actually do this and you?re talking about some fictitious scenario that doesn?t happen in real life. > > Yes, BofA and SPAM-Inc. move the goalpost and change the scenario, but that?s also why most telco-contracted backhoe operating companies have numbers in their name? Ho-Co #1 cut someone?s fiber, so they sold their substantial assets to Ho-Co #2 for a song to pay their legal fees, then went chapter 13 before the case could make it to court. Chapter 13 is personal bankruptcy. > > > > Of course it is. If your email won't be accepted without proper > > postage attached then that's the cost of having your email delivered. > > No, that?s a protection racket/extortion scheme. Oh c'mon, then so is every other situation where you have to pay for something, including credentials. Are SSL certs a protection racket/extortion scheme? > > > Ok, I think a lot of the rest of this could be answered by: > > > > It would be interesting to ask a spammer or ex-spammer what they > > thought about the scheme. > > LoL I'm serious! I wouldn't consider investing a dime without talking to some spammers or ex-spammers of note. There're a few of them who'd probably be glad to talk for some prison canteen credits. -- -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 Valdis.Kletnieks at vt.edu Sun Mar 30 18:40:09 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 30 Mar 2014 14:40:09 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: Your message of "Sat, 29 Mar 2014 18:05:39 -0700." References: <5332DF1A.9040001@pari.edu> <20140326165952.13291.qmail@joyce.lan> Message-ID: <107762.1396204809@turing-police.cc.vt.edu> On Sat, 29 Mar 2014 18:05:39 -0700, Matthew Petach said: > system, which does 100,000,000 transactions/day. Facebook's > presentation talks about doing billions *per second*, which if I Fortunately for Facebook, they don't have to worry about double-spending problems, and you don't have to worry that much about authentication and security, because you control both ends of the transaction. It's easy to scale when you don't have to worry about the hard parts. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mansaxel at besserwisser.org Sun Mar 30 20:40:07 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 30 Mar 2014 22:40:07 +0200 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <99E849E6-C7B3-4A92-B02B-018CB7FD484D@ianai.net> References: <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> <20140329071508.GJ10032@besserwisser.org> <99E849E6-C7B3-4A92-B02B-018CB7FD484D@ianai.net> Message-ID: <20140330204006.GA30533@besserwisser.org> Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Sat, Mar 29, 2014 at 11:06:11AM -0400 Quoting Patrick W. Gilmore (patrick at ianai.net): > Composed on a virtual keyboard, please forgive typos. > > > On Mar 29, 2014, at 3:15, M?ns Nilsson wrote: > > Quoting John R. Levine (johnl at iecc.com): > >>> Ergo, ad hominem. Please quit doing that. > >>> As a side note I happen to run my own mail server without spam filters > >>> -- it works for me. I might not be the norm, but then again, is there > >>> really a norm? (A norm that transcends SMTP RFC reach, that is -- > >> > >> I know a lot of people who run a lot of mail systems, and let's just > >> say you're so far out in the long tail we need a telescope to see > >> you. > > > > I will not debate with people who resort to humiliation techniques > > when questioned. > > I will not argue whether you were humiliated as that is something only you can decide. The puny attempt at "master suppression technique"[0] was identified as such and countermeasures were launched. No damage done. > However, John was still factually correct. No big deal, lots of people are humiliated by facts. Although I admit I didn't find the quote above terribly humiliating myself. You have a point. Further, I do not debate the truth in the statement. My personal email system IS small -- I did even state that -- but that does not mean I do not run larger systems for others, nor does it mean that the general public should dismiss my ideas and only listen to people who brag about their acquaintances. There are other much more compelling reasons not to do as I say. > Also, realize that John has already done more to stop spam in his career then you and your thousand closest friends ever will. (E.g. Look up abuse.net.) Again not humiliation, just a fact. > > Feel free to plonk me as well. I won't be humiliated. :-) I won't. There is a clear divide between politely pointing out facts and abusing facts to tell people that their opinion does not matter. And, for the record, I do not support spamming in any form. But the mitigation techniques MUST NOT impose undue constraints on the legitimate use of e-mail, even when it is not vetted by passing it through big insecure monitored US webmail providers. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Vote for ME -- I'm well-tapered, half-cocked, ill-conceived and TAX-DEFERRED! [0] http://en.wikipedia.org/wiki/Master_suppression_techniques -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From rdrake at direcpath.com Sun Mar 30 23:58:37 2014 From: rdrake at direcpath.com (Robert Drake) Date: Sun, 30 Mar 2014 19:58:37 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <21303.39300.804622.225416@world.std.com> References: <21303.11694.671771.160140@world.std.com> <20140329223724.3994.qmail@joyce.lan> <21303.26502.281987.205590@world.std.com> <21303.39300.804622.225416@world.std.com> Message-ID: <5338AFAD.5080907@direcpath.com> On 3/30/2014 12:11 AM, Barry Shein wrote: > I don't know what "WKBI" means and google turns up nothing. I'll guess > "Well Known Bad Idea"? > > Since I said that I found the idea described above uninteresting I > wonder what is a "WKBI" from 1997? The idea I rejected? > > Also, I remember ideas being shot down on the ASRG (Anti-Spam Research > Group) list primarily because they would take ten years to gain > acceptance. > > Over ten years ago. > > Maybe they were bad ideas for other reasons. Some certainly were. > > But there's this tone of off-the-cuff dismissal, oh that would take > TEN YEARS to gain traction, or that's a WKBI, which I don't find > convincing. > > I read your paper, for example, and said it's a nice paper. > > But I don't find it compelling to the degree you seem to want it to be > because it mostly makes a bunch of assumptions about how an e-postage > system would work and proceeds to argue that the particular model you > describe (and some variants) creates impossible or impractical > hurdles. > > But what if it worked differently? > > At some point you're just reacting to the term "e-postage" and > whatever it happens to mean to you, right? Imagine living in a world where this system is implemented. Then imagine ways to break it. The first thing I can think of is money laundering through hundreds of source and destination email accounts. The second is stolen identities or credit cards where the money doesn't exist to begin with (Who pays when this happens?) Third is administrative overhead. Banks/paypal/exchanges/someone is going to want a cut for each transaction, and they deserve one since they're going to end up tracking all of them and need to be able to reverse charges when something goes wrong. But then you have a central point of failure and central monitoring point so you want to involve multiple exchanges, banks, etc. Then you've got a dictatorship somewhere who says they want an extra $0.03 tacked on to each transaction, only it's not $0.03 it's so any mail that goes to that country has to have custom rules that fluctuate multiple times a day. Then there is my mom, who knows just enough about computers to send cat pictures and forward me chain letters. She'll not understand that email costs something now, or how to re-up her email account when it runs out. The administrative burden will either fall to me or her ISP, and each phone call to the ISP probably costs them $$ because they must pay a live human to walk someone through email. > You can't really say you've exhaustively worked out every possibility > which might be labelled "e-postage". Only a particular interpretation, > a fairly specific model, or a few. > > When people talked of "virtual currency" over the years, often arguing > that it's too hard a problem, how many described bitcoin with its > cryptographic mining etc? > > Bitcoin might well be a lousy solution. But there it is nonetheless, > and despite the pile of papers which argued that this sort of thing > was impossible or nearly so. > > Note: Yes, I can also argue that Bitcoin is not truly a virtual > currency. > > Sometimes a problem is like the Gordian Knot of ancient lore which no > one could untie. And then Alexander The Great swung his sword and the > crowds cried "cheat!" but he then became King of Asia just as > prophesized. > > > > > Regards, > > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > > Please consider the environment before reading this e-mail. http://jl.ly > The answer is that you can't do this to SMTP. Nobody will ever have the answers to all the questions involved with adding cost transactions to the protocol. The only way to do this is to reboot with a new protocol that people start to adopt, and the only way they'll do that is if it's markedly better than the old way. You have to remember some people when given the choice of paying for email or accepting 10 spams/day will opt for accepting a little spam. The good news is, with email consolidated into 5 or so large providers and most people using webmail or exchange, you've got an opportunity to change the backend. Not much software has to be modified, but you do need those large providers to buy-in to the idea. From mpetach at netflight.com Mon Mar 31 00:00:51 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 30 Mar 2014 17:00:51 -0700 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <5332DF1A.9040001@pari.edu> <20140326165952.13291.qmail@joyce.lan> Message-ID: On Sat, Mar 29, 2014 at 7:40 PM, John R. Levine wrote: > The numbers you list in your argument against a micropayment >> system being able to function are a fraction of the number of >> transactions Facebook deals with in updating newsfeeds for >> the billion+ users on their system.[0] >> > > ... which is completely irrelevant because they don't have a double > spending problem. Sheesh. It's easy to scale up stuff that is trivially > parallelizable.* > Apparently, in the intervening 10 years since you wrote that, you might have missed some advances in the state of the art in computer science. http://arxiv.org/abs/0802.0832v1 I quote from the abstract: " Contrary to the commonly held belief that this is fundamentally impossible, we propose several solutions that do achieve a reasonable level of double spending prevention" I suggest you update your 'commonly held belief' that the double spending problem is intractable. ;) > > Also, I wrote that ten years ago. Add an extra zero or two to the numbers > if you want, but it doesn't make any difference. Perhaps the number of zeroes doesn't make a difference; but solving the double spending problem would seem to play a much bigger role in making a difference to your conclusion from ten years ago. Note that one of the concepts around the double spending problem is that of offline spending being able to happen in massively large scale in very short time before the network is rejoined; however, in the case of email, that situation is largely a dead end; if you're not online, you're not going to be making very many mail connections. What may have been seen as impossible ten years ago may now be completely feasible. ^_^; > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > * - a term of art, look it up > > Thanks! Matt From johnl at iecc.com Mon Mar 31 00:42:46 2014 From: johnl at iecc.com (John R. Levine) Date: 30 Mar 2014 20:42:46 -0400 Subject: e-postage still doesn't work, why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <5332DF1A.9040001@pari.edu> <20140326165952.13291.qmail@joyce.lan> Message-ID: > " Contrary to the commonly held belief that this is fundamentally > impossible, we propose several solutions that do achieve a reasonable level > of double spending prevention" Yes, that's Bitcoin's claim to fame. > Perhaps the number of zeroes doesn't make a difference; but solving the > double spending problem would seem to play a much bigger role in making > a difference to your conclusion from ten years ago. Note that one of > the concepts around the double spending problem is that of offline > spending being able to happen in massively large scale in very short > time before the network is rejoined; however, in the case of email, that > situation is largely a dead end; if you're not online, you're not going > to be making very many mail connections. If you actually care about this, you might consider what would happen to the Bitcoin blockchain if it were attacked with millions of double spending transactions. This paper claims it can't prevent double spending, only prevent overspending by a factor of 100, which may be of theoretical interest but isn't of much practical use. We already know how to do approximate bulk counting. Oh, and on the last page, they think that hashcash works, to limit transaction rates. Anyway, if you reread my paper from a decade ago, the bank problem is only one of many problems with e-postage, each of which is fatal. R's, John From patrick at ianai.net Mon Mar 31 04:17:19 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 31 Mar 2014 00:17:19 -0400 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <20140330204006.GA30533@besserwisser.org> References: <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> <20140329071508.GJ10032@besserwisser.org> <99E849E6-C7B3-4A92-B02B-018CB7FD484D@ianai.net> <20140330204006.GA30533@besserwisser.org> Message-ID: <73F5375D-20DA-49E6-A5B1-4A083B8CE4E8@ianai.net> On Mar 30, 2014, at 16:40 , M?ns Nilsson wrote: > Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Sat, Mar 29, 2014 at 11:06:11AM -0400 Quoting Patrick W. Gilmore (patrick at ianai.net): >>> On Mar 29, 2014, at 3:15, M?ns Nilsson wrote: >>> Quoting John R. Levine (johnl at iecc.com): >>>>> Ergo, ad hominem. Please quit doing that. >>>>> As a side note I happen to run my own mail server without spam filters >>>>> -- it works for me. I might not be the norm, but then again, is there >>>>> really a norm? (A norm that transcends SMTP RFC reach, that is -- >>>> >>>> I know a lot of people who run a lot of mail systems, and let's just >>>> say you're so far out in the long tail we need a telescope to see >>>> you. >>> >>> I will not debate with people who resort to humiliation techniques >>> when questioned. >> >> I will not argue whether you were humiliated as that is something only you can decide. > > The puny attempt at "master suppression technique"[0] was identified > as such and countermeasures were launched. No damage done. I was serious. Your reaction .. well, I shouldn't say anything more lest you call me puny again. (What were you saying about humiliation techniques? Glad to see you would never be hypocritical.) >> However, John was still factually correct. No big deal, lots of people are humiliated by facts. Although I admit I didn't find the quote above terribly humiliating myself. > > You have a point. Further, I do not debate the truth in the statement. My > personal email system IS small -- I did even state that -- but that does > not mean I do not run larger systems for others, nor does it mean that > the general public should dismiss my ideas and only listen to people > who brag about their acquaintances. There are other much more compelling > reasons not to do as I say. You misunderstand. Or perhaps I did? I read John's statement to be in reference to your stance, i.e. running without spam filters. Not that your server is small. John can clarify if he likes. But either way, running without spam filters is beyond unusual these days. My personal server is run with very few filters, all of which REJECT or accept and send to a box I read. I have no "spam folder". So while I am not as far down the tail as you are, I am definitely out of the mainstream. The only reason I mention that is so you don't go researching for another reason to "identify" my comments as anything except exactly what they say. >> Also, realize that John has already done more to stop spam in his career then you and your thousand closest friends ever will. (E.g. Look up abuse.net.) Again not humiliation, just a fact. >> >> Feel free to plonk me as well. I won't be humiliated. :-) > > I won't. There is a clear divide between politely pointing out facts > and abusing facts to tell people that their opinion does not matter. > > And, for the record, I do not support spamming in any form. But the > mitigation techniques MUST NOT impose undue constraints on the legitimate > use of e-mail, even when it is not vetted by passing it through big > insecure monitored US webmail providers. I like your use of MUST. However, I think you'll find your definition of "undue" and most of the rest of the Internet's is vastly different. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From LarrySheldon at cox.net Mon Mar 31 04:38:48 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 30 Mar 2014 23:38:48 -0500 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: References: <20140325234813.41B5511CD233@rock.dv.isc.org> <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> <20140329071508.GJ10032@besserwisser.org> <99E849E6-C7B3-4A92-B02B-018CB7FD484D@ianai.net> <20140330204006.GA30533@besserwisser.org> Message-ID: <5338F158.4080801@cox.net> On 3/30/2014 11:17 PM, Patrick W. Gilmore wrote: > On Mar 30, 2014, at 16:40 , M?ns Nilsson wrote: >> Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Sat, Mar 29, 2014 at 11:06:11AM -0400 Quoting Patrick W. Gilmore (patrick at ianai.net): >>>> On Mar 29, 2014, at 3:15, M?ns Nilsson wrote: >>>> Quoting John R. Levine (johnl at iecc.com): >>>>>> Ergo, ad hominem. Please quit doing that. >>>>>> As a side note I happen to run my own mail server without spam filters >>>>>> -- it works for me. I might not be the norm, but then again, is there [snip] > However, I think you'll find your definition of "undue" and most of the rest of the Internet's is vastly different. > Seems like I got chased off of NANOG for less, in years gone by....... -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mansaxel at besserwisser.org Mon Mar 31 10:30:14 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 31 Mar 2014 12:30:14 +0200 Subject: why IPv6 isn't ready for prime time, SMTP edition In-Reply-To: <73F5375D-20DA-49E6-A5B1-4A083B8CE4E8@ianai.net> References: <20140326004546.825AD11CD8C8@rock.dv.isc.org> <20140326183226.GE10032@besserwisser.org> <20140327092231.GH10032@besserwisser.org> <20140329071508.GJ10032@besserwisser.org> <99E849E6-C7B3-4A92-B02B-018CB7FD484D@ianai.net> <20140330204006.GA30533@besserwisser.org> <73F5375D-20DA-49E6-A5B1-4A083B8CE4E8@ianai.net> Message-ID: <20140331103014.GC30533@besserwisser.org> Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Mon, Mar 31, 2014 at 12:17:19AM -0400 Quoting Patrick W. Gilmore (patrick at ianai.net): > On Mar 30, 2014, at 16:40 , M?ns Nilsson wrote: > > Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Sat, Mar 29, 2014 at 11:06:11AM -0400 Quoting Patrick W. Gilmore (patrick at ianai.net): > >>> On Mar 29, 2014, at 3:15, M?ns Nilsson wrote: > >>> Quoting John R. Levine (johnl at iecc.com): > >>>>> Ergo, ad hominem. Please quit doing that. > >>>>> As a side note I happen to run my own mail server without spam filters > >>>>> -- it works for me. I might not be the norm, but then again, is there > >>>>> really a norm? (A norm that transcends SMTP RFC reach, that is -- > >>>> > >>>> I know a lot of people who run a lot of mail systems, and let's just > >>>> say you're so far out in the long tail we need a telescope to see > >>>> you. > >>> > >>> I will not debate with people who resort to humiliation techniques > >>> when questioned. > >> > >> I will not argue whether you were humiliated as that is something only you can decide. > > > > The puny attempt at "master suppression technique"[0] was identified > > as such and countermeasures were launched. No damage done. > > I was serious. Your reaction .. well, I shouldn't say anything more lest you call me puny again. (What were you saying about humiliation techniques? Glad to see you would never be hypocritical.) My apologies. I was not refering to your statement -- if that was not clear I should most certainly have written more clearly. > >> However, John was still factually correct. No big deal, lots of people are humiliated by facts. Although I admit I didn't find the quote above terribly humiliating myself. > > > > You have a point. Further, I do not debate the truth in the statement. My > > personal email system IS small -- I did even state that -- but that does > > not mean I do not run larger systems for others, nor does it mean that > > the general public should dismiss my ideas and only listen to people > > who brag about their acquaintances. There are other much more compelling > > reasons not to do as I say. > > You misunderstand. Or perhaps I did? > > I read John's statement to be in reference to your stance, i.e. running without spam filters. Not that your server is small. I read "you handle no big amount of e-mail and I know people who do and therefore you should STFU and not bother us with your silly ideas about following standards" in Johns message, and while that might seen like one of many interpretations of what was written, it is an interpretation I hope to be not so far out on the insulted fringe so as to be silly. > John can clarify if he likes. But either way, running without spam filters is beyond unusual these days. Indeed. > My personal server is run with very few filters, all of which REJECT or accept and send to a box I read. I have no "spam folder". So while I am not as far down the tail as you are, I am definitely out of the mainstream. The only reason I mention that is so you don't go researching for another reason to "identify" my comments as anything except exactly what they say. Oh, I'm not hoping to pick a fight. Bad move to pick fights with people that function as mediators. > >> Also, realize that John has already done more to stop spam in his career then you and your thousand closest friends ever will. (E.g. Look up abuse.net.) Again not humiliation, just a fact. > >> > >> Feel free to plonk me as well. I won't be humiliated. :-) > > > > I won't. There is a clear divide between politely pointing out facts > > and abusing facts to tell people that their opinion does not matter. > > > > And, for the record, I do not support spamming in any form. But the > > mitigation techniques MUST NOT impose undue constraints on the legitimate > > use of e-mail, even when it is not vetted by passing it through big > > insecure monitored US webmail providers. > > I like your use of MUST. > > However, I think you'll find your definition of "undue" and most of the rest of the Internet's is vastly different. I'm fully aware of that. The clear separation between network and application that is at the core of IP is easily compromised by the best intentions. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I selected E5 ... but I didn't hear "Sam the Sham and the Pharoahs"! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From akaradag at NETAS.com.tr Mon Mar 31 12:17:24 2014 From: akaradag at NETAS.com.tr (Anil KARADAG) Date: Mon, 31 Mar 2014 12:17:24 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> Message-ID: Hi Paul, Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? Thanks -----Original Message----- From: Paul Bertain [mailto:paul at bertain.net] Sent: Tuesday, March 25, 2014 10:47 PM To: Anil KARADAG Cc: nanog at nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. Paul > On Mar 24, 2014, at 11:46 PM, Anil KARADAG wrote: > > Hi, > > I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. > > I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. > > thanks > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From rdobbins at arbor.net Mon Mar 31 12:19:42 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 31 Mar 2014 12:19:42 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> Message-ID: <4C468D30-5072-4F9F-ABFC-A1827C76D775@arbor.net> On Mar 31, 2014, at 7:17 PM, Anil KARADAG wrote: > However, we need the source port to be the same on the destination servers. Out of curiosity, why? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From email at edylie.net Mon Mar 31 12:23:13 2014 From: email at edylie.net (Pui Edylie) Date: Mon, 31 Mar 2014 20:23:13 +0800 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> Message-ID: <53395E31.7020002@edylie.net> Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: > Hi Paul, > > Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? > > Thanks > > -----Original Message----- > From: Paul Bertain [mailto:paul at bertain.net] > Sent: Tuesday, March 25, 2014 10:47 PM > To: Anil KARADAG > Cc: nanog at nanog.org > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > Hi Anil, > > Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. > > Paul > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG wrote: >> >> Hi, >> >> I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. >> >> I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. >> >> thanks >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. >> ------------------------------------------------------- >> This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From akaradag at NETAS.com.tr Mon Mar 31 12:51:03 2014 From: akaradag at NETAS.com.tr (Anil KARADAG) Date: Mon, 31 Mar 2014 12:51:03 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: <53395E31.7020002@edylie.net> References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> <53395E31.7020002@edylie.net> Message-ID: Hi, Thanks for solution but I cannot use it, because backend servers must know netscaler snip ip for clients. So I need fixed proxy port to communication with backend servers. -----Original Message----- From: Pui Edylie [mailto:email at edylie.net] Sent: Monday, March 31, 2014 3:23 PM To: Anil KARADAG; Paul Bertain Cc: nanog at nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: > Hi Paul, > > Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? > > Thanks > > -----Original Message----- > From: Paul Bertain [mailto:paul at bertain.net] > Sent: Tuesday, March 25, 2014 10:47 PM > To: Anil KARADAG > Cc: nanog at nanog.org > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > Hi Anil, > > Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. > > Paul > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG wrote: >> >> Hi, >> >> I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. >> >> I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. >> >> thanks >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. >> ------------------------------------------------------- >> This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From David.Siegel at Level3.com Mon Mar 31 22:34:08 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Mon, 31 Mar 2014 22:34:08 +0000 Subject: 3356 leaking routes out 3549 lately? In-Reply-To: References: <20140328194212.GB43550@2bithacker.net> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC06A39AF88@USIDCWVEMBX05.corp.global.level3.com> There shouldn't be any reason for this happening. Our network integration work generally involves moving a customer ASN from behind 3549 to be behind 3356, and once moved is generally permanent. In some cases, 3356 provides transit for 3549 to get to some peers that have been consolidated onto 3356, which would create a 3356 3549 path, but not the one you outline in your note, which implies 3549 providing transit for 3356. To my knowledge, and the guy I check with in engineering, we are not intentionally doing that anywhere. So, if you see this problem continue, please open a ticket and escalate it if you don't get a good response. Dave -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Friday, March 28, 2014 2:32 PM To: chip at 2bithacker.net Cc: nanog at nanog.org Subject: Re: 3356 leaking routes out 3549 lately? On Mar 28, 2014, at 3:42 PM, Chip Marshall wrote: > On 2014-03-28, David Hubbard sent: >> Has anyone had issues with Level 3 leaking advertisements out their >> Global Crossing AS3356 for customers of 3549, but not accepting the >> traffic back? We've been encountering this more and more recently, >> bgpmon always detects it, and all we ever get from them is there's >> nothing wrong. Today it affected CloudFlare's ability to talk to us. >> It seems to happen mostly with Europe and Asian peering points. >> Typically lasts five to ten minutes which makes me think someone >> working on merging the two networks is doing some 'no one will notice this' >> changes in the middle of the night. > > I'm not sure if it's the same thing, but I've had a few alerts from > Renesys lately seeing a path to my AS via GLBX 3549 that shouldn't > exist, as we only have connections with Level 3 3356. > > For example, Renesys reports "x 3549 33517" where it should only be > able to see "x 3356 33517" or maybe "x 3549 3356 33517". > > (Due to Renesys policy, I can't know what x is) It's been a few years i think now since the "level-crossing" merger so I'm certainly not surprised to see them doing work on this front. This often happens during integration work, and networks of that scale I would imagine tools that detect routing leaks need to account for this merger activity. I can see I need to update my tools :) http://puck.nether.net/bgp/leakinfo.cgi?search=do&search_prefix=&search_aspath=3549_3356&search_asn=&recent=1000 http://puck.nether.net/bgp/leakinfo.cgi?search=do&search_prefix=&search_aspath=3356_3549&search_asn=&recent=1000