From saku at ytti.fi Mon Jul 1 07:24:40 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 1 Jul 2013 10:24:40 +0300 Subject: Egress filters dropping traffic In-Reply-To: References: Message-ID: <20130701072440.GA9940@pob.ytti.fi> On (2013-06-30 22:04 +0530), Glen Kent wrote: > Under what scenarios do providers install egress ACLs which could say for > eg. > > 1. Allow all IP traffic out on an interface foo if its coming from source > IP x.x.x.x/y > 2. Drop all other IP traffic out on this interface. Question seems to be 'when do you need to drop packets', I'm sure 10 different people would give 10 different use-cases. One use-case for this particular ACL is that the interface is used for MGMT only, so you allow NMS network and drop everything else. -- ++ytti From jerome at ceriz.fr Mon Jul 1 08:45:37 2013 From: jerome at ceriz.fr (=?windows-1252?Q?J=E9r=F4me_Nicolle?=) Date: Mon, 01 Jul 2013 10:45:37 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C9662F.9000106@gmail.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> <51C9662F.9000106@gmail.com> Message-ID: <51D141B1.7060407@ceriz.fr> Le 25/06/2013 11:43, Arturo Servin a ?crit : > And this presentation by Geoff Huston: Thanks ! Funny thing is, the IPv4 table projection looks accurate for now. Does it seem plausible to establish a backpressure model over a longer period now we have some more data about new allocation policies and general behavior ? -- J?r?me Nicolle 06 19 31 27 14 From jeroen at massar.ch Mon Jul 1 10:05:59 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 01 Jul 2013 12:05:59 +0200 Subject: SixXS Contact In-Reply-To: References: Message-ID: <51D15487.8080000@massar.ch> [several replies in one (hence cc's) to not clutter the list with non-really-nanog stuff, but it kinda deserves a reply, reply-to set to where these things should be going in the first place] [TLDR: contact = info at sixxs.net, mail queue is long, human time is limited, if you have lots of users some will feel wronged] On 2013-06-27 16:17, K. M. Peterson wrote: > Are there any SixXS admins who read this list? Several, but it is not the contact point. Note that if you had searched the NANOG archives, or googled, or read the SixXS website this would have been clear. But let me nevertheless answer these comments and then return to normal live, real work and then in our spare times processing the request queues and the insane backlog of email. > I seem to have committed a > faux pas with respect to requesting an account, and I'm not getting any > responses to my attempts (to info at sixxs.net) to clear up the issue. In that mailbox there are currently 6396 unreplied messages, this is spread over the last several years though (and some back-dated spam that passed the filters creeps in there too). We used to have a near real time statistic at http://www.sixxs.net/misc/operstats/ indicating that, due to infrastructure changes though this does not show anymore there though. Your message is thus among those unreplied ones (I quickly see 3 in the mail queue). Unfortunately things that are not automated have to be handled by humans and time is a rather limited resource (and getting good people who help along is a very tricky thing as we have found out; hints appreciated). We would love to have more time for SixXS, but there are unfortunately only 24 hours in a day and many of that is used for real life. Just in case: we make it a point to not prefer handling one persons case over the rest of them. They all get handled in turn. (LIFO style in typical case, and sometimes we then jump back a lot to resolve a few of those too, but pretty much at random) On 2013-06-27 16:47, Anthony Williams wrote:> > > > Can I piggy back on that inquiry and request a reset of my ISK points > after committing a faux pas with respect to going negative from down v6 > tunnels and deleting. Now to create a new tunnel I need positive ISK > points and I'm stilling at -10 with no way to boost my numbers. :( > > Reset Points: AWJ11-SIXXS Oh Pretty please w/sugar on top. :) You deleted the two working tunnels you had, adding a few credits does not resolve your problem as you have been answered in email. Resetting your credit would quite well make the credit system useless as people could then just waste it all, not maintain their connection and then ask for more, but we have other ways of solving problems like this. On 2013-06-27 21:43, M?ns Nilsson wrote: > Personally, even though I'm on the same IRC channel as one of the > admins and could have all support I want Extremely interesting statement. As I am sure you are not on the IRC channel that I do actually idle at... and even if you where, SixXS does not do help on IRC or for specific people, see above and the site. On 2013-06-28 13:48, M?ns Nilsson wrote: > > Apparently I'm not on the same IRC channel as an admin anymore: > > "Just let me state that the day after I quit working with SIXXS I got myself a HE tunnel" I am really wondering which "admin" you mean, and "working" is impossible as it is just all done in free time. Please read the about page, and you'll realize there are only two people who 'are' SixXS, both of us have lots of native connectivity and for the left-over locations have a wide array of SixXS PoPs to choose out of thus no need for alternates; though in case of throughput/latency being better and the need would be there that would of course be a better and thus logical choice. Also note that anybody who really is with SixXS would write "SixXS" and not everything in caps as they know the difference in writing style and the reason why it is written that way. (The same trick with people writing TOR which would mean Top Of Rack, not Tor as in Tor Project) On 2013-06-27 22:00, Andrew D Kirch wrote:[..] > Yes it's a private service, yes it's run by volunteers, BUT SIXXS is > publicly putting themselves forward as ambassadors for IPv6. "The main > target is to create a common portal to help company engineers find their > way with IPv6 networks deploying IPv6 to their customers > in a rapid and > controllable fashion." (Sixxs website) and "For whom? For everybody. > The average joe and jane can use AICCU so that they can use IPv6 very > quick and easy." (SIXXS website "about us"). That is all correct. And I am actually extremely convinced that we have overreached every single one of the goals that we have set out to achieve: http://www.sixxs.net/faq/sixxs/?faq=why > I'm neither Joe nor Jane, > nor am I Tom, Dick, or Harry, and quite frankly SIXXS has been > abrasive > and abusive in my attempt to use their service. Yes, it is really hard for some people to realize that we have a very clear "do not sign up multiple times" policy. Instead of contacting us first and getting your expired/unmaintained ARIN record converted into something that worked, you signed up again, and then with a bouncing email address. On top of that you keep on making snarky comments, without any merit or backing, on a public mailing list. As you might expect, nobody is going to help you solve your problem that way, especially when there are other people who are waiting nicely to get their problem resolved. > Their stewardship of IPv6 is quite frankly horrible. Thank you for thinking that we have any kind of "stewardship of IPv6", I am sure you are confusing us with the IETF and maybe much more the companies that provide IPv6 connectivity globally along with all the hardware vendors. Please note that SixXS is just at the edge of IPv6, the people from the ISPs who are present on NANOG are the ones at the core, we just try to help out where we can. > When people on NANOG are complaining > about lack of response, SIXXS responds with silence or "we're a > volunteer group". Since when is NANOG the list for complaining about public internet services? (I cannot think of a service similar to SixXS's structure, thus unfortunately I can't google/bing/yahoo for any complaints about those). I also like to hint to http://www.sixxs.net/r/makeitbetter and if you have a complaint to file it at info at sixxs.net with actual arguments and reasoning. Please note though that indeed we will point you to our FAQ and the big warnings that exist on the website. Thus indeed your "I signed up multiple times" gets pointed at the for you familiar place. As you are on NANOG and have been complaining quite a while already, what have you done, as an operator, to get IPv6 to your network and services? I can only assume that it will be close to zero, otherwise, for what are you caring so much about that SixXS account? > I was told to go screw myself because I'd had a work > account years ago and tried to set up a personal one not even > realizing > the work account was still active (totally allowed by their TOS), my > account was still canceled, and three weeks later Jeroen essentially > told me I could go screw myself. You are contradicting yourself here by first starting that you where told to go s* yourself and then that you where 'essentially told' to do so. I am very sure that I would never use that language. For the record, this is the answer you received: "Instead of contacting us first, you just went ahead against the signup page's instructions. How much clearer can we make the contact page and the signup so that this would not occur to you?" Sounds a lot less bad than you try to describe it, also you never answered that message. > I'm the community manager at Zenoss > and I'd get fired for treating my users like that. You mean "Zenoss.com" right, the commercial entity? How does that compare to a spare time project that grew out of hand? That is the thing with a "a privately conducted development of software and services." you can't get "fired" from that, there is no boss, as we are the boss and we do it in our free spare time. The only thing we can do is just give up on helping people when we get too over tired of complainers like you. Instead of doing that though, we keep it running. Yes, we might not be able to help every single soul on the planet, but we are helping the ones who do follow the simple procedures we have in place. > I think it's _LONG_ past time we started asking "how severely has > SIXXS's negative behavior slowed the adoption of IPv6?", and "is this > behavior acceptable?" Exactly what 'SIXXS's negative behavior' has slowed adoption of IPv6? We have currently over 35k active users, amongst which a large technical audience, certainly these people are helped. We have developed several protocols/tools to enable IPv6 in various places. We have helped define the IPv6 standards and solve/identify corner cases in those standards. Next to that the many ISPs that we helped to get native IPv6, the GRH service that we provide to debug issues and the many many times we have reached out to providers to resolve problems in IPv6 connectivity. Oh and not forgetting that little traffic generator called IPv6Gate, you would be surprised to see how that is used (my NANOG presentation has details though in case you missed it). > For me, their service is long past worse than no service at all. You only used the service for 39 weeks next to several months of your tunnel not pinging. That tunnel was used another two years by the person who we transfered it to, on your request. That you forgot you had an ARIN handle, didn't bother to update that, let your mail bounce and signed up again, is not much we can do about. Also you are very obviously missing the very big point that SixXS is only one of many many solutions for getting you IPv6 connectivity. To list a few direct alternatives: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers And indeed, the alternatives might lack features (AYIYA/TIC/AICCU which we developed ourselves, though gogo6 has TSP on their end), but that does not make SixXS the only service there is. There is lots of choice. Also please note that we are always advocating that people use native IPv6 (see also the 'why' FAQ with the targets above). Hence also why we maintain these two FAQs: http://www.sixxs.net/faq/connectivity/?faq=native http://www.sixxs.net/faq/connectivity/?faq=ipv6transit As you are thinking so badly about SixXS, I suggest that you use your options, go somewhere else, or better, after 7 years (2013 now, you signed up in 2006) finally get your head out of the sand and get that native IPv6 connectivity arranged. Greets, Jeroen From dhill at mindcry.org Mon Jul 1 14:34:21 2013 From: dhill at mindcry.org (David Hill) Date: Mon, 1 Jul 2013 10:34:21 -0400 Subject: www.att.net ipv6 traceroute Message-ID: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> Anyone else noticing odd ipv6 traceroutes to www.att.net (2001:1890:1c01:2::40)? For example, the first traceroute originating in Chicago, and if the hostnames are anything to go by: Chicago -> Dallas -> Atlanta -> Miama -> NYC -> Amsterdam -> Frankfurt -> France -> D.C. -> Atlanta... The first 2 traceroutes are on SixXs tunnels and the third is native. From 2604:8800::/32 (Chicago, Sixxs) 2 gw-122.chi-03.us.sixxs.net 25.925 ms 14.816 ms 13.645 ms 3 uschi03.sixxs.net 18.651 ms 15.544 ms 34.06 ms 4 2620:0:6b0:a::1 27.401 ms 15.677 ms 14.83 ms 5 tge6-3.fr3.ord4.ipv6.llnw.net 14.482 ms 18.875 ms 21.112 ms 6 ve8.fr3.ord.ipv6.llnw.net 28.965 ms 24.031 ms 15.947 ms 7 tge2-1.fr3.dal.ipv6.llnw.net 39.672 ms 41.431 ms 49.888 ms 8 tge4-1.fr3.atl1.ipv6.llnw.net 59.908 ms 62.198 ms 72.244 ms 9 tge2-1.fr3.mia1.ipv6.llnw.net 78.641 ms 75.351 ms 74.425 ms 10 2600:804:11f::11 91.243 ms 90.002 ms 87.802 ms 11 2600:802::23 119.804 ms 100.727 ms 100.737 ms 12 ge-0-3-0.IL1.NYC12.ALTER.NET 147.803 ms 145.406 ms 147.878 ms 13 ae1.XT2.AMS2.ALTER.NET 148.699 ms ae1.XT1.AMS2.ALTER.NET 146.322 ms 152.503 ms 14 GigabitEthernet6-0-0.GW5.AMS6.ALTER.NET 145.967 ms 148.903 ms 165.926 ms 15 FastEthernet0-0.6B1.AMS6.ALTER.NET 183.716 ms 156.131 ms 194.141 ms 16 tu3.6B1.FFT4.ALTER.NET 184.867 ms 184.005 ms 170.47 ms 17 ffm-s1-rou-1006.DE.eurorings.net 159.565 ms * 173.012 ms 18 ffm-s1-rou-1102.DE.eurorings.net 200.82 ms 225.979 ms 207.712 ms 19 kehl-s2-rou-1103.DE.eurorings.net 228.884 ms 208.576 ms 203.722 ms 20 nntr-s1-rou-1101.FR.eurorings.net 192.901 ms 210.818 ms 210.279 ms 21 * 2001:680:0:134:222:226:160:1 189.452 ms 171.714 ms 22 2001:1890:c00:c001::1171:ecca 192.306 ms 164.33 ms 192.835 ms 23 2001:1890:c00:c001::ee71:ecca 222.488 ms 218.21 ms 194.537 ms 24 2001:1890:ff:ffff:12:122:105:90 214.309 ms 216.21 ms 216.51 ms 25 wswdc22crs.ipv6.att.net 206.215 ms 220.884 ms 202.472 ms 26 attga21crs.ipv6.att.net 213.776 ms 220.918 ms 205.205 ms 27 attga409me3.ipv6.att.net 190.66 ms 228.532 ms 200.606 ms 28 2001:1890:c00:8802::11cc:6c6d 217.65 ms 222.145 ms 210.213 ms From 2a02:2528::/32 (Switzerland, Sixxs) 2 gw-91.gva-01.ch.sixxs.net 28.932 ms 28.415 ms 29.091 ms 3 2a02:2528:ff:1::4 28.082 ms 28.873 ms 41.525 ms 4 ge0-1.gv1.ip-max.sixxs.net 29.546 ms 37.835 ms 29.366 ms 5 ge3-14.ar01.gva253.ip-max.net 30.502 ms 32.925 ms 29.370 ms 6 ae1.cr01.gva253.ip-max.net 45.019 ms 41.335 ms 47.675 ms 7 xe0-0-1.cr01.gva252.ip-max.net 28.903 ms 33.530 ms 41.954 ms 8 po1.br01.gva252.ip-max.net 39.794 ms 34.197 ms 28.843 ms 9 r1gva1.core.init7.net 28.849 ms 32.812 ms 31.988 ms 10 r1zug1.core.init7.net 47.583 ms 42.633 ms 37.785 ms 11 r1glb1.core.init7.net 36.323 ms 56.574 ms 34.909 ms 12 r1zrh1.core.init7.net 50.896 ms 56.617 ms 42.967 ms 13 ae0-12.zur11.ip6.tinet.net 42.462 ms 41.909 ms 41.557 ms 14 xe-0-1-1.nyc20.ip6.tinet.net 128.395 ms xe-0-1-2.nyc20.ip6.tinet.net 127.736 ms xe-0-1-1.nyc20.ip6.tinet.net 120.968 ms 15 nyiix.iij.net 121.285 ms 121.758 ms 120.904 ms 16 nyc002bb10.iij.net 121.436 ms 122.211 ms 120.475 ms 17 abn001bb10.iij.net 121.829 ms 123.181 ms 121.787 ms 18 2600:803:92f::1 143.860 ms 125.196 ms 179.323 ms 19 2600:802::23 139.937 ms 132.728 ms 140.416 ms 20 ge-1-2-0.il1.nyc12.alter.net 130.477 ms ge-0-3-0.il1.nyc12.alter.net 130.349 ms 140.231 ms 21 * * * 22 gigabitethernet6-0-0.gw5.ams6.alter.net 349.594 ms 129.648 ms gigabitethernet7-0-0.gw5.ams6.alter.net 130.583 ms 23 fastethernet0-0.6b1.ams6.alter.net 138.677 ms 169.896 ms 402.511 ms 24 tu3.6b1.fft4.alter.net 379.628 ms 156.939 ms 138.227 ms 25 * * * 26 ffm-s1-rou-1102.de.eurorings.net 219.035 ms 227.354 ms 236.133 ms 27 kehl-s2-rou-1103.de.eurorings.net 228.896 ms 221.190 ms 239.280 ms 28 nntr-s1-rou-1101.fr.eurorings.net 219.410 ms 226.779 ms 230.940 ms 29 2001:680::134:222:226:160:1 247.598 ms 243.938 ms 218.783 ms 30 2001:1890:c00:c001::1171:ecca 217.493 ms 242.119 ms 217.778 ms 31 2001:1890:c00:c001::ee71:ecca 238.297 ms 219.211 ms 218.524 ms 32 2001:1890:ff:ffff:12:122:105:90 257.048 ms 250.699 ms 252.160 ms 33 wswdc22crs.ipv6.att.net 248.764 ms 268.970 ms 416.443 ms 34 * attga21crs.ipv6.att.net 239.030 ms 241.492 ms 35 attga409me3.ipv6.att.net 249.902 ms 268.800 ms 253.631 ms 36 2001:1890:c00:8802::11cc:6c6d 260.203 ms 236.484 ms 245.413 ms From 2001:1b60::/32 (Germany, Native) 2 2001:1b60:0:1:0:1:0:1 0.275 ms 0.247 ms 0.237 ms 3 Pironet.FRA-12-eth012-615.v6.lambdanet.net 3.199 ms 3.198 ms 4.578 ms 4 ae5.irt1.fra44.de.v6.as13237.net 6.518 ms 6.499 ms 6.507 ms 5 xe-0-3-0-0.fra21.ip6.tinet.net 6.570 ms 6.563 ms 6.543 ms 6 xe-0-1-2.nyc20.ip6.tinet.net 86.740 ms xe-0-0-2.nyc20.ip6.tinet.net 86.833 ms xe-0-2-1.nyc20.ip6.tinet.net 86.715 ms 7 NYIIX.IIJ.Net 88.196 ms 88.046 ms 88.016 ms 8 nyc002bb10.iij.net 85.712 ms 85.844 ms 85.978 ms 9 abn001bb10.iij.net 92.920 ms 93.113 ms 92.785 ms 10 2600:803:92f::1 93.331 ms 92.965 ms 92.713 ms 11 2600:802::23 94.009 ms 94.048 ms 100.621 ms 12 ge-0-3-0.IL1.NYC12.ALTER.NET 99.927 ms 99.896 ms ge-1-2-0.IL1.NYC12.ALTER.NET 99.866 ms 13 ae1.XT2.AMS2.ALTER.NET 97.016 ms ae1.XT1.AMS2.ALTER.NET 96.994 ms 96.919 ms 14 GigabitEthernet7-0-0.GW5.AMS6.ALTER.NET 97.120 ms 98.054 ms GigabitEthernet6-0-0.GW5.AMS6.ALTER.NET 97.111 ms 15 FastEthernet0-0.6B1.AMS6.ALTER.NET 104.272 ms 106.899 ms 106.249 ms 16 tu3.6B1.FFT4.ALTER.NET 107.443 ms 100.970 ms 98.980 ms 17 * * ffm-s1-rou-1006.DE.eurorings.net 99.641 ms 18 ffm-s1-rou-1102.DE.eurorings.net 190.998 ms 183.395 ms 190.432 ms 19 kehl-s2-rou-1103.DE.eurorings.net 190.216 ms 203.128 ms 192.594 ms 20 nntr-s1-rou-1101.FR.eurorings.net 183.713 ms 193.837 ms 202.330 ms 21 2001:680:0:134:222:226:164:1 209.937 ms 182.641 ms 182.782 ms 22 2001:1890:c00:c001::1171:ecca 188.257 ms 183.682 ms 216.084 ms 23 2001:1890:c00:c001::ee71:ecca 205.741 ms 183.258 ms 204.891 ms 24 2001:1890:ff:ffff:12:122:105:90 247.476 ms 242.229 ms 251.679 ms 25 wswdc22crs.ipv6.att.net 237.167 ms 216.849 ms 228.173 ms 26 attga21crs.ipv6.att.net 208.246 ms 230.028 ms 232.396 ms 27 attga409me3.ipv6.att.net 255.300 ms 251.860 ms 249.848 ms 28 2001:1890:c00:8802::11cc:6c6d 233.211 ms 215.398 ms 206.866 ms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From chris.burri at hotmail.ch Mon Jul 1 15:38:32 2013 From: chris.burri at hotmail.ch (chris burri) Date: Mon, 1 Jul 2013 17:38:32 +0200 Subject: Ciena MPLS-VPWS Message-ID: Hi all, I need a little help with MPLS-VPWS configuration on ciena 3916. Could someone knowledgeable in the topic please contact me off-list? Thank you Chris --- -= Amat Victoria Curam =- From alex-lists-nanog at yuriev.com Mon Jul 1 16:07:51 2013 From: alex-lists-nanog at yuriev.com (alex-lists-nanog at yuriev.com) Date: Mon, 1 Jul 2013 12:07:51 -0400 Subject: EC2 issues starting at about 9am Eastern Message-ID: <20130701160751.GA29573@tickets1.zubrcom.net> Hello, Is anyone seeing any EC2 issues? We started seeing them as of about 9:01am today. The issues are manifesting with different instances sporadically not being able to connect to each other or connect to hosts ourside EC2. Thanks, Alex From mpetach at netflight.com Mon Jul 1 19:42:51 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 1 Jul 2013 12:42:51 -0700 Subject: www.att.net ipv6 traceroute In-Reply-To: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> References: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> Message-ID: On Mon, Jul 1, 2013 at 7:34 AM, David Hill wrote: > Anyone else noticing odd ipv6 traceroutes to www.att.net > (2001:1890:1c01:2::40)? > > For example, the first traceroute originating in Chicago, and if the > hostnames are anything to go by: > > Chicago -> Dallas -> Atlanta -> Miama -> NYC -> Amsterdam -> > Frankfurt -> France -> D.C. -> Atlanta... > > The first 2 traceroutes are on SixXs tunnels and the third is native. > > From 2604:8800::/32 (Chicago, Sixxs) > > 2 gw-122.chi-03.us.sixxs.net 25.925 ms 14.816 ms 13.645 ms > 3 uschi03.sixxs.net 18.651 ms 15.544 ms 34.06 ms > 4 2620:0:6b0:a::1 27.401 ms 15.677 ms 14.83 ms > 5 tge6-3.fr3.ord4.ipv6.llnw.net 14.482 ms 18.875 ms 21.112 ms > 6 ve8.fr3.ord.ipv6.llnw.net 28.965 ms 24.031 ms 15.947 ms > 7 tge2-1.fr3.dal.ipv6.llnw.net 39.672 ms 41.431 ms 49.888 ms > 8 tge4-1.fr3.atl1.ipv6.llnw.net 59.908 ms 62.198 ms 72.244 ms > 9 tge2-1.fr3.mia1.ipv6.llnw.net 78.641 ms 75.351 ms 74.425 ms > 10 2600:804:11f::11 91.243 ms 90.002 ms 87.802 ms > 11 2600:802::23 119.804 ms 100.727 ms 100.737 ms > 12 ge-0-3-0.IL1.NYC12.ALTER.NET 147.803 ms 145.406 ms 147.878 ms > 13 ae1.XT2.AMS2.ALTER.NET 148.699 ms ae1.XT1.AMS2.ALTER.NET 146.322 ms > 152.503 ms > 14 GigabitEthernet6-0-0.GW5.AMS6.ALTER.NET 145.967 ms 148.903 ms > 165.926 ms > 15 FastEthernet0-0.6B1.AMS6.ALTER.NET 183.716 ms 156.131 ms 194.141 ms > 16 tu3.6B1.FFT4.ALTER.NET 184.867 ms 184.005 ms 170.47 ms > 17 ffm-s1-rou-1006.DE.eurorings.net 159.565 ms * 173.012 ms > 18 ffm-s1-rou-1102.DE.eurorings.net 200.82 ms 225.979 ms 207.712 ms > 19 kehl-s2-rou-1103.DE.eurorings.net 228.884 ms 208.576 ms 203.722 ms > 20 nntr-s1-rou-1101.FR.eurorings.net 192.901 ms 210.818 ms 210.279 ms > 21 * 2001:680:0:134:222:226:160:1 189.452 ms 171.714 ms > 22 2001:1890:c00:c001::1171:ecca 192.306 ms 164.33 ms 192.835 ms > 23 2001:1890:c00:c001::ee71:ecca 222.488 ms 218.21 ms 194.537 ms > 24 2001:1890:ff:ffff:12:122:105:90 214.309 ms 216.21 ms 216.51 ms > 25 wswdc22crs.ipv6.att.net 206.215 ms 220.884 ms 202.472 ms > 26 attga21crs.ipv6.att.net 213.776 ms 220.918 ms 205.205 ms > 27 attga409me3.ipv6.att.net 190.66 ms 228.532 ms 200.606 ms > 28 2001:1890:c00:8802::11cc:6c6d 217.65 ms 222.145 ms 210.213 ms > > From 2a02:2528::/32 (Switzerland, Sixxs) > > 2 gw-91.gva-01.ch.sixxs.net 28.932 ms 28.415 ms 29.091 ms > 3 2a02:2528:ff:1::4 28.082 ms 28.873 ms 41.525 ms > 4 ge0-1.gv1.ip-max.sixxs.net 29.546 ms 37.835 ms 29.366 ms > 5 ge3-14.ar01.gva253.ip-max.net 30.502 ms 32.925 ms 29.370 ms > 6 ae1.cr01.gva253.ip-max.net 45.019 ms 41.335 ms 47.675 ms > 7 xe0-0-1.cr01.gva252.ip-max.net 28.903 ms 33.530 ms 41.954 ms > 8 po1.br01.gva252.ip-max.net 39.794 ms 34.197 ms 28.843 ms > 9 r1gva1.core.init7.net 28.849 ms 32.812 ms 31.988 ms > 10 r1zug1.core.init7.net 47.583 ms 42.633 ms 37.785 ms > 11 r1glb1.core.init7.net 36.323 ms 56.574 ms 34.909 ms > 12 r1zrh1.core.init7.net 50.896 ms 56.617 ms 42.967 ms > 13 ae0-12.zur11.ip6.tinet.net 42.462 ms 41.909 ms 41.557 ms > 14 xe-0-1-1.nyc20.ip6.tinet.net 128.395 ms > xe-0-1-2.nyc20.ip6.tinet.net 127.736 ms > xe-0-1-1.nyc20.ip6.tinet.net 120.968 ms > 15 nyiix.iij.net 121.285 ms 121.758 ms 120.904 ms > 16 nyc002bb10.iij.net 121.436 ms 122.211 ms 120.475 ms > 17 abn001bb10.iij.net 121.829 ms 123.181 ms 121.787 ms > 18 2600:803:92f::1 143.860 ms 125.196 ms 179.323 ms > 19 2600:802::23 139.937 ms 132.728 ms 140.416 ms > 20 ge-1-2-0.il1.nyc12.alter.net 130.477 ms > ge-0-3-0.il1.nyc12.alter.net 130.349 ms 140.231 ms > 21 * * * > 22 gigabitethernet6-0-0.gw5.ams6.alter.net 349.594 ms 129.648 ms > gigabitethernet7-0-0.gw5.ams6.alter.net 130.583 ms > 23 fastethernet0-0.6b1.ams6.alter.net 138.677 ms 169.896 ms 402.511 ms > 24 tu3.6b1.fft4.alter.net 379.628 ms 156.939 ms 138.227 ms > 25 * * * > 26 ffm-s1-rou-1102.de.eurorings.net 219.035 ms 227.354 ms 236.133 ms > 27 kehl-s2-rou-1103.de.eurorings.net 228.896 ms 221.190 ms 239.280 ms > 28 nntr-s1-rou-1101.fr.eurorings.net 219.410 ms 226.779 ms 230.940 ms > 29 2001:680::134:222:226:160:1 247.598 ms 243.938 ms 218.783 ms > 30 2001:1890:c00:c001::1171:ecca 217.493 ms 242.119 ms 217.778 ms > 31 2001:1890:c00:c001::ee71:ecca 238.297 ms 219.211 ms 218.524 ms > 32 2001:1890:ff:ffff:12:122:105:90 257.048 ms 250.699 ms 252.160 ms > 33 wswdc22crs.ipv6.att.net 248.764 ms 268.970 ms 416.443 ms > 34 * > attga21crs.ipv6.att.net 239.030 ms 241.492 ms > 35 attga409me3.ipv6.att.net 249.902 ms 268.800 ms 253.631 ms > 36 2001:1890:c00:8802::11cc:6c6d 260.203 ms 236.484 ms 245.413 ms > > From 2001:1b60::/32 (Germany, Native) > > 2 2001:1b60:0:1:0:1:0:1 0.275 ms 0.247 ms 0.237 ms > 3 Pironet.FRA-12-eth012-615.v6.lambdanet.net 3.199 ms 3.198 ms 4.578 > ms > 4 ae5.irt1.fra44.de.v6.as13237.net 6.518 ms 6.499 ms 6.507 ms > 5 xe-0-3-0-0.fra21.ip6.tinet.net 6.570 ms 6.563 ms 6.543 ms > 6 xe-0-1-2.nyc20.ip6.tinet.net 86.740 ms > xe-0-0-2.nyc20.ip6.tinet.net 86.833 ms > xe-0-2-1.nyc20.ip6.tinet.net 86.715 ms > 7 NYIIX.IIJ.Net 88.196 ms 88.046 ms 88.016 ms > 8 nyc002bb10.iij.net 85.712 ms 85.844 ms 85.978 ms > 9 abn001bb10.iij.net 92.920 ms 93.113 ms 92.785 ms > 10 2600:803:92f::1 93.331 ms 92.965 ms 92.713 ms > 11 2600:802::23 94.009 ms 94.048 ms 100.621 ms > 12 ge-0-3-0.IL1.NYC12.ALTER.NET 99.927 ms 99.896 ms > ge-1-2-0.IL1.NYC12.ALTER.NET 99.866 ms > 13 ae1.XT2.AMS2.ALTER.NET 97.016 ms > ae1.XT1.AMS2.ALTER.NET 96.994 ms 96.919 ms > 14 GigabitEthernet7-0-0.GW5.AMS6.ALTER.NET 97.120 ms 98.054 ms > GigabitEthernet6-0-0.GW5.AMS6.ALTER.NET 97.111 ms > 15 FastEthernet0-0.6B1.AMS6.ALTER.NET 104.272 ms 106.899 ms 106.249 ms > 16 tu3.6B1.FFT4.ALTER.NET 107.443 ms 100.970 ms 98.980 ms > 17 * * > ffm-s1-rou-1006.DE.eurorings.net 99.641 ms > 18 ffm-s1-rou-1102.DE.eurorings.net 190.998 ms 183.395 ms 190.432 ms > 19 kehl-s2-rou-1103.DE.eurorings.net 190.216 ms 203.128 ms 192.594 ms > 20 nntr-s1-rou-1101.FR.eurorings.net 183.713 ms 193.837 ms 202.330 ms > 21 2001:680:0:134:222:226:164:1 209.937 ms 182.641 ms 182.782 ms > 22 2001:1890:c00:c001::1171:ecca 188.257 ms 183.682 ms 216.084 ms > 23 2001:1890:c00:c001::ee71:ecca 205.741 ms 183.258 ms 204.891 ms > 24 2001:1890:ff:ffff:12:122:105:90 247.476 ms 242.229 ms 251.679 ms > 25 wswdc22crs.ipv6.att.net 237.167 ms 216.849 ms 228.173 ms > 26 attga21crs.ipv6.att.net 208.246 ms 230.028 ms 232.396 ms > 27 attga409me3.ipv6.att.net 255.300 ms 251.860 ms 249.848 ms > 28 2001:1890:c00:8802::11cc:6c6d 233.211 ms 215.398 ms 206.866 ms > > Looks fine to me: mpetach at tftp1:~> traceroute6 www.att.net traceroute6 to www.att.net (2001:1890:1c01:2::40) from 2001:4998:f002:1fe::100, 64 hops max, 12 byte packets 1 ge-0-3-1-d2.pat1.pao.yahoo.com 0.369 ms 0.352 ms 0.367 ms 2 ae-8.pat1.dnx.yahoo.com 25.348 ms 25.363 ms 123.170 ms 3 2605:6c00:303:303::69 35.219 ms 25.622 ms 25.956 ms 4 10gigabitethernet4-3.core1.chi1.he.net 52.456 ms 59.001 ms 53.043 ms 5 att-internet4-as7018.10gigabitethernet5.switch2.chi1.he.net 75.188 ms 77.365 ms 75.445 ms 6 cgcil21crs.ipv6.att.net 102.561 ms 104.090 ms 103.922 ms 7 cl2oh21crs.ipv6.att.net 105.803 ms 106.685 ms 103.180 ms 8 * * * 9 nsvtn21crs.ipv6.att.net 97.371 ms 119.415 ms 92.557 ms 10 * * * 11 attga409me3.ipv6.att.net 113.108 ms 119.130 ms 118.172 ms 12 2001:1890:c00:8802::11cc:6c6d 126.793 ms 117.539 ms 128.418 ms Palo Alto->Denver->Chicago->Cleveland->Nashville->Atlanta mpetach at tftp1:~> traceroute6 www.att.net traceroute6 to www.att.net (2001:1890:1c01:2::40) from 2a00:1288:f00e:1fd::100, 64 hops max, 12 byte packets 1 ge-0-1-0-d2.pat1.ams.yahoo.com 0.594 ms 0.745 ms 0.449 ms 2 30gigabitethernet1-3.core1.ams1.he.net 7.836 ms 11.186 ms 0.621 ms 3 10gigabitethernet1-4.core1.lon1.he.net 7.235 ms 7.693 ms 7.537 ms 4 10gigabitethernet10-4.core1.nyc4.he.net 85.336 ms 75.730 ms 74.506 ms 5 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net 84.458 ms 84.046 ms 84.470 ms 6 n54ny22crs.ipv6.att.net 108.346 ms 109.709 ms 106.708 ms 7 wswdc22crs.ipv6.att.net 109.593 ms 109.116 ms 109.738 ms 8 attga21crs.ipv6.att.net 107.695 ms 104.384 ms 108.077 ms 9 attga409me3.ipv6.att.net 104.221 ms 109.647 ms 104.790 ms 10 2001:1890:c00:8802::11cc:6c6d 105.524 ms 105.763 ms 105.345 ms Amsterdam->London->NY->DC->Atlanta Possibly just a transient issue? Matt From lord2y at gmail.com Mon Jul 1 19:56:38 2013 From: lord2y at gmail.com (Alessandro Ratti) Date: Mon, 1 Jul 2013 21:56:38 +0200 Subject: EC2 issues starting at about 9am Eastern In-Reply-To: <20130701160751.GA29573@tickets1.zubrcom.net> References: <20130701160751.GA29573@tickets1.zubrcom.net> Message-ID: Il giorno luned? 1 luglio 2013, ha scritto: > Hello, > > Is anyone seeing any EC2 issues? We started seeing them as of about 9:01am > today. The issues are manifesting with different instances sporadically not > being able to connect to each other or connect to hosts ourside EC2. > > Which region? > Thanks, > Alex > > -- Alessandro Ratti http://about.me/alessandroratti NOTICE This message is for the named person's use only and it's confidential. If you receive this message in error, please immediately delete it and and notify the sender. Thank you. From robertg at garlic.com Mon Jul 1 20:04:59 2013 From: robertg at garlic.com (Robert Glover) Date: Mon, 01 Jul 2013 13:04:59 -0700 Subject: www.att.net ipv6 traceroute In-Reply-To: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> References: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> Message-ID: <51D1E0EB.6090208@garlic.com> On 07/01/2013 07:34 AM, David Hill wrote: > Anyone else noticing odd ipv6 traceroutes to www.att.net > (2001:1890:1c01:2::40)? > > For example, the first traceroute originating in Chicago, and if the > hostnames are anything to go by: > > Chicago -> Dallas -> Atlanta -> Miama -> NYC -> Amsterdam -> > Frankfurt -> France -> D.C. -> Atlanta... > > Looks OK from here: (From 2607:4B00::/32 - SF Bay Area, Native): mushroom#traceroute www.att.net Translating "www.att.net"...domain server (216.139.32.37) [OK] Type escape sequence to abort. Tracing the route to www.att.net (2001:1890:1C01:2::40) 1 2001:550:2:C::2:1 0 msec 4 msec 4 msec 2 2001:550::142 40 msec 2001:550::113 52 msec 2001:550::142 48 msec 3 2001:550::1040 40 msec 2001:550::1041 48 msec 2001:550::1040 48 msec 4 2001:550:4::4C 44 msec 36 msec 44 msec 5 2001:550:3::7A 40 msec 40 msec 44 msec 6 sffca22crs.ipv6.att.net (2001:1890:FF:FFFF:12:122:86:122) 112 msec 108 msec 112 msec 7 la2ca22crs.ipv6.att.net (2001:1890:FF:FFFF:12:122:31:133) 104 msec 112 msec 108 msec 8 dlstx22crs.ipv6.att.net (2001:1890:FF:FFFF:12:122:28:177) 108 msec 104 msec 112 msec 9 attga21crs.ipv6.att.net (2001:1890:FF:FFFF:12:122:28:173) 108 msec 100 msec 108 msec 10 attga409me3.ipv6.att.net (2001:1890:FF:FFFF:12:122:120:244) 112 msec 124 msec 100 msec 11 * 2001:1890:C00:8802::11CC:6C6D 108 msec 104 msec 12 * * * 13 * * * 14 * * * -Robert From jayb at att.com Mon Jul 1 20:18:51 2013 From: jayb at att.com (Jay Borkenhagen) Date: Mon, 1 Jul 2013 16:18:51 -0400 Subject: www.att.net ipv6 traceroute In-Reply-To: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> References: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> Message-ID: <20945.58411.851583.636356@oz.mt.att.com> David Hill writes: > Anyone else noticing odd ipv6 traceroutes to www.att.net > (2001:1890:1c01:2::40)? > David, We see what's going on. It currently affects only a portion of the v6 Internet. Working on a fix... Jay B. From faisal at snappytelecom.net Mon Jul 1 23:03:20 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 1 Jul 2013 23:03:20 +0000 (GMT) Subject: ALTDB question. In-Reply-To: <754539073.100580.1372719349915.JavaMail.root@snappytelecom.net> Message-ID: <1950290203.100664.1372719800301.JavaMail.root@snappytelecom.net> Hello, A quick question for all. It's my understanding that the Maintainer object needs to be created first. This is accomplished by sending the template to db-admin at altdb.net This is not an automated process, but gets done manually. If there is any discrepancy then one gets a reply back with the error . a) Am I correct in my understanding of above ? b) Is there any auto reply to confirm email receipt ? or only replies are after the request is either complete or sent back for missing / incorrect info ? c) What would be the appropriate amount of time to wait for such a reply ? d) Is there a way to check to see if the Maintainer object has been created ? Many thanks in advance. I dealing with Altdb for the first time, so am looking for some base for what to expect and or not to expect. Regards. ? Faisal Imtiaz Snappy Internet & Telecom From jlewis at lewis.org Tue Jul 2 00:02:59 2013 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 1 Jul 2013 20:02:59 -0400 (EDT) Subject: ALTDB question. In-Reply-To: <1950290203.100664.1372719800301.JavaMail.root@snappytelecom.net> References: <1950290203.100664.1372719800301.JavaMail.root@snappytelecom.net> Message-ID: On Mon, 1 Jul 2013, Faisal Imtiaz wrote: > Hello, > > A quick question for all. > > It's my understanding that the Maintainer object needs to be created first. This is accomplished by sending the template to db-admin at altdb.net > > This is not an automated process, but gets done manually. If there is any discrepancy then one gets a reply back with the error . > > a) Am I correct in my understanding of above ? > b) Is there any auto reply to confirm email receipt ? or only replies are after the request is either complete or sent back for missing / incorrect info ? > c) What would be the appropriate amount of time to wait for such a reply ? > d) Is there a way to check to see if the Maintainer object has been created ? Once created, your maintainer object will be visible in the whois served by whois.altdb.net. If you're just getting started with IRR, no offense intended towards ALTDB, but I'd suggest using any of the other free ones. ARIN and RIPE are both, AFAIK, free for anyone to use and support better authentication than ALTDB. Also, AFAIK, ALTDB has been a one (or few?) person volunteer effort, and from time to time, there have been service outages, reliant on one or a few people for resolution. ARIN and RIPE are staffed and better financially backed. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From todd at borked.ca Tue Jul 2 14:23:58 2013 From: todd at borked.ca (Todd S) Date: Tue, 2 Jul 2013 10:23:58 -0400 Subject: Leap Second Message-ID: We found we got leap seconds added on some systems over the weekend. There were no leap seconds planned ( http://www.usno.navy.mil/USNO/earth-orientation/leap-second-announcement), however some of our systems got one. We run our own s2/s3/s4 system, with only the s2s going to the Internet. We have about 20 servers defined there, but looking through the logs, I can't figure out which one(s) may have been advertising the leap second. I went through all our systems on Friday and Saturday to check for the leap bit, but had nothing, so it must have come out on Sunday. Anyone else run in to this, or have any further intel about servers that advertised the leap second? Cheers, Todd. From mloftis at wgops.com Tue Jul 2 14:35:23 2013 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 2 Jul 2013 07:35:23 -0700 Subject: Leap Second In-Reply-To: References: Message-ID: On Tue, Jul 2, 2013 at 7:23 AM, Todd S wrote: > We found we got leap seconds added on some systems over the weekend. There > were no leap seconds planned ( > http://www.usno.navy.mil/USNO/earth-orientation/leap-second-announcement), > however some of our systems got one. > > We run our own s2/s3/s4 system, with only the s2s going to the Internet. > We have about 20 servers defined there, but looking through the logs, I > can't figure out which one(s) may have been advertising the leap second. I > went through all our systems on Friday and Saturday to check for the leap > bit, but had nothing, so it must have come out on Sunday. > > Anyone else run in to this, or have any further intel about servers that > advertised the leap second? > Had a leap happen here on the 30th. My stratum 1 source is a CDMA timekeeper, I'll ping the operator of it and see if he knows anything or if it logged anything. It's probably not isolated at all since all my S2 machines have some diversity in alternate time sources but still took the leap second. > > Cheers, > > Todd. > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From dmr at ramseyfamily.org Tue Jul 2 14:35:29 2013 From: dmr at ramseyfamily.org (David Ramsey) Date: Tue, 2 Jul 2013 10:35:29 -0400 Subject: Leap Second In-Reply-To: References: Message-ID: I saw alerts from Symmetricom about it for their NTP hardware, and got notified from Infoblox also. Relevant links: http://www.symmetricom.com/media/files/downloads/leap-second/S200_S250_SyncServer_Leap_Second_SRN_v1.30.pdf http://www.symmetricom.com/media/files/downloads/leap-second/S300_S350_SyncServer_Leap_Second_SRN_v2.70.pdf Regards, --dmr On Tue, Jul 2, 2013 at 10:23 AM, Todd S wrote: > We found we got leap seconds added on some systems over the weekend. There > were no leap seconds planned ( > http://www.usno.navy.mil/USNO/earth-orientation/leap-second-announcement), > however some of our systems got one. > > We run our own s2/s3/s4 system, with only the s2s going to the Internet. > We have about 20 servers defined there, but looking through the logs, I > can't figure out which one(s) may have been advertising the leap second. I > went through all our systems on Friday and Saturday to check for the leap > bit, but had nothing, so it must have come out on Sunday. > > Anyone else run in to this, or have any further intel about servers that > advertised the leap second? > > Cheers, > > Todd. > From mansaxel at besserwisser.org Tue Jul 2 14:39:20 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 2 Jul 2013 16:39:20 +0200 Subject: Leap Second In-Reply-To: References: Message-ID: <20130702143919.GB12188@besserwisser.org> Subject: Leap Second Date: Tue, Jul 02, 2013 at 10:23:58AM -0400 Quoting Todd S (todd at borked.ca): > We found we got leap seconds added on some systems over the weekend. There > were no leap seconds planned ( > http://www.usno.navy.mil/USNO/earth-orientation/leap-second-announcement), > however some of our systems got one. > > We run our own s2/s3/s4 system, with only the s2s going to the Internet. > We have about 20 servers defined there, but looking through the logs, I > can't figure out which one(s) may have been advertising the leap second. I > went through all our systems on Friday and Saturday to check for the leap > bit, but had nothing, so it must have come out on Sunday. > > Anyone else run in to this, or have any further intel about servers that > advertised the leap second? We did get an advisory from Infoblox about a bug in "NTP servers based on open source NTP" that would do just that. For Infoblox NIOS there was a hotfix, and Symmetricom also has a patch out. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I think my career is ruined! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mloftis at wgops.com Tue Jul 2 14:39:38 2013 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 2 Jul 2013 07:39:38 -0700 Subject: Leap Second In-Reply-To: References: Message-ID: On Tue, Jul 2, 2013 at 7:35 AM, Michael Loftis wrote: > > > Had a leap happen here on the 30th. My stratum 1 source is a CDMA > timekeeper, I'll ping the operator of it and see if he knows anything or if > it logged anything. It's probably not isolated at all since all my S2 > machines have some diversity in alternate time sources but still took the > leap second. > OK he's checked, nothing unusual in logs....data on the box matches NOAA site (16 leaps, 16 future) - and pool.ntp.org/scores thinks that it's all OK/well within norms. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From todd at borked.ca Tue Jul 2 14:43:19 2013 From: todd at borked.ca (Todd S) Date: Tue, 2 Jul 2013 10:43:19 -0400 Subject: Leap Second In-Reply-To: <20130702143919.GB12188@besserwisser.org> References: <20130702143919.GB12188@besserwisser.org> Message-ID: My S2s are Symmetricoms, so we may have a winner here. Cheers! On Tue, Jul 2, 2013 at 10:39 AM, M?ns Nilsson wrote: > Subject: Leap Second Date: Tue, Jul 02, 2013 at 10:23:58AM -0400 Quoting > Todd S (todd at borked.ca): > > We found we got leap seconds added on some systems over the weekend. > There > > were no leap seconds planned ( > > http://www.usno.navy.mil/USNO/earth-orientation/leap-second-announcement > ), > > however some of our systems got one. > > > > We run our own s2/s3/s4 system, with only the s2s going to the Internet. > > We have about 20 servers defined there, but looking through the logs, I > > can't figure out which one(s) may have been advertising the leap second. > I > > went through all our systems on Friday and Saturday to check for the leap > > bit, but had nothing, so it must have come out on Sunday. > > > > Anyone else run in to this, or have any further intel about servers that > > advertised the leap second? > > We did get an advisory from Infoblox about a bug in "NTP servers based > on open source NTP" that would do just that. For Infoblox NIOS there > was a hotfix, and Symmetricom also has a patch out. > > -- > M?ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > I think my career is ruined! > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAlHS5hcACgkQ02/pMZDM1cWy4ACeKiv8CEjxnPlLgC+OuMJiItSS > EdcAnjWlm1/KOPEiIUf6Kmb9Y6Dj4o5/ > =94yl > -----END PGP SIGNATURE----- > > From smb at cs.columbia.edu Tue Jul 2 14:51:44 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 2 Jul 2013 10:51:44 -0400 Subject: IPMI vulnerabilities Message-ID: http://www.wired.com/threatlevel/2013/07/ipmi/ Capsule summary: watch out! --Steve Bellovin, https://www.cs.columbia.edu/~smb From jeroen at massar.ch Tue Jul 2 15:32:34 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Tue, 02 Jul 2013 17:32:34 +0200 Subject: IPMI vulnerabilities In-Reply-To: References: Message-ID: <51D2F292.5060801@massar.ch> On 2013-07-02 16:51 , Steven Bellovin wrote: > http://www.wired.com/threatlevel/2013/07/ipmi/ > > Capsule summary: watch out! Indeed! But it is should be logical, as IPMI is supposed to be for OOB access right? :) Anybody not putting them behind a properly restricted firewall and/or VLAN is asking for issues... typical IPMI boxes run outdated linux kernels, with nice olddated userspace and a whole lot of tools that one can not really restrict access to, thus it is quite silly to have that access open to the public. Greets, Jeroen From lindner234 at gmail.com Tue Jul 2 15:27:33 2013 From: lindner234 at gmail.com (Dave Lindner) Date: Tue, 2 Jul 2013 11:27:33 -0400 Subject: IPMI vulnerabilities In-Reply-To: References: Message-ID: On Tue, Jul 2, 2013 at 10:51 AM, Steven Bellovin wrote: > http://www.wired.com/threatlevel/2013/07/ipmi/ > > Capsule summary: watch out! > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > Dan Farmer wrote a really nice paper on this subject, complete with bibliography, references, and a tad more content. :) http://fish2.com/ipmi/itrain.html From jamie at photon.com Tue Jul 2 15:54:30 2013 From: jamie at photon.com (Jamie Bowden) Date: Tue, 2 Jul 2013 15:54:30 +0000 Subject: IPMI vulnerabilities In-Reply-To: <51D2F292.5060801@massar.ch> References: <51D2F292.5060801@massar.ch> Message-ID: <465966A5F5B867419F604CD3E604C1E54D5CED99@PRA-DCA-MAIL.pra.ray.com> > From: Jeroen Massar [mailto:jeroen at massar.ch] > On 2013-07-02 16:51 , Steven Bellovin wrote: > > http://www.wired.com/threatlevel/2013/07/ipmi/ > > > > Capsule summary: watch out! > > Indeed! But it is should be logical, as IPMI is supposed to be for OOB > access right? :) > > Anybody not putting them behind a properly restricted firewall and/or > VLAN is asking for issues... typical IPMI boxes run outdated linux > kernels, with nice olddated userspace and a whole lot of tools that one > can not really restrict access to, thus it is quite silly to have that > access open to the public. That same reasoning has worked wonders at keeping SCADA systems off the public internet too. Jamie From jeroen at massar.ch Tue Jul 2 15:58:16 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Tue, 02 Jul 2013 17:58:16 +0200 Subject: IPMI vulnerabilities In-Reply-To: <465966A5F5B867419F604CD3E604C1E54D5CED99@PRA-DCA-MAIL.pra.ray.com> References: <51D2F292.5060801@massar.ch> <465966A5F5B867419F604CD3E604C1E54D5CED99@PRA-DCA-MAIL.pra.ray.com> Message-ID: <51D2F898.9090107@massar.ch> On 2013-07-02 17:54 , Jamie Bowden wrote: >> From: Jeroen Massar [mailto:jeroen at massar.ch] >> On 2013-07-02 16:51 , Steven Bellovin wrote: >>> http://www.wired.com/threatlevel/2013/07/ipmi/ >>> >>> Capsule summary: watch out! >> >> Indeed! But it is should be logical, as IPMI is supposed to be for OOB >> access right? :) >> >> Anybody not putting them behind a properly restricted firewall and/or >> VLAN is asking for issues... typical IPMI boxes run outdated linux >> kernels, with nice olddated userspace and a whole lot of tools that one >> can not really restrict access to, thus it is quite silly to have that >> access open to the public. > > That same reasoning has worked wonders at keeping SCADA systems off the public internet too. People problems cannot be resolved with code. Greets, Jeroen From sla at ucolick.org Tue Jul 2 16:38:07 2013 From: sla at ucolick.org (Steve Allen) Date: Tue, 2 Jul 2013 09:38:07 -0700 Subject: Leap Second In-Reply-To: References: Message-ID: <20130702163807.GA18530@ucolick.org> On Tue 2013-07-02T10:23:58 -0400, Todd S hath writ: > Anyone else run in to this, or have any further intel about servers that > advertised the leap second? David Malone has been monitoring the NTP pool for years. See his plots http://www.maths.tcd.ie/~dwmalone/time/leaps/ This time pool was much better than it has been. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From Valdis.Kletnieks at vt.edu Tue Jul 2 16:49:22 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 02 Jul 2013 12:49:22 -0400 Subject: IPMI vulnerabilities In-Reply-To: Your message of "Tue, 02 Jul 2013 17:58:16 +0200." <51D2F898.9090107@massar.ch> References: <51D2F292.5060801@massar.ch> <465966A5F5B867419F604CD3E604C1E54D5CED99@PRA-DCA-MAIL.pra.ray.com> <51D2F898.9090107@massar.ch> Message-ID: <127247.1372783762@turing-police.cc.vt.edu> On Tue, 02 Jul 2013 17:58:16 +0200, Jeroen Massar said: > On 2013-07-02 17:54 , Jamie Bowden wrote: > > That same reasoning has worked wonders at keeping SCADA systems off the public internet too. > > People problems cannot be resolved with code. Would an Linux cluebat driver count? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From saku at ytti.fi Tue Jul 2 18:35:58 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 2 Jul 2013 21:35:58 +0300 Subject: Google's QUIC In-Reply-To: <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> References: <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> <20130629180710.GA1822@pob.ytti.fi> <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> Message-ID: <20130702183558.GA14948@pob.ytti.fi> On (2013-06-29 23:36 +0100), Tony Finch wrote: > Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to attribute as chance, considering both are DJB's work, both are used by his NaCl library and by extension by MinimaLT. Neither is particularly common algorithm. I'm not implying QUIC plagiarizes MinimaLT, there are differences in the protocol, just choice of the algorithm implies QUIC authors are aware of MinimaLT. -- ++ytti From djahandarie at gmail.com Tue Jul 2 18:40:03 2013 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 2 Jul 2013 14:40:03 -0400 Subject: Google's QUIC In-Reply-To: <20130702183558.GA14948@pob.ytti.fi> References: <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> <20130629180710.GA1822@pob.ytti.fi> <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> <20130702183558.GA14948@pob.ytti.fi> Message-ID: On Tue, Jul 2, 2013 at 2:35 PM, Saku Ytti wrote: > On (2013-06-29 23:36 +0100), Tony Finch wrote: > >> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf > > Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. > > QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to > attribute as chance, considering both are DJB's work, both are used by his > NaCl library and by extension by MinimaLT. Neither is particularly common > algorithm. Taking into consideration these are the best algorithms in their class currently, it would be more surprising to me if they weren't used. -- Darius Jahandarie From jason at lixfeld.ca Tue Jul 2 23:30:20 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 2 Jul 2013 19:30:20 -0400 Subject: Ciena 6200 clue? Message-ID: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> So I've got a bunch of Ciena 6200 kit in, with some of their professional services folks onsite, helping with the initial setup. I know nothing of this kit, other than from what I'm being told, it's pretty bleeding edge, so much so that not even many people at Ciena know how to use it. The SE who's onsite is apparently claiming that there is no provision to set a default gateway on the management interface. This seems odd to me. What is more odd is that we have to buy a manual for it. There isn't an electronic version available, even. I've created an account on their portal, so when that gets approved, I'll see what sort of documentation I can find, but off the top of anyone's head, does anyone know how to do this default gateway thing on the management interface? It's apparently been IP'd properly, so that much is working... Thanks in advance. Sorry for the lack of content otherwise. From LarrySheldon at cox.net Tue Jul 2 23:35:11 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 02 Jul 2013 18:35:11 -0500 Subject: Ciena 6200 clue? In-Reply-To: References: Message-ID: <51D363AF.9090701@cox.net> On 7/2/2013 6:30 PM, Jason Lixfeld wrote: > So I've got a bunch of Ciena 6200 kit in, with some of their professional services folks onsite, helping with the initial setup. I know nothing of this kit, other than from what I'm being told, it's pretty bleeding edge, so much so that not even many people at Ciena know how to use it. > > The SE who's onsite is apparently claiming that there is no provision to set a default gateway on the management interface. This seems odd to me. What is more odd is that we have to buy a manual for it. There isn't an electronic version available, even. > > I've created an account on their portal, so when that gets approved, I'll see what sort of documentation I can find, but off the top of anyone's head, does anyone know how to do this default gateway thing on the management interface? It's apparently been IP'd properly, so that much is working... > > Thanks in advance. Sorry for the lack of content otherwise. Adding to the useless and pointless: Why is all of this being found out after delivery? -- 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 jeffshultz at wvi.com Tue Jul 2 23:39:38 2013 From: jeffshultz at wvi.com (Jeff Shultz) Date: Tue, 02 Jul 2013 16:39:38 -0700 Subject: Ciena 6200 clue? In-Reply-To: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: <51D364BA.8040102@wvi.com> On 7/2/2013 4:30 PM, Jason Lixfeld wrote: > > The SE who's onsite is apparently claiming that there is no provision > to set a default gateway on the management interface. This seems odd > to me. Me too, which is why I've got a call in to another company regarding their management LAN port that I can't configure with a default gateway either. At least not using the CLI. Is this common and I just noticed it because it happened to me, or is this some collective engineering brain cramp that just took hold? -- Jeff Shultz From morrowc.lists at gmail.com Wed Jul 3 00:01:16 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jul 2013 20:01:16 -0400 Subject: Ciena 6200 clue? In-Reply-To: <51D364BA.8040102@wvi.com> References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> <51D364BA.8040102@wvi.com> Message-ID: it's probably fair to point out that practically all optical vendors don't actually understand 'ip' and 'routing' and 'systems management' ... try doing ntp with ONS boxes? got ntpv>1? then ... oops :( never mind the situations where you install a 0/0 route on a management interface/config and STILL have to /32 route particular services out the same GW as 0/0 ... (not cisco, another busted vendor)... optical people... srsly, get with the program. On Tue, Jul 2, 2013 at 7:39 PM, Jeff Shultz wrote: > On 7/2/2013 4:30 PM, Jason Lixfeld wrote: > >> >> The SE who's onsite is apparently claiming that there is no provision >> to set a default gateway on the management interface. This seems odd >> to me. > > > Me too, which is why I've got a call in to another company regarding their > management LAN port that I can't configure with a default gateway either. At > least not using the CLI. > > Is this common and I just noticed it because it happened to me, or is this > some collective engineering brain cramp that just took hold? > > -- > Jeff Shultz > > > From surfer at mauigateway.com Wed Jul 3 01:12:01 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 2 Jul 2013 18:12:01 -0700 Subject: .nyc - here we go... Message-ID: <20130702181201.D483A746@resin13.mta.everyone.net> < careful there may be a troll in here... :) > https://en.wikipedia.org/wiki/.nyc "As of July 2, 2013, .nyc has been approved by ICANN as a city-level top-level domain (TLD) for New York City" As places like that see $186,000 as small change, I wonder what other countries (much less the cities within them) like .nu, .sb or .vu will do? For them this is an astronomical number. Someone's about to hit a financial home run reminiscient of the tech-stock bubble... I haven't read enough, but what's to stop speculators paying the $186,000 then charging the tiny countries mors when they are able to make the purchase? Please don't suggest arbitration because that only increases the cost to those countries. Who's going to buy .nanog? Who's going to buy .ietf? etc. Did icann have any financial requirements to get .icann? scott From rubensk at gmail.com Wed Jul 3 01:23:08 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 2 Jul 2013 22:23:08 -0300 Subject: .nyc - here we go... In-Reply-To: <20130702181201.D483A746@resin13.mta.everyone.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> Message-ID: On Tue, Jul 2, 2013 at 10:12 PM, Scott Weeks wrote: > > > < careful there may be a troll in here... :) > > > https://en.wikipedia.org/wiki/.nyc > > "As of July 2, 2013, .nyc has been approved by ICANN as a > city-level top-level domain (TLD) for New York City" > .nyc has been approved by ICANN May 24. The city made its announcement only today. Link to evaluation report: http://newgtlds.icann.org/sites/default/files/ier/f3T5ufeSpeThAJezaxezuDtE/ie-1-1715-21938-en.pdf Link to all status information: https://gtldresult.icann.org/application-result/applicationstatus/viewstatus > > As places like that see $186,000 as small change, I wonder > what other countries (much less the cities within them) > like .nu, .sb or .vu will do? For them this is an > astronomical number. Someone's about to hit a financial > home run reminiscient of the tech-stock bubble... > No countries were obliged to apply. Both country codes and country names were excluded from the new gTLD process. Actually, they couldn't even apply, as they are considered ccTLDs. > I haven't read enough, but what's to stop speculators > paying the $186,000 then charging the tiny countries > mors when they are able to make the purchase? Please > don't suggest arbitration because that only increases > the cost to those countries. > > Who's going to buy .nanog? > No one in this round. May be in the next one. > Who's going to buy .ietf? > No one, excluded from the process by ICANN. > etc. > Did icann have any financial requirements to get .icann? > .icann also wasn't available for application. Rubens From brunner at nic-naa.net Wed Jul 3 01:33:28 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 02 Jul 2013 18:33:28 -0700 Subject: .nyc - here we go... In-Reply-To: References: <20130702181201.D483A746@resin13.mta.everyone.net> Message-ID: <51D37F68.4050308@nic-naa.net> Thank you Rubens, you saved me the effort. Eric From surfer at mauigateway.com Wed Jul 3 01:45:19 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 2 Jul 2013 18:45:19 -0700 Subject: .nyc - here we go... Message-ID: <20130702184519.D483997E@resin13.mta.everyone.net> --- rubensk at gmail.com wrote: From: Rubens Kuhl > As places like that see $186,000 as small change, I wonder > what other countries (much less the cities within them) > like .nu, .sb or .vu will do? For them this is an > astronomical number. Someone's about to hit a financial > home run reminiscient of the tech-stock bubble... > No countries were obliged to apply. Both country codes and country names were excluded from the new gTLD process. Actually, they couldn't even apply, as they are considered ccTLDs. > I haven't read enough, but what's to stop speculators > paying the $186,000 then charging the tiny countries > mors when they are able to make the purchase? Please > don't suggest arbitration because that only increases > the cost to those countries. ------------------------------------------------------------- Thank you for explaining this. Again, probably. So the cities in those countries could buy them (if they could afford them) but not the countries? So .portvila is available, but not .vanuatu? What about places like Singapore? The city name is the same as the country name. "I haven't read enough, but what's to stop speculators paying the $186,000 then charging the tiny countries mors when they are able to make the purchase?" s/tiny countries/cities in tiny countries/ Does the speculator issue have to go to arbitration? scott From JTyler at fiberutilities.com Wed Jul 3 01:47:55 2013 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Wed, 3 Jul 2013 01:47:55 +0000 Subject: Perl router snmp to DNS Message-ID: My Google fu is failing. Can anybody point me to a script that will create DNS entries from router snmp info? Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC From johnl at iecc.com Wed Jul 3 02:06:31 2013 From: johnl at iecc.com (John Levine) Date: 3 Jul 2013 02:06:31 -0000 Subject: .nyc - here we go... In-Reply-To: <20130702181201.D483A746@resin13.mta.everyone.net> Message-ID: <20130703020631.23093.qmail@joyce.lan> >I haven't read enough, but what's to stop speculators >paying the $186,000 then ... Rather than asking random strangers, you can read the applicant guidebook and find out what the actual rules are: http://newgtlds.icann.org/en/applicants/agb From surfer at mauigateway.com Wed Jul 3 02:17:39 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 2 Jul 2013 19:17:39 -0700 Subject: .nyc - here we go... Message-ID: <20130702191739.D4839832@resin13.mta.everyone.net> --- johnl at iecc.com wrote: From: "John Levine" >I haven't read enough, but what's to stop speculators >paying the $186,000 then ... Rather than asking random strangers, you can read the applicant guidebook and find out what the actual rules are: http://newgtlds.icann.org/en/applicants/agb ---------------------------------------- Ok, you're correct. I need to add that to my list of reading. I am just thinking about the digital divide getting larger (not smaller) as these places are writing about on their various technical mailing lists. That kind of money is not insignificant to them. scott From fergdawgster at gmail.com Wed Jul 3 02:23:55 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 2 Jul 2013 19:23:55 -0700 Subject: .nyc - here we go... In-Reply-To: <20130702191739.D4839832@resin13.mta.everyone.net> References: <20130702191739.D4839832@resin13.mta.everyone.net> Message-ID: On Tue, Jul 2, 2013 at 7:17 PM, Scott Weeks wrote: > Ok, you're correct. I need to add that to my list of reading. > I am just thinking about the digital divide getting larger > (not smaller) as these places are writing about on their > various technical mailing lists. That kind of money is not > insignificant to them. > The expansion of the gTLD space is about much more than costs -- it is also about the expansion in efforts that it will take to monitor for abuse. That is something that a lot of people have been concerned about for a long time now. $.03, - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From brunner at nic-naa.net Wed Jul 3 02:33:23 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 02 Jul 2013 19:33:23 -0700 Subject: .nyc - here we go... In-Reply-To: <20130703020631.23093.qmail@joyce.lan> References: <20130703020631.23093.qmail@joyce.lan> Message-ID: <51D38D73.5060005@nic-naa.net> On 7/2/13 7:06 PM, John Levine wrote: > Rather than asking random strangers, you can read the applicant > guidebook and find out what the actual rules are: There really should be a kinder introduction to those who lack basic clue than to attempt to read the last version of the DAG, even for the American Legally Literate. Someone who has more than just ICANNatitude (in either of the usual senses) should do a standup at the next {$NETTECH} meet and 'splain policy and business, can the bits and vod them out on the *OG lists. Then we could discuss the merits, such as they are. Eric From rubensk at gmail.com Wed Jul 3 03:12:27 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 3 Jul 2013 00:12:27 -0300 Subject: .nyc - here we go... In-Reply-To: <20130702184519.D483997E@resin13.mta.everyone.net> References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: > > Thank you for explaining this. Again, probably. > > So the cities in those countries could buy them (if they could > afford them) but not the countries? So .portvila is available, > but not .vanuatu? > Yes. Country names will be part of the expansion of the ccTLD space, where usually countries are not asked to pay evaluation fees, just annual fees much like current country codes. What about places like Singapore? The city name is the same as > the country name. > Excluded by being a country name. > > "I haven't read enough, but what's to stop speculators paying > the $186,000 then charging the tiny countries mors when they > are able to make the purchase?" > > s/tiny countries/cities in tiny countries/ > > Does the speculator issue have to go to arbitration? > The $185k is an evaluation fee, not a "buy now" price. Part of the evaluation process is to determine if the string has a geographic nature, and if does, if there is proper government support. There could be issues if a city name that is not in the ISO lists (nation capitals, state names) that happens to be a plausible non-geographic name. Let's take Sao Paulo (largest brazilian city) for example: it's the name of a catholic saint in Portuguese, so an applicant claiming to a be a gTLD targeted at the saint devotees could in theory apply (it's not the case as Sao Paulo is also a state name listed in ISO 3166) and after getting the delegation repurpose it to serve Sao Paulo individuals and businesses. Besides many objection procedures, one of them a community rights objection that could be used in a case such as the one I described, governments have a veto power that even requiring consensus among representatives would probably be used to stop the application. Both mechanisms (objections and government veto) are in play at two TLDs facing opposition from south-american countries: .amazon (from Amazon Inc., opposed by countries of the Amazon region like Brazil and Peru ) and .patagonia (opposed by the region of same name encompassing Argentina and Chile). The outcomes of both will likely be known this month at ICANN's meeting in Durban. Summary: there are residual risks, but the checks and balances of the process are likely to stop bad actors, at the cost of also stopping some good actors. Error in the side of caution preferred. Rubens From fergdawgster at gmail.com Wed Jul 3 03:21:15 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 2 Jul 2013 20:21:15 -0700 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: On Tue, Jul 2, 2013 at 8:12 PM, Rubens Kuhl wrote: > Summary: there are residual risks, but the checks and balances of the > process are likely to stop bad actors, at the cost of also stopping some > good actors. Error in the side of caution preferred. > You're missing the forest.... If a new gTLD applicant decides to "capitalize" on their financial investment once they have received approval, there is nothing stopping them from opening the flood gates to anyone who wants to register sub-domains/second-level domains for financial gain. Of course, they should be allowed to do so. It's a free market. Just look at .cc and the complete Charlie Foxtrot they caused by allowing second-level domains to be used by anyone for any purpose (e.g. *.co.cc, *.cu.cc, etc.) and .tk for instance. We can expect a lot more of the same with the expansion of the TLD space, so it *will* require a lot more diligence. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From johnl at iecc.com Wed Jul 3 03:26:24 2013 From: johnl at iecc.com (John Levine) Date: 3 Jul 2013 03:26:24 -0000 Subject: .nyc - here we go... In-Reply-To: <20130702191739.D4839832@resin13.mta.everyone.net> Message-ID: <20130703032624.23356.qmail@joyce.lan> >Rather than asking random strangers, you can read the applicant >guidebook and find out what the actual rules are: > >http://newgtlds.icann.org/en/applicants/agb > >Ok, you're correct. I need to add that to my list of reading. >I am just thinking about the digital divide getting larger >(not smaller) as these places are writing about on their >various technical mailing lists. That kind of money is not >insignificant to them. The largest set of applications are for single registrant vanity domains, like .ibm and .mormon from IBM and the LDS church. I don't see them causing much damage to anyone other than the organizations who are paying for them. There are some from geographic areas like .nyc, and a bunch from people who imagine that they can get rich with people who want to register in .hockey or .art. The one that sort of is like what you were worried about is the application for .patagonia, which is from the outdoors equipment company, and is causing great consternation in southern Argentina. It remains to be seen what ICANN will do about that. Also, considering what a bust all the existing special interest domains such as .aero, .travel, .museum, and .asia are, I wouldn't hold my breath waiting for vast action in any of the new ones. R's, John From rubensk at gmail.com Wed Jul 3 03:41:52 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 3 Jul 2013 00:41:52 -0300 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: On Wed, Jul 3, 2013 at 12:21 AM, Paul Ferguson wrote: > > On Tue, Jul 2, 2013 at 8:12 PM, Rubens Kuhl wrote: > > > Summary: there are residual risks, but the checks and balances of the > > process are likely to stop bad actors, at the cost of also stopping some > > good actors. Error in the side of caution preferred. > > > > You're missing the forest.... > > If a new gTLD applicant decides to "capitalize" on their financial > investment once they have received approval, there is nothing stopping > them from opening the flood gates to anyone who wants to register > sub-domains/second-level domains for financial gain. > > Of course, they should be allowed to do so. It's a free market. > > Just look at .cc and the complete Charlie Foxtrot they caused by > allowing second-level domains to be used by anyone for any purpose > (e.g. *.co.cc, *.cu.cc, etc.) and .tk for instance. New gTLDs aren't allowed to register 2-letter country-codes like co. without clearance from government of that country. Considering gTLDs pay ICANN fees by domain if they go higher than 50k domains, it's unlikely that a registry business model will go in the same direction as the repurposed ccTLDs > > > We can expect a lot more of the same with the expansion of the TLD > space, so it *will* require a lot more diligence. Current working version of the Registry Agreement, following advice from governments, established requirements for security monitoring for ICANN, registries and registrars, so you should probably wait until ICANN board publishes it to assess whether such diligence is already being provisioned into the system or not. From http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-ii-agenda-2b-25jun13-en.pdf "Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request." Rubens From fergdawgster at gmail.com Wed Jul 3 03:47:08 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 2 Jul 2013 20:47:08 -0700 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: On Tue, Jul 2, 2013 at 8:41 PM, Rubens Kuhl wrote: > > From > http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-ii-agenda-2b-25jun13-en.pdf > "Registry Operator will periodically conduct a technical analysis to assess > whether domains in the TLD are being used to perpetrate security threats, > such as pharming, phishing, malware, and botnets. Registry Operator will > maintain statistical reports on the number of security threats identified > and the actions taken as a result of the periodic security checks. Registry > Operator will maintain these reports for the term of the Agreement unless a > shorter period is required by law or approved by ICANN, and will provide > them to ICANN upon request." > > Great, Let's see what happens. If history is any teacher... - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From LarrySheldon at cox.net Wed Jul 3 04:15:46 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 02 Jul 2013 23:15:46 -0500 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: <51D3A572.2030701@cox.net> Makes me wonder if concern for routing table size is worrying about the right thing. -- 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 rubensk at gmail.com Wed Jul 3 04:23:13 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 3 Jul 2013 01:23:13 -0300 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: > Great, Let's see what happens. > > If history is any teacher... > > There is not much history here to look at... .cc and .tk are ccTLDs, based out of sovereign states. They are delegated into the root by ICANN (more precisely by IANA, which is currently a contract also granted to ICANN) and that's it. What they do with 2LDs/3LDs are not under community scrutiny, unless the ccTLD operator is also operated on a multi-stakeholder basis. gTLDs operate under ICANN compliance regime and are required to abide by community policies. Will this be enough ? We don't know yet, but people have given some thought trying to find a way it is enough, and can require further mechanisms if the initial ones fail. Rubens From fergdawgster at gmail.com Wed Jul 3 04:29:02 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 2 Jul 2013 21:29:02 -0700 Subject: .nyc - here we go... In-Reply-To: <51D3A572.2030701@cox.net> References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> Message-ID: Now you are thinking. :-) - ferg On Tue, Jul 2, 2013 at 9:15 PM, Larry Sheldon wrote: > Makes me wonder if concern for routing table size is worrying about the > right thing. > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From fergdawgster at gmail.com Wed Jul 3 04:30:07 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 2 Jul 2013 21:30:07 -0700 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> Message-ID: On Tue, Jul 2, 2013 at 9:23 PM, Rubens Kuhl wrote: > gTLDs operate under ICANN compliance regime and are required to abide by > community policies. Will this be enough ? We don't know yet, but people have > given some thought trying to find a way it is enough, and can require > further mechanisms if the initial ones fail. > Of course, we all know that makes a huge difference. Cheers, - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From asullivan at dyn.com Wed Jul 3 04:39:39 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 3 Jul 2013 00:39:39 -0400 Subject: .nyc - here we go... In-Reply-To: <51D3A572.2030701@cox.net> References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> Message-ID: On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon wrote: > Makes me wonder if concern for routing table size is worrying about the > right thing. > Because obviously, the problems of scaling router memory and scaling DNS servers are the same kind? Yes, having many many new TLDs introduces new problems. (If you're not scared enough, I encourage you to go read the output of the Variant Issues Project. Full disclosure: I had a hand in.) Why are we talking about this non-news now? We all knew about three years ago, at the latest, that ICANN was planning to do this. If we didn't, shame on us. A From LarrySheldon at cox.net Wed Jul 3 05:01:46 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 03 Jul 2013 00:01:46 -0500 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> Message-ID: <51D3B03A.5010209@cox.net> On 7/2/2013 11:39 PM, Andrew Sullivan wrote: > On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon > wrote: > >> Makes me wonder if concern for routing table size is worrying about >> the right thing. > > Because obviously, the problems of scaling router memory and scaling > DNS servers are the same kind? I would not say "same" but I would say "similar" and "related" when you think about things like how big the cache will be and how much of the traffic the peerages worry about will be pure overhead, and stuff like that. > Yes, having many many new TLDs introduces new problems. (If you're > not scared enough, I encourage you to go read the output of the > Variant Issues Project. Full disclosure: I had a hand in.) Why are > we talking about this non-news now? We all knew about three years > ago, at the latest, that ICANN was planning to do this. If we > didn't, shame on us. What is going to happen tomorrow is sometimes less interesting that what is happening a while ago. -- 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 fergdawgster at gmail.com Wed Jul 3 05:04:05 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 2 Jul 2013 22:04:05 -0700 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> Message-ID: Why does this discussion have to always be "one or the other"? We have multiple problems here, friends. Focus. - ferg On Tue, Jul 2, 2013 at 9:39 PM, Andrew Sullivan wrote: > On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon wrote: > >> Makes me wonder if concern for routing table size is worrying about the >> right thing. >> > > Because obviously, the problems of scaling router memory and scaling DNS > servers are the same kind? > > Yes, having many many new TLDs introduces new problems. (If you're not > scared enough, I encourage you to go read the output of the Variant Issues > Project. Full disclosure: I had a hand in.) Why are we talking about this > non-news now? We all knew about three years ago, at the latest, that ICANN > was planning to do this. If we didn't, shame on us. > > A -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From marka at isc.org Wed Jul 3 05:26:29 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Jul 2013 15:26:29 +1000 Subject: .nyc - here we go... In-Reply-To: Your message of "Wed, 03 Jul 2013 00:01:46 -0500." <51D3B03A.5010209@cox.net> References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> <51D3B03A.5010209@cox.net> Message-ID: <20130703052630.01CFE36C0368@drugs.dv.isc.org> In message <51D3B03A.5010209 at cox.net>, Larry Sheldon writes: > On 7/2/2013 11:39 PM, Andrew Sullivan wrote: > > On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon > > wrote: > > > >> Makes me wonder if concern for routing table size is worrying about > >> the right thing. > > > > Because obviously, the problems of scaling router memory and scaling > > DNS servers are the same kind? > > I would not say "same" but I would say "similar" and "related" when you > think about things like how big the cache will be and how much of the > traffic the peerages worry about will be pure overhead, and stuff like that. The number of tld's has very little effect on cache size. Cache size is proportional to the number of unique queries made. There are already enough names to blow out any cache. The number of tld's does have a impact on servers that keep a local copy of the root zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nick at foobar.org Wed Jul 3 08:29:29 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 03 Jul 2013 09:29:29 +0100 Subject: Perl router snmp to DNS In-Reply-To: References: Message-ID: <51D3E0E9.805@foobar.org> On 03/07/2013 02:47, Jensen Tyler wrote: > My Google fu is failing. Can anybody point me to a script that will > create DNS entries from router snmp info? netdot.uoregon.edu it's a little larger than the standard one line perl script, but it works and I use it in anger. Nick From David.Malone at nuim.ie Wed Jul 3 10:25:40 2013 From: David.Malone at nuim.ie (David Malone) Date: Wed, 03 Jul 2013 11:25:40 +0100 Subject: Leap Second In-Reply-To: References: Message-ID: <20130703102540.GA59779@marble.hamilton.local> I had a quick look at the data, and only 5 of the servers that I was monitoring advertised a leap on June 30th - three in the US, one in Argentina and one in New Zealand. If Todd or Michael want, we can compare notes and see if they are peering with one of the servers that I spotted. David. From eugen at leitl.org Wed Jul 3 10:27:00 2013 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 3 Jul 2013 12:27:00 +0200 Subject: [cryptography] Google's QUIC Message-ID: <20130703102700.GN24217@leitl.org> ----- Forwarded message from ianG ----- Date: Wed, 03 Jul 2013 13:24:54 +0300 From: ianG To: cryptography at randombit.net Subject: Re: [cryptography] Google's QUIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 On 3/07/13 12:37 PM, Eugen Leitl wrote: > ----- Forwarded message from Saku Ytti ----- > > Date: Tue, 2 Jul 2013 21:35:58 +0300 > From: Saku Ytti > To: nanog at nanog.org > Subject: Re: Google's QUIC > User-Agent: Mutt/1.5.21 (2010-09-15) > > On (2013-06-29 23:36 +0100), Tony Finch wrote: > >> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf > > Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. > > QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to > attribute as chance, considering both are DJB's work, both are used by his > NaCl library and by extension by MinimaLT. Neither is particularly common > algorithm. It's not the choice of algorithm that is "by chance" it is the choice of suite as a design decision that matters. I also would like to use the same ciphersuite, but the reason is that DJB has already done the work to define the entire suite, saving me from doing it. This is quite a saving for me, and hasn't hitherto existed as an external service. Last time it took over a month of hard research and learning to settle on RSA/AES128/CBC/SHA1/HMAC/Encrypt-then-mac. As an added bonus, DJB came up with a shorter, catchier name: curve25519xsalsa20poly1305 In the past, things like TLS, PGP, IPSec and others encouraged you to slice and dice the various algorithms as a sort of alphabet soup mix. Disaster. What we got for that favour was code bloat, insecurity at the edges, continual arguments as to what is good & bad, focus on numbers & acronyms, distraction from user security, entire projects that rate your skills in cryptoscrabble, committeeitus, upgrade nightmares, pontification ... Cryptoplumbing shouldn't be like eating spagetti soup with a toothpick. There should be One Cipher Suite and that should do for everyone, everytime. There should be no way for users to stuff things up by tweaking a dial they read about in some slashdot tweakabit article while on the train to work. > I'm not implying QUIC plagiarizes MinimaLT, there are differences in the > protocol, just choice of the algorithm implies QUIC authors are aware of > MinimaLT. Picking curve25519xsalsa20poly1305 is good enough for that One True CipherSuite motive alone, and doesn't imply any other sort of copying one might have seen. It's an innovation! Adopt it. iang _______________________________________________ cryptography mailing list cryptography at randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 From streiner at cluebyfour.org Wed Jul 3 12:37:09 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 3 Jul 2013 08:37:09 -0400 (EDT) Subject: Perl router snmp to DNS In-Reply-To: References: Message-ID: On Wed, 3 Jul 2013, Jensen Tyler wrote: > My Google fu is failing. Can anybody point me to a script that will > create DNS entries from router snmp info? I don't recall ever having seen anything like that as a pre-built package or Perl module. If I understand what you're trying to do, that might be tough to as a one-size-fits-all module, because different organizations have vastly different network device naming conventions. jms From thijs.stuurman at nxs.nl Wed Jul 3 11:48:53 2013 From: thijs.stuurman at nxs.nl (Thijs Stuurman) Date: Wed, 3 Jul 2013 11:48:53 +0000 Subject: RPKI Dashboard Message-ID: FYI, source information: http://staff.science.uva.nl/~delaat/rp/2012-2013/index.html#Presentations-rp2 Dashboard: http://academic.slowpoke.nl/ With kind regards, Thijs Stuurman From Jac.Kloots at surfnet.nl Wed Jul 3 16:27:39 2013 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Wed, 3 Jul 2013 18:27:39 +0200 (CEST) Subject: RPKI Dashboard In-Reply-To: References: Message-ID: Hi folks, On Wed, 3 Jul 2013, Thijs Stuurman wrote: > FYI, source information: http://staff.science.uva.nl/~delaat/rp/2012-2013/index.html#Presentations-rp2 > > Dashboard: > > http://academic.slowpoke.nl/ This is the development server. The dashboard will soon be migrated to http://rpki.surfnet.nl (server is running, but no data in there yet). Any comments and suggestions are welcome! Regards, Jac -- Jac Kloots Network Services SURFnet bv From surfer at mauigateway.com Wed Jul 3 17:00:38 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 3 Jul 2013 10:00:38 -0700 Subject: .nyc - here we go... Message-ID: <20130703100038.D49AD828@m0005311.ppops.net> --- rubensk at gmail.com wrote: From: Rubens Kuhl > Thank you for explaining this. Again, probably. Summary: there are residual risks, but the checks and balances of the process are likely to stop bad actors, at the cost of also stopping some good actors. Error in the side of caution preferred. ----------------------------------------------------------- Thanks for the explanation. I will begin to learn more about this. scott From shortdudey123 at gmail.com Wed Jul 3 17:02:18 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 3 Jul 2013 10:02:18 -0700 Subject: Leap Second In-Reply-To: <20130703102540.GA59779@marble.hamilton.local> References: <20130703102540.GA59779@marble.hamilton.local> Message-ID: This might sound like an easy question, but how do you verify if a Red Hat box took a leap second? -Grant On Wed, Jul 3, 2013 at 3:25 AM, David Malone wrote: > I had a quick look at the data, and only 5 of the servers that I > was monitoring advertised a leap on June 30th - three in the US, > one in Argentina and one in New Zealand. If Todd or Michael want, > we can compare notes and see if they are peering with one of the > servers that I spotted. > > David. > > From dan at beanfield.com Wed Jul 3 18:51:22 2013 From: dan at beanfield.com (Dan Armstrong) Date: Wed, 3 Jul 2013 14:51:22 -0400 Subject: 10G Wave from NJ to NY Message-ID: <4BFCDAB9-2A33-431B-9369-D7FFAF7F34F8@beanfield.com> Would anybody out there have a 10G wave for sale on a route between 165 Halsey in Newark and 60 Hudson in New York that crosses the Hudson River at or south of the Holland Tunnel? Possibly in the rail tunnel between World Trade Centre station and Exchange Place? Off list replies are great. Thanks! From bross at pobox.com Wed Jul 3 19:57:40 2013 From: bross at pobox.com (Brandon Ross) Date: Wed, 3 Jul 2013 15:57:40 -0400 (EDT) Subject: Ciena 6200 clue? In-Reply-To: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: On Tue, 2 Jul 2013, Jason Lixfeld wrote: > The SE who's onsite is apparently claiming that there is no provision to > set a default gateway on the management interface. Everyone knows that attacks against your management interface come from devices not on your management network. By removing the default gateway feature, Ciena is improving the security of your network. It's time we created a BCOP specifying that default gateway functionality be disabled or removed in all network deployments, in the interest of security. Security improvements realized in the last few years by dropping all ICMP and TCP DNS at firewall boundaries, not to mention universal deployment of NAT, were just the first few steps to creating a much more secure Internet. Once disablement of default gateway functionality has been become a common practice, the natural reduction in traffic on the Internet should allow most operators to achieve enormous cost savings by powering off all of their equipment. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From paul at paulstewart.org Wed Jul 3 20:00:09 2013 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 03 Jul 2013 16:00:09 -0400 Subject: Ciena 6200 clue? In-Reply-To: Message-ID: On 2013-07-03 3:57 PM, "Brandon Ross" wrote: > >Everyone knows that attacks against your management interface come from >devices not on your management network. By removing the default gateway >feature, Ciena is improving the security of your network. > >It's time we created a BCOP specifying that default gateway functionality >be disabled or removed in all network deployments, in the interest of >security. Security improvements realized in the last few years by >dropping all ICMP and TCP DNS at firewall boundaries, not to mention >universal deployment of NAT, were just the first few steps to creating a >much more secure Internet. > >Once disablement of default gateway functionality has been become a >common >practice, the natural reduction in traffic on the Internet should allow >most operators to achieve enormous cost savings by powering off all of >their equipment. > Awesome - sorry, can't resist?. :) Paul From qlixed at gmail.com Wed Jul 3 20:30:37 2013 From: qlixed at gmail.com (QliX=D! [aka EHB]) Date: Wed, 3 Jul 2013 17:30:37 -0300 Subject: Leap Second In-Reply-To: References: <20130703102540.GA59779@marble.hamilton.local> Message-ID: As far i can remember the ntp logs have that info... greap for leap pr leap second El jul 3, 2013 2:05 PM, "Grant Ridder" escribi?: > This might sound like an easy question, but how do you verify if a Red Hat > box took a leap second? > > -Grant > > On Wed, Jul 3, 2013 at 3:25 AM, David Malone wrote: > > > I had a quick look at the data, and only 5 of the servers that I > > was monitoring advertised a leap on June 30th - three in the US, > > one in Argentina and one in New Zealand. If Todd or Michael want, > > we can compare notes and see if they are peering with one of the > > servers that I spotted. > > > > David. > > > > > From David.Malone at nuim.ie Wed Jul 3 20:41:57 2013 From: David.Malone at nuim.ie (David Malone) Date: Wed, 03 Jul 2013 21:41:57 +0100 Subject: Leap Second In-Reply-To: References: <20130703102540.GA59779@marble.hamilton.local> Message-ID: <20130703204157.GB95065@marble.hamilton.local> Hi Grant, My Linux boxes have usually logged a message like: Jul 1 00:59:59 aturing kernel: [3812251.350269] Clock: inserting leap second 23:59:60 UTC This message is logged by the kernel, so you can see it in the output of dmesg - otherwise check in /var/log as it should have been logged to some one of the files there. David. From jeffshultz at wvi.com Wed Jul 3 20:01:44 2013 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 03 Jul 2013 13:01:44 -0700 Subject: Ciena 6200 clue? In-Reply-To: References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: <51D48328.8000704@wvi.com> On 7/3/2013 12:57 PM, Brandon Ross wrote: > On Tue, 2 Jul 2013, Jason Lixfeld wrote: > >> The SE who's onsite is apparently claiming that there is no provision >> to set a default gateway on the management interface. > > Everyone knows that attacks against your management interface come from > devices not on your management network. By removing the default gateway > feature, Ciena is improving the security of your network. > While my device is not a Ciena, it has the same issue - and I don't think I'm going to be getting attacks against my management interface on a 10.0.x.x network. I want the option to decide for myself. I'm not all that interested in setting up a management VLAN so this one device in my central office will be happy on it's "virtually flat" network. -- Jeff Shultz From jeffshultz at wvi.com Wed Jul 3 20:03:46 2013 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 03 Jul 2013 13:03:46 -0700 Subject: Ciena 6200 clue? In-Reply-To: References: Message-ID: <51D483A2.3060805@wvi.com> On 7/3/2013 1:00 PM, Paul Stewart wrote: > On 2013-07-03 3:57 PM, "Brandon Ross" wrote: >> >> Everyone knows that attacks against your management interface come >> from devices not on your management network. By removing the >> default gateway feature, Ciena is improving the security of your >> network. >> >> It's time we created a BCOP specifying that default gateway >> functionality be disabled or removed in all network deployments, in >> the interest of security. Security improvements realized in the >> last few years by dropping all ICMP and TCP DNS at firewall >> boundaries, not to mention universal deployment of NAT, were just >> the first few steps to creating a much more secure Internet. >> >> Once disablement of default gateway functionality has been become >> a common practice, the natural reduction in traffic on the Internet >> should allow most operators to achieve enormous cost savings by >> powering off all of their equipment. >> > Awesome - sorry, can't resist?. :) > Ah, somehow my eyeballs glazed over the excellent sarcasm that was made evident in the last paragraph.... Either way, my point remains: I want the option. I suspect I'm not alone... -- Jeff Shultz From bedard.phil at gmail.com Wed Jul 3 21:41:55 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 03 Jul 2013 17:41:55 -0400 Subject: Ciena 6200 clue? In-Reply-To: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: The ALU 7750/7450, etc. routers have a separate routing process/configuration for their OOB mgmt and as of the last time I looked do not support a default gateway. Phil On 7/2/13 7:30 PM, "Jason Lixfeld" wrote: >So I've got a bunch of Ciena 6200 kit in, with some of their professional >services folks onsite, helping with the initial setup. I know nothing of >this kit, other than from what I'm being told, it's pretty bleeding edge, >so much so that not even many people at Ciena know how to use it. > >The SE who's onsite is apparently claiming that there is no provision to >set a default gateway on the management interface. This seems odd to me. > What is more odd is that we have to buy a manual for it. There isn't an >electronic version available, even. > >I've created an account on their portal, so when that gets approved, I'll >see what sort of documentation I can find, but off the top of anyone's >head, does anyone know how to do this default gateway thing on the >management interface? It's apparently been IP'd properly, so that much >is working... > >Thanks in advance. Sorry for the lack of content otherwise. From erikm at buh.org Wed Jul 3 22:08:28 2013 From: erikm at buh.org (Erik Muller) Date: Thu, 04 Jul 2013 00:08:28 +0200 Subject: Ciena 6200 clue? In-Reply-To: References: Message-ID: <51D4A0DC.5030103@buh.org> On 7/3/13 23:41 , Phil Bedard wrote: > The ALU 7750/7450, etc. routers have a separate routing > process/configuration for their OOB mgmt and as of the last time I looked > do not support a default gateway. Can you still call it a routing process if it's incapable of routing? -e From Bryan at bryanfields.net Wed Jul 3 22:14:19 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 03 Jul 2013 18:14:19 -0400 Subject: Ciena 6200 clue? In-Reply-To: References: Message-ID: <51D4A23B.8000008@bryanfields.net> On 7/3/13 5:41 PM, Phil Bedard wrote: > The ALU 7750/7450, etc. routers have a separate routing > process/configuration for their OOB mgmt and as of the last time I looked > do not support a default gateway. Well you can set up multiple static routes. The only route you can't set it 0/0. This will work, though I'd suggest only putting the management routes it needs in it. A:Milhouse>bof# static-route 0.0.0.0/0 next-hop 1.0.0.2 MINOR: SYSTEM #1505 Invalid static route destination prefix - cannot configure default route on the management interface A:Milhouse>bof# static-route 0.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# static-route 128.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# show bof =============================================================================== BOF (Memory) =============================================================================== primary-image nope.jpg primary-config Milhouse/config.cfg address 1.0.0.70/24 active primary-dns 1.0.0.2 dns-domain nope.jpg static-route 0.0.0.0/1 next-hop 1.0.0.2 static-route 128.0.0.0/1 next-hop 1.0.0.2 autonegotiate duplex full speed 100 wait 4 persist on no li-local-save no li-separate console-speed 115200 =============================================================================== -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From kyle.creyts at gmail.com Wed Jul 3 23:43:36 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 3 Jul 2013 16:43:36 -0700 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> Message-ID: +10 On Tue, Jul 2, 2013 at 10:04 PM, Paul Ferguson wrote: > Why does this discussion have to always be "one or the other"? > > We have multiple problems here, friends. > > Focus. > > - ferg > > > On Tue, Jul 2, 2013 at 9:39 PM, Andrew Sullivan wrote: > > > On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon > wrote: > > > >> Makes me wonder if concern for routing table size is worrying about the > >> right thing. > >> > > > > Because obviously, the problems of scaling router memory and scaling DNS > > servers are the same kind? > > > > Yes, having many many new TLDs introduces new problems. (If you're not > > scared enough, I encourage you to go read the output of the Variant > Issues > > Project. Full disclosure: I had a hand in.) Why are we talking about > this > > non-news now? We all knew about three years ago, at the latest, that > ICANN > > was planning to do this. If we didn't, shame on us. > > > > A > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From bedard.phil at gmail.com Wed Jul 3 23:58:13 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 3 Jul 2013 16:58:13 -0700 Subject: Ciena 6200 clue? Message-ID: <-199329547269245042@unknownmsgid> Right that is the "workaround." :) Phil From: Bryan Fields Sent: 7/3/2013 18:15 To: NANOG list Subject: Re: Ciena 6200 clue? On 7/3/13 5:41 PM, Phil Bedard wrote: > The ALU 7750/7450, etc. routers have a separate routing > process/configuration for their OOB mgmt and as of the last time I looked > do not support a default gateway. Well you can set up multiple static routes. The only route you can't set it 0/0. This will work, though I'd suggest only putting the management routes it needs in it. A:Milhouse>bof# static-route 0.0.0.0/0 next-hop 1.0.0.2 MINOR: SYSTEM #1505 Invalid static route destination prefix - cannot configure default route on the management interface A:Milhouse>bof# static-route 0.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# static-route 128.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# show bof =============================================================================== BOF (Memory) =============================================================================== primary-image nope.jpg primary-config Milhouse/config.cfg address 1.0.0.70/24 active primary-dns 1.0.0.2 dns-domain nope.jpg static-route 0.0.0.0/1 next-hop 1.0.0.2 static-route 128.0.0.0/1 next-hop 1.0.0.2 autonegotiate duplex full speed 100 wait 4 persist on no li-local-save no li-separate console-speed 115200 =============================================================================== -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From jason at lixfeld.ca Thu Jul 4 00:05:39 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 3 Jul 2013 20:05:39 -0400 Subject: Ciena 6200 clue? In-Reply-To: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: <0271F729-B522-4A80-B5F5-C797A83F5E55@lixfeld.ca> Hi, So just for completeness - the box does support a default gateway and it was pretty simple to figure out once we were able to connect to it over the Web UI. The professional services tech who installed this stuff basically copied data off of a spreadsheet and didn't really have any notion of how the thing really worked so he didn't really have any answers. On 2013-07-02, at 7:30 PM, Jason Lixfeld wrote: > So I've got a bunch of Ciena 6200 kit in, with some of their professional services folks onsite, helping with the initial setup. I know nothing of this kit, other than from what I'm being told, it's pretty bleeding edge, so much so that not even many people at Ciena know how to use it. > > The SE who's onsite is apparently claiming that there is no provision to set a default gateway on the management interface. This seems odd to me. What is more odd is that we have to buy a manual for it. There isn't an electronic version available, even. > > I've created an account on their portal, so when that gets approved, I'll see what sort of documentation I can find, but off the top of anyone's head, does anyone know how to do this default gateway thing on the management interface? It's apparently been IP'd properly, so that much is working... > > Thanks in advance. Sorry for the lack of content otherwise. From morrowc.lists at gmail.com Thu Jul 4 01:32:53 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Jul 2013 21:32:53 -0400 Subject: Ciena 6200 clue? In-Reply-To: References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: On Wed, Jul 3, 2013 at 5:41 PM, Phil Bedard wrote: > The ALU 7750/7450, etc. routers have a separate routing > process/configuration for their OOB mgmt and as of the last time I looked > do not support a default gateway. honestly? this sounds like typical alu :( some of their kit requires either proxy-arp from the default-gw (and no support for default-gw, all of the 'internet' is out the management ether... on that ether link) or 'can we run ospf with your router?' what?? you put ospf processing/handling/debugging (ha!) but you can't point 0/0 at that ip over -> there?? wtf :( From courtneysmith at comcast.net Thu Jul 4 01:49:06 2013 From: courtneysmith at comcast.net (Courtney Smith) Date: Wed, 3 Jul 2013 21:49:06 -0400 Subject: Perl router snmp to DNS In-Reply-To: References: Message-ID: <35FE0DE5-FFDD-48D3-A337-480015C3D5A1@comcast.net> On Jul 3, 2013, at 5:30 PM, nanog-request at nanog.org wrote: > Message: 1 > Date: Wed, 3 Jul 2013 08:37:09 -0400 (EDT) > From: "Justin M. Streiner" > To: "nanog at nanog.org" > Subject: Re: Perl router snmp to DNS > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 3 Jul 2013, Jensen Tyler wrote: > >> My Google fu is failing. Can anybody point me to a script that will >> create DNS entries from router snmp info? > > I don't recall ever having seen anything like that as a pre-built package > or Perl module. If I understand what you're trying to do, that might be > tough to as a one-size-fits-all module, because different organizations > have vastly different network device naming conventions. > > jms These were provided in a post from 10/2012. Search archives for "Semi-automated L3 interface DNS records". https://gist.github.com/oogali/778830 http://cluepon.net/ras/generate_dnsptr_generic_php Courtney Smith courtneysmith at comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jabley at hopcount.ca Thu Jul 4 14:24:13 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 4 Jul 2013 10:24:13 -0400 Subject: .nyc - here we go... In-Reply-To: References: <20130702184519.D483997E@resin13.mta.everyone.net> <51D3A572.2030701@cox.net> Message-ID: <8778438D-FF55-40E4-A4FF-3C02EB48D877@hopcount.ca> On 2013-07-03, at 01:04, Paul Ferguson wrote: > Why does this discussion have to always be "one or the other"? > > We have multiple problems here, friends. > > Focus. I think you mean "de-focus". :-) Joe From ml-nanog090304q at elcsplace.com Thu Jul 4 15:00:26 2013 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Fri, 05 Jul 2013 01:00:26 +1000 Subject: .nyc - here we go... In-Reply-To: <20130702181201.D483A746@resin13.mta.everyone.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> Message-ID: <51D58E0A.6040103@elcsplace.com> On 03/07/13 11:12, Scott Weeks wrote: > "As of July 2, 2013, .nyc has been approved by ICANN as a > city-level top-level domain (TLD) for New York City" Do they have DNSSEC from inception? It would seem a sensible thing to do for a virgin TLD. From rubensk at gmail.com Thu Jul 4 16:42:32 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 4 Jul 2013 13:42:32 -0300 Subject: .nyc - here we go... In-Reply-To: <51D58E0A.6040103@elcsplace.com> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> Message-ID: On Thu, Jul 4, 2013 at 12:00 PM, Ted Cooper wrote: > On 03/07/13 11:12, Scott Weeks wrote: > > "As of July 2, 2013, .nyc has been approved by ICANN as a > > city-level top-level domain (TLD) for New York City" > > Do they have DNSSEC from inception? It would seem a sensible thing to do > for a virgin TLD. All new gTLDs are required to be DNSSEC-signed. The requirement only applies to the parent zone, unless registry policy dictates otherwise, so we can expect many more DS records in the root but a similar DS rate for 2LDs to other gTLDs, likely to be less than 1%: http://scoreboard.verisignlabs.com/percent-trace.png Rubens From Bryan at bryanfields.net Thu Jul 4 16:50:58 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 04 Jul 2013 12:50:58 -0400 Subject: Ciena 6200 clue? In-Reply-To: References: <04ABA7D5-95CD-4866-B423-CAD54FDDF4A8@lixfeld.ca> Message-ID: <51D5A7F2.7060000@bryanfields.net> On 7/3/13 9:32 PM, Christopher Morrow wrote: > honestly? this sounds like typical alu :( > some of their kit requires either proxy-arp from the default-gw (and > no support for default-gw, all of the 'internet' is out the management > ether... on that ether link) or 'can we run ospf with your router?' > > what?? you put ospf processing/handling/debugging (ha!) but you can't > point 0/0 at that ip over -> there?? wtf The older microwave radios were like this. Most other vendors just put a serial console on the product at 9600n8 to do a basic config (power, channel, etc). Not ALU. The radio sets up a PPP connection on the serial port and that connects to a windows laptop (XP sp1 or older, win2k works best). Now do you think they use IP for this? nope! ISO CLNS and ISIS to find the radio. Only after these 5 things go right, may you fire up the java GUI that actually talks to it. After about 10 min, it should be up and might talk to it. Now on the odd chance it does not work (shocking, right?), you get to trouble shoot it. Better break out the Italian to English dictionary, all the error messages are in Italian. Thankfully the IP routing development team does not have these issues. Most possess a good amount of clue. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From johnl at iecc.com Thu Jul 4 17:01:15 2013 From: johnl at iecc.com (John Levine) Date: 4 Jul 2013 17:01:15 -0000 Subject: .nyc - here we go... In-Reply-To: <51D58E0A.6040103@elcsplace.com> Message-ID: <20130704170115.16559.qmail@joyce.lan> >> "As of July 2, 2013, .nyc has been approved by ICANN as a >> city-level top-level domain (TLD) for New York City" > >Do they have DNSSEC from inception? It would seem a sensible thing to do >for a virgin TLD. Yes. See the AGB, to which I sent a link a few messages back. From brunner at nic-naa.net Thu Jul 4 17:34:41 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 10:34:41 -0700 Subject: .nyc - here we go... In-Reply-To: <51D58E0A.6040103@elcsplace.com> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> Message-ID: <51D5B231.2000508@nic-naa.net> On 7/4/13 8:00 AM, Ted Cooper wrote: > Do they have DNSSEC from inception? It would seem a sensible thing to do > for a virgin TLD. In the evolution of the DAG I pointed out that both the DNSSEC and the IPv6 requirements, as well as other SLA requirements, were significantly in excess of those placed upon the legacy registries, and assumed general value and availability with non-trivial cost to entry operators, some of whom might not be capitalized by investors with profit expectations similar to those that existed prior to the catastrophic telecoms build-out and the millennial dotbomb collapse. The v6-is-everywhere and the DNSSEC-greenfields advocates prevailed, and of course, the SLA boggies remain "elevated" w.r.t. the legacy registry operator obligations. "Sensible" may be subject to cost-benefit analysis. I did .cat's DNSSEC funnel request at the contracted party's insistence and I thought it pure marketing. The .museum's DNSSEC funnel request must have, under the "it is necessary" theory, produced demonstrable value beyond the technical pleasure of its implementer. Anyone care to advance evidence that either zone has been, not "will someday be", significantly improved by the adoption of DS records? Evidence, not rhetoric, please. #insert usual junk from *nog v6 evangelicals that .africa and .eos (Basque Autonomous Region) must drive v6 adoption from their ever-so-deep-pockets, or the net will die. Eric From johnl at iecc.com Thu Jul 4 17:48:54 2013 From: johnl at iecc.com (John Levine) Date: 4 Jul 2013 17:48:54 -0000 Subject: .nyc - here we go... In-Reply-To: <51D5B231.2000508@nic-naa.net> Message-ID: <20130704174854.16978.qmail@joyce.lan> >Anyone care to advance evidence that either zone has been, not "will >someday be", significantly improved by the adoption of DS records? >Evidence, not rhetoric, please. I dunno. Can you point to parts of your house that have been significantly improved by fire insurance? From Valdis.Kletnieks at vt.edu Thu Jul 4 18:11:44 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Jul 2013 14:11:44 -0400 Subject: .nyc - here we go... In-Reply-To: Your message of "Thu, 04 Jul 2013 10:34:41 -0700." <51D5B231.2000508@nic-naa.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> Message-ID: <37268.1372961504@turing-police.cc.vt.edu> On Thu, 04 Jul 2013 10:34:41 -0700, Eric Brunner-Williams said: > #insert usual junk from *nog v6 evangelicals that .africa and .eos > (Basque Autonomous Region) must drive v6 adoption from their > ever-so-deep-pockets, or the net will die. I'll bite. What's the *actual* additional cost for dnssec and ipv6 support for a greenfield rollout? It's greenfield, so there's no "our older gear/software/admins need upgrading" issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From eric at nixwizard.net Thu Jul 4 18:21:54 2013 From: eric at nixwizard.net (Eric G) Date: Thu, 4 Jul 2013 14:21:54 -0400 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> Message-ID: On Mar 15, 2013 11:37 AM, "Christopher Morrow" wrote: > > On Fri, Mar 15, 2013 at 11:32 AM, Joshua Goldbard wrote: > > God I want one of those PA firewalls just to play with in the lab. I can't > > justify the expense, but as far as firewalls go they're gorgeous. From the > > chassis to the UI, PA is just doing it right. > > > > If anyone has a different experience, I'd love to hear it. > > for any firewall/appliance .. ask this: > "How can I manage 200 of these things remotely" > > UI is pretty and nice and cool.. but utterly useless if you have more > than 1 of the things. > also, a firewall is a firewall is a firewall... they all do the basics > (nat/filter/'proxy') nothing else in that category really matters... > management matters. > I know I'm necro'ing a thread, but PA has a centralized management product called Panorama. I threw up a Panorama VM the other day at work and I was thoroughly impressed with how easy it was to set up ("establish SIC? What's that?") and the slick management UI on Panorama that basically mirrors the normal PA UI. The App-ID thing that PA implemented *does* matter in my humble opinion... being able to say "allow specifically traffic that looks and smells like RADIUS" instead of "allow UDP 1812 and 1813" is neato PA has had some rough edges (their client VPN solution for Windows and OSX is not ready for prime time in my opinion) but this is one thing they nailed. Chris Morrow - if it's in your budget you can pick up a PA200 on eBay for like $1k. I've only played with PA over the year and a half I've been with my current employer, but they've got a neat product. I've been tempted to buy one for the house even honestly... having URL filtering, SSL decrypt, SSH decrypt (via man-in-the-middle), App-ID, some basic DLP and even some malware analysis (Wildfire) built right in is kind of compelling -- Eric http://linkedin.com/in/ericgearhart From brunner at nic-naa.net Thu Jul 4 18:59:02 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 11:59:02 -0700 Subject: .nyc - here we go... In-Reply-To: <20130704174854.16978.qmail@joyce.lan> References: <20130704174854.16978.qmail@joyce.lan> Message-ID: <51D5C5F6.106@nic-naa.net> On 7/4/13 10:48 AM, John Levine wrote: > I dunno. Can you point to parts of your house that have been > significantly improved by fire insurance? Cute John. Let me know when you've run out of neat things other people should do. Eric From brunner at nic-naa.net Thu Jul 4 19:04:48 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 12:04:48 -0700 Subject: .nyc - here we go... In-Reply-To: <37268.1372961504@turing-police.cc.vt.edu> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> Message-ID: <51D5C750.4090502@nic-naa.net> On 7/4/13 11:11 AM, Valdis.Kletnieks at vt.edu wrote: > I'll bite. What's the *actual* additional cost for dnssec and ipv6 > support for a greenfield rollout? It's greenfield, so there's no > "our older gear/software/admins need upgrading" issues. You'll let me know there is no place where v6 is not available, and while you're at it, why .frogans (I've met the guy, has to be the least obvious value proposition I've come across) needs to accessible to v6ers before, well, er, that .com thingie. "DNSSEC No clue necessary" ... so all those guys and gals out there selling training are ... adding no necessary value at some measurable cost? Eric From matthew at matthew.at Thu Jul 4 22:48:54 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 4 Jul 2013 15:48:54 -0700 Subject: .nyc - here we go... In-Reply-To: <37268.1372961504@turing-police.cc.vt.edu> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> Message-ID: <9FF40D24-169E-4568-9F25-EE00BEEED13A@matthew.at> Well, for starters there's whole truckloads of surplus gear that you can't get for pennies and use successfully. Matthew Kaufman (Sent from my iPhone) On Jul 4, 2013, at 11:11 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 04 Jul 2013 10:34:41 -0700, Eric Brunner-Williams said: > >> #insert usual junk from *nog v6 evangelicals that .africa and .eos >> (Basque Autonomous Region) must drive v6 adoption from their >> ever-so-deep-pockets, or the net will die. > > I'll bite. What's the *actual* additional cost for dnssec and ipv6 > support for a greenfield rollout? It's greenfield, so there's no > "our older gear/software/admins need upgrading" issues. From marka at isc.org Thu Jul 4 23:44:21 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Jul 2013 09:44:21 +1000 Subject: .nyc - here we go... In-Reply-To: Your message of "Thu, 04 Jul 2013 12:04:48 -0700." <51D5C750.4090502@nic-naa.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> Message-ID: <20130704234421.6428236E1D5F@drugs.dv.isc.org> In message <51D5C750.4090502 at nic-naa.net>, Eric Brunner-Williams writes: > On 7/4/13 11:11 AM, Valdis.Kletnieks at vt.edu wrote: > > I'll bite. What's the *actual* additional cost for dnssec and ipv6 > > support for a greenfield rollout? It's greenfield, so there's no > > "our older gear/software/admins need upgrading" issues. > > You'll let me know there is no place where v6 is not available, and > while you're at it, why .frogans (I've met the guy, has to be the > least obvious value proposition I've come across) needs to accessible > to v6ers before, well, er, that .com thingie. Well give that .com thingie is IPv6 accessable and has DNSSEC there is nothing we need to let you know. And yes you can get IPv6 everywhere if you want it. Native IPv6 is a little bit harder but definitely not impossible nor more expensive. ; <<>> DiG 9.10.0pre-alpha <<>> ns com @a.gtld-servers.net -6 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18176 ;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 16 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;com. IN NS ;; ANSWER SECTION: com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN RRSIG NS 8 1 172800 20130709042103 20130702031103 35519 com. G9bZIBIFL0MacyGQ9rgx+eFSnp/j11x/OoXJ30ADzYqffm/if68R1DYs v0fA4vqf3NQsUoonSO7t6tCh4Fl5OV/oju0BYXukXOn7bvpiA7Ij+B7H UoSyybVZRsRk4Q4d6t7EJ/gohL/p9B4BFOIiQ1gDIa8dAUzCUOXXo59j Oks= ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 f.gtld-servers.net. 172800 IN A 192.35.51.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 m.gtld-servers.net. 172800 IN A 192.55.83.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 ;; Query time: 173 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Fri Jul 05 09:38:20 EST 2013 ;; MSG SIZE rcvd: 683 > "DNSSEC No clue necessary" ... so all those guys and gals out there > selling training are ... adding no necessary value at some measurable > cost? > > Eric > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jul 4 23:55:01 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Jul 2013 09:55:01 +1000 Subject: .nyc - here we go... In-Reply-To: Your message of "Thu, 04 Jul 2013 15:48:54 -0700." <9FF40D24-169E-4568-9F25-EE00BEEED13A@matthew.at> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <9FF40D24-169E-4568-9F25-EE00BEEED13A@matthew.at> Message-ID: <20130704235501.D836E36E1E0D@drugs.dv.isc.org> In message <9FF40D24-169E-4568-9F25-EE00BEEED13A at matthew.at>, Matthew Kaufman writes: > Well, for starters there's whole truckloads of surplus gear that you > can't get for pennies and use successfully. Surplus IPv6 capable gear has been around for a long while now. Remember most gear has had IPv6 for over a decade now. A lot of gear that ISC got given for IPv6 development was on it 2nd or 3rd repurposing before we got it nearly a decade ago. > Matthew Kaufman > > (Sent from my iPhone) > > On Jul 4, 2013, at 11:11 AM, Valdis.Kletnieks at vt.edu wrote: > > > On Thu, 04 Jul 2013 10:34:41 -0700, Eric Brunner-Williams said: > > > >> #insert usual junk from *nog v6 evangelicals that .africa and .eos > >> (Basque Autonomous Region) must drive v6 adoption from their > >> ever-so-deep-pockets, or the net will die. > > > > I'll bite. What's the *actual* additional cost for dnssec and ipv6 > > support for a greenfield rollout? It's greenfield, so there's no > > "our older gear/software/admins need upgrading" issues. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbailey at satelliteintelligencegroup.com Fri Jul 5 00:12:27 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 5 Jul 2013 00:12:27 +0000 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> , Message-ID: Palo Alto has zero support for anything lea wise past the 7200 if I recall. We spent a ton of money on asr's and found out we needed to lawful intercept ios which was only working/tested on a 7206vxr with a g2. Palo Alto is insanely expensive, and (in my opinion) is only really cool for seeing what kind of porn people are looking at. This was an international (literally, every country AND every body of water) and was required as every government on the planet wanted access to data from their flagged airplanes. It was cool, but not cool enough to be priced at what it is (the support and update costs were pretty intense on a larger deployment). Any deeper questions etc, reply off list. Sent from my Mobile Device. -------- Original message -------- From: Eric G Date: 07/04/2013 11:23 AM (GMT-08:00) To: Christopher Morrow Cc: NANOG list Subject: Re: What are y'all doing for CALEA compliance? On Mar 15, 2013 11:37 AM, "Christopher Morrow" wrote: > > On Fri, Mar 15, 2013 at 11:32 AM, Joshua Goldbard wrote: > > God I want one of those PA firewalls just to play with in the lab. I can't > > justify the expense, but as far as firewalls go they're gorgeous. From the > > chassis to the UI, PA is just doing it right. > > > > If anyone has a different experience, I'd love to hear it. > > for any firewall/appliance .. ask this: > "How can I manage 200 of these things remotely" > > UI is pretty and nice and cool.. but utterly useless if you have more > than 1 of the things. > also, a firewall is a firewall is a firewall... they all do the basics > (nat/filter/'proxy') nothing else in that category really matters... > management matters. > I know I'm necro'ing a thread, but PA has a centralized management product called Panorama. I threw up a Panorama VM the other day at work and I was thoroughly impressed with how easy it was to set up ("establish SIC? What's that?") and the slick management UI on Panorama that basically mirrors the normal PA UI. The App-ID thing that PA implemented *does* matter in my humble opinion... being able to say "allow specifically traffic that looks and smells like RADIUS" instead of "allow UDP 1812 and 1813" is neato PA has had some rough edges (their client VPN solution for Windows and OSX is not ready for prime time in my opinion) but this is one thing they nailed. Chris Morrow - if it's in your budget you can pick up a PA200 on eBay for like $1k. I've only played with PA over the year and a half I've been with my current employer, but they've got a neat product. I've been tempted to buy one for the house even honestly... having URL filtering, SSL decrypt, SSH decrypt (via man-in-the-middle), App-ID, some basic DLP and even some malware analysis (Wildfire) built right in is kind of compelling -- Eric http://linkedin.com/in/ericgearhart From ebw at abenaki.wabanaki.net Fri Jul 5 01:02:35 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 18:02:35 -0700 Subject: .nyc - here we go... In-Reply-To: <20130704234421.6428236E1D5F@drugs.dv.isc.org> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> Message-ID: <51D61B2B.8020504@abenaki.wabanaki.net> Someone who should know better wrote: > Well give that .com thingie is IPv6 accessable and has DNSSEC there > is nothing we need to let you know. And yes you can get IPv6 > everywhere if you want it. Native IPv6 is a little bit harder but > definitely not impossible nor more expensive. And this was true when the v6 and DEC requirements entered the DAG? Try again, and while you're inventing a better past, explain how everyone knew that it would take 6 revisions of the DAG and take until 3Q2012 before an applicant could predict when capabilities could be scheduled. The one thing you've got going for you is that in 2009 no one knew that almost all of the nearly 2,000 applicants would be forced by higher technical and financial requirements to pick one of a universe of fewer than 50 service providers, or that nearly all of the "developing economies" would be excluded, or self-exclude, from attempting to apply. So the basic diversity assumption was wrong. Why are the people who don't follow the shitty process so full of confidence they have all the clue necessary? Eric From LarrySheldon at cox.net Fri Jul 5 01:23:22 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Jul 2013 20:23:22 -0500 Subject: .nyc - here we go... In-Reply-To: References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> Message-ID: <51D6200A.8050407@cox.net> On 7/4/2013 8:02 PM, Eric Brunner-Williams wrote: > And this was true when the v6 and DEC requirements entered the DAG? OK, I 'fess to terminal stupidity--in this contest: "DEC"? "the DAG"? > Why are the people who don't follow the shitty process so full of > confidence they have all the clue necessary? A job requirement? Genetic links to DESIRABLE characteristics? Comes with the territory? -- 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 brunner at nic-naa.net Fri Jul 5 01:35:35 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 18:35:35 -0700 Subject: .nyc - here we go... In-Reply-To: <51D6200A.8050407@cox.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> <51D6200A.8050407@cox.net> Message-ID: <51D622E7.6000608@nic-naa.net> > OK, I 'fess to terminal stupidity--in this contest: "DEC"? "the DAG"? Draft Applicant's Guidebook. From brunner at nic-naa.net Fri Jul 5 01:37:45 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 18:37:45 -0700 Subject: .nyc - here we go... In-Reply-To: <51D6200A.8050407@cox.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> <51D6200A.8050407@cox.net> Message-ID: <51D62369.3070307@nic-naa.net> On 7/4/13 6:23 PM, Larry Sheldon wrote: > > OK, I 'fess to terminal stupidity--in this contest: "DEC"? "the DAG"? Sigh. DNSSEC and Draft Applicant Guidebook. From Valdis.Kletnieks at vt.edu Fri Jul 5 01:39:34 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Jul 2013 21:39:34 -0400 Subject: .nyc - here we go... In-Reply-To: Your message of "Thu, 04 Jul 2013 18:02:35 -0700." <51D61B2B.8020504@abenaki.wabanaki.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> <51D61B2B.8020504@abenaki.wabanaki.net> Message-ID: <58307.1372988374@turing-police.cc.vt.edu> On Thu, 04 Jul 2013 18:02:35 -0700, Eric Brunner-Williams said: > higher technical and financial requirements to pick one of a universe > of fewer than 50 service providers, I'm reasonably sure that there are more than 50 service providers who are able to privide you with a connection that will do IPv6. > or that nearly all of the > "developing economies" would be excluded, or self-exclude, from > attempting to apply. % dig so. any ... ;; ADDITIONAL SECTION: a.nic.so. 43165 IN A 72.52.71.4 a.nic.so. 43165 IN AAAA 2001:470:1a::4 b.nic.so. 43165 IN A 38.103.2.4 c.nic.so. 43165 IN A 63.243.194.4 c.nic.so. 43165 IN AAAA 2001:5a0:10::4 d.nic.so. 43165 IN A 196.216.168.54 d.nic.so. 43165 IN AAAA 2001:43f8:120::54 If Somalia, the failed nation state and near-undisputed champion hell-hole of the world, can manage to get quad-A's for its ccTLD, the bar can't be *too* high. (Yes, i see exactly how they did it. And there's nothing prohibiting any of the applicants in "developing countries" from doing exactly the same thing) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ebw at abenaki.wabanaki.net Fri Jul 5 01:58:24 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Thu, 04 Jul 2013 18:58:24 -0700 Subject: .nyc - here we go... In-Reply-To: <58307.1372988374@turing-police.cc.vt.edu> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> <51D61B2B.8020504@abenaki.wabanaki.net> <58307.1372988374@turing-police.cc.vt.edu> Message-ID: <51D62840.9060904@abenaki.wabanaki.net> > I'm reasonably sure that there are more than 50 service providers > who are able to privide you with a connection that will do IPv6. In this context the universe of 50 providers are registry service providers, existing and entrant. Verisign, NeuStar, Afilias, CORE, AusReg, ISC, ... Your side won if you predicted in 2009, or even as late as 2011, that there would be many many applicants, using very very few providers, and none in awkward places. If you predicted that, you won on all counts, v6 availability, density of available technical clue for DNSSEC as the cheap box checks -- the real win was access to investment capital and financial instruments, access to American or equivalent legal and ancillary services, shared fate (still being dickered) on insurance bundling and business continuity set-aside, the business advantages offered by Verisign, NeuStar, Afilias, CORE, AusReg, ISC, ... Absent that it really doesn't matter if a light in the sky told you that v6 was everywhere and free, or that DNSSEC was vital to everything, and free too, or not. I didn't predict it, so I lobbied under the assumption that very low capitalizations would attempt to provide some locally needed name to existing address mapping, and that signing the zone had little but cosmetic effect unless there were resources within the zone offering a greater return on attacker investment than any large, and unsigned zone (and there still are some of those). I also tried to get ICANN's attempt to provide "Applicant Support" to defer these non-essentials for registry start-up, but that whole thing went south and the one qualified application was disallowed because ... .ummah upset someone who didn't care to admit it (the Support Program reviewers are anonymous). .museum started on a desktop. There has to be a good reason why this can never happen again. Eric From johnl at iecc.com Fri Jul 5 02:04:07 2013 From: johnl at iecc.com (John Levine) Date: 5 Jul 2013 02:04:07 -0000 Subject: .nyc - here we go... In-Reply-To: <37268.1372961504@turing-police.cc.vt.edu> Message-ID: <20130705020407.18584.qmail@joyce.lan> >I'll bite. What's the *actual* additional cost for dnssec and ipv6 >support for a greenfield rollout? It's greenfield, so there's no >"our older gear/software/admins need upgrading" issues. I've read the IPv6 and DNSSEC parts of a lot of the applications, including the ones that aren't backed by the familiar large registries, and nobody had any great trouble doing DNSSEC or IPv6. There are a couple of adequate DNSSEC toolkits for anyone who doesn't want to buy a prefab system, and even though there are plenty of places where IPv6 isn't available, the sensible thing to do (even for large applicants) is to put the servers where the networks are. R's, John From johnl at iecc.com Fri Jul 5 02:05:41 2013 From: johnl at iecc.com (John Levine) Date: 5 Jul 2013 02:05:41 -0000 Subject: .nyc - here we go... In-Reply-To: <51D61B2B.8020504@abenaki.wabanaki.net> Message-ID: <20130705020541.18608.qmail@joyce.lan> >Why are the people who don't follow the shitty process so full of >confidence they have all the clue necessary? Probably because they don't think that new TLDs are particularly useful or valuable. R's, John From mdr at tesp.com Fri Jul 5 02:12:52 2013 From: mdr at tesp.com (Michael Rathbun) Date: Thu, 04 Jul 2013 19:12:52 -0700 Subject: Yahoo! security: are there any lights on? Message-ID: <87act8l775clji2vpr2m41krcvpid34in9@4ax.com> Y! is haemorrhaging PII to me and I cannot figure out how to make it stop. I have an ancient three-letter account (you can easily guess what the three letters are) and hundreds of people have somehow been led to believe that they own and control it, to the point of associating it with their own accounts, using it as a CC in their communication with their attorneys, banks, spouses and other ... persons. Today during our traditional early-morning July 4 breakfast cookout I got an SMS message, purportedly from Y!, that "We detected unusual activity on the network. Log in to yahoo.com from the web to unlock your account." This was an out-of-the-blue first event, but there was no mechanism in the message to do anything dangerous. When back at home, logging in to Y! involved additional authentication steps and a mandatory password change. Fair enough. No sign of account access from anywhere unusual. The password change event was sent to the correct linked external accounts. But then, a new and interesting barrage of mail started coming in, indicating that, as suspected, the account associations were indeed being effected without any involvement of myself. For instance: >Hi Vince, > >We detected a login attempt with valid password to your Yahoo! account ([munged by me, but not by Y!]) from an unrecognized device on Thu, Jul 4, 2013 3:56 PM VET. > >Location: Venezuela (IP=186.88.201.179) > >Note: The location is based on information from your Internet service or wireless carrier provider. > >Was this you? If so, you can disregard the rest of this email. (This is interesting and, perhaps, encouraging -- that's one of the cantv.net addresses I've recently seen in compromised Y! account spam headers.) I have never yet succeeded in contacting a live body at Y!. Does anyone know whether the lights are even on, let alone anybody being home? mdr -- "There are no laws here, only agreements." -- Masahiko From mdr at tesp.com Fri Jul 5 02:37:56 2013 From: mdr at tesp.com (Michael Rathbun) Date: Thu, 04 Jul 2013 19:37:56 -0700 Subject: Yahoo! security: are there any lights on? In-Reply-To: <87act8l775clji2vpr2m41krcvpid34in9@4ax.com> References: <87act8l775clji2vpr2m41krcvpid34in9@4ax.com> Message-ID: On Thu, 04 Jul 2013 19:12:52 -0700, Michael Rathbun wrote: >I have never yet succeeded in contacting a live body at Y!. Does anyone >know whether the lights are even on, let alone anybody being home? Info received. Thanks all. mdr -- The hits just keep on coming for poor "Nadine". See the sad tale of email lists gone horribly wrong at F - IW AA #2157 GEVNP From marka at isc.org Fri Jul 5 03:35:30 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Jul 2013 13:35:30 +1000 Subject: .nyc - here we go... In-Reply-To: Your message of "Thu, 04 Jul 2013 18:02:35 -0700." <51D61B2B.8020504@abenaki.wabanaki.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> <51D61B2B.8020504@abenaki.wabanaki.net> Message-ID: <20130705033530.4C49136E2E29@drugs.dv.isc.org> In message <51D61B2B.8020504 at abenaki.wabanaki.net>, Eric Brunner-Williams write s: > Someone who should know better wrote: > > > Well give that .com thingie is IPv6 accessable and has DNSSEC there > > is nothing we need to let you know. And yes you can get IPv6 > > everywhere if you want it. Native IPv6 is a little bit harder but > > definitely not impossible nor more expensive. > > And this was true when the v6 and DEC requirements entered the DAG? DS for COM was added added to the root zone in Feb 2011. The process of getting COM signed started a lot earlier well before the root zone was signed and included ensuring the protocol worked for COM sized zones. But hey if you just look a when records are added to zones you wouldn't see that. Requiring new zones start at the standard you expect existing zones to obtain is neither unexpected nor unreasonable. > Try again, and while you're inventing a better past, explain how > everyone knew that it would take 6 revisions of the DAG and take until > 3Q2012 before an applicant could predict when capabilities could be > scheduled. > > The one thing you've got going for you is that in 2009 no one knew > that almost all of the nearly 2,000 applicants would be forced by > higher technical and financial requirements to pick one of a universe > of fewer than 50 service providers, or that nearly all of the > "developing economies" would be excluded, or self-exclude, from > attempting to apply. So the basic diversity assumption was wrong. > > Why are the people who don't follow the shitty process so full of > confidence they have all the clue necessary? > > Eric > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bzs at world.std.com Fri Jul 5 04:11:04 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 5 Jul 2013 00:11:04 -0400 Subject: .nyc - here we go... In-Reply-To: <20130705020541.18608.qmail@joyce.lan> References: <51D61B2B.8020504@abenaki.wabanaki.net> <20130705020541.18608.qmail@joyce.lan> Message-ID: <20950.18264.154175.258853@world.std.com> > >Why are the people who don't follow the shitty process so full of > >confidence they have all the clue necessary? > > Probably because they don't think that new TLDs are particularly > useful or valuable. Oops, just a minute, gotta grab the popcorn and cooler for this one...ok, proceed. -- -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 mike at mikejones.in Fri Jul 5 08:43:39 2013 From: mike at mikejones.in (Mike Jones) Date: Fri, 5 Jul 2013 09:43:39 +0100 Subject: .nyc - here we go... In-Reply-To: <51D61B2B.8020504@abenaki.wabanaki.net> References: <20130702181201.D483A746@resin13.mta.everyone.net> <51D58E0A.6040103@elcsplace.com> <51D5B231.2000508@nic-naa.net> <37268.1372961504@turing-police.cc.vt.edu> <51D5C750.4090502@nic-naa.net> <20130704234421.6428236E1D5F@drugs.dv.isc.org> <51D61B2B.8020504@abenaki.wabanaki.net> Message-ID: On 5 July 2013 02:02, Eric Brunner-Williams wrote: > Someone who should know better wrote: > > > Well give that .com thingie is IPv6 accessable and has DNSSEC there > > is nothing we need to let you know. And yes you can get IPv6 > > everywhere if you want it. Native IPv6 is a little bit harder but > > definitely not impossible nor more expensive. > > And this was true when the v6 and DEC requirements entered the DAG? > > Try again, and while you're inventing a better past, explain how > everyone knew that it would take 6 revisions of the DAG and take until > 3Q2012 before an applicant could predict when capabilities could be > scheduled. > > The one thing you've got going for you is that in 2009 no one knew > that almost all of the nearly 2,000 applicants would be forced by > higher technical and financial requirements to pick one of a universe > of fewer than 50 service providers, or that nearly all of the > "developing economies" would be excluded, or self-exclude, from > attempting to apply. So the basic diversity assumption was wrong. > > Why are the people who don't follow the shitty process so full of > confidence they have all the clue necessary? Why do people who make statements about .com not being IPv6 reachable think they have all the clue necessary? And what about those people who think that DNSSEC is about validating the answers from the root/TLD name servers? At least you avoided the common mistake of citing the 1% end user IPv6 availability figure when claiming that IPv6 wasn't available in data centres... ;) - Mike From lord2y at gmail.com Fri Jul 5 13:06:19 2013 From: lord2y at gmail.com (Alessandro Ratti) Date: Fri, 5 Jul 2013 15:06:19 +0200 Subject: Helix Solutions Message-ID: Hi list, I have a question for you. Anyone knows or has had to deal with Helix Solutions? They ask me IPv4 space but I have a feeling they want that space for spam activities. Any feedback on them would be welcome. Thanks Regards Alessandro From lord2y at gmail.com Fri Jul 5 13:47:42 2013 From: lord2y at gmail.com (Alessandro Ratti) Date: Fri, 5 Jul 2013 15:47:42 +0200 Subject: Helix Solutions In-Reply-To: <20130705133801.GF24217@leitl.org> References: <20130705133801.GF24217@leitl.org> Message-ID: On Fri, Jul 5, 2013 at 3:38 PM, Eugen Leitl wrote: > On Fri, Jul 05, 2013 at 03:06:19PM +0200, Alessandro Ratti wrote: > > Hi list, > > > > I have a question for you. > > Anyone knows or has had to deal with Helix Solutions? > > The Swiss guys: http://helix-it.ch/ > ? > No seems US company. http://www.helixsolutions.net/ From clayton at MNSi.Net Fri Jul 5 14:05:26 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 05 Jul 2013 10:05:26 -0400 Subject: Helix Solutions In-Reply-To: References: <20130705133801.GF24217@leitl.org> Message-ID: <1373033120_188493@duplo.mnsi.net> Sounds sketchy. Helix Solutions is a specialized IP technology firm, offering the largest inventory of IPv4 address space. Our objective is to enable email marketers to overcome the acute IP shortage and communicate with their target audiences smoothly and effectively. At 09:47 AM 05/07/2013, Alessandro Ratti wrote: >On Fri, Jul 5, 2013 at 3:38 PM, Eugen Leitl wrote: > > > On Fri, Jul 05, 2013 at 03:06:19PM +0200, Alessandro Ratti wrote: > > > Hi list, > > > > > > I have a question for you. > > > Anyone knows or has had to deal with Helix Solutions? > > > > The Swiss guys: http://helix-it.ch/ > > ? > > > >No seems US company. >http://www.helixsolutions.net/ --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From cabenth at gmail.com Fri Jul 5 14:26:30 2013 From: cabenth at gmail.com (eric clark) Date: Fri, 5 Jul 2013 07:26:30 -0700 Subject: Helix Solutions In-Reply-To: <1373033120_188493@duplo.mnsi.net> References: <20130705133801.GF24217@leitl.org> <1373033120_188493@duplo.mnsi.net> Message-ID: I've seen this sort of thing popping up before. Don't quite understand how its going to work. Leasing I understand. So long as you are willing to suffer the revocation of the IP space should the company that was actually ISSUED the IP space looses it for whatever reason... "Buying" I really don't get. IP space that is issued by a registrar is not owned. It is assigned. Sure, its yours until they want it back or you give it back, but its not owned. So, for a person to sell space that was allocated to them, just doesn't make sense. The "provide via GRE or other tunnel" makes me think they're tunneling your traffic to the actual assignee's environment, which would make sense, but then that assignee has to deal with your bandwidth, don't they? Obviously, if you take all of their space, you could physically move it, but if you're only dealing with a portion, and ARIN has it assigned to AS xxx, then you have to be running AS xxx... Sketchy and messy and I don't see how its appropriate. E On Fri, Jul 5, 2013 at 7:05 AM, Clayton Zekelman wrote: > > Sounds sketchy. > > Helix Solutions is a specialized IP technology firm, offering the largest > inventory of IPv4 address space. Our objective is to enable email marketers > to overcome the acute IP shortage and communicate with their target > audiences smoothly and effectively. > > > > At 09:47 AM 05/07/2013, Alessandro Ratti wrote: > >> On Fri, Jul 5, 2013 at 3:38 PM, Eugen Leitl wrote: >> >> > On Fri, Jul 05, 2013 at 03:06:19PM +0200, Alessandro Ratti wrote: >> > > Hi list, >> > > >> > > I have a question for you. >> > > Anyone knows or has had to deal with Helix Solutions? >> > >> > The Swiss guys: http://helix-it.ch/ >> > ? >> > >> >> No seems US company. >> http://www.helixsolutions.net/ >> > > --- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 > > From ops.lists at gmail.com Fri Jul 5 14:30:51 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 5 Jul 2013 20:00:51 +0530 Subject: Helix Solutions In-Reply-To: References: <20130705133801.GF24217@leitl.org> <1373033120_188493@duplo.mnsi.net> Message-ID: Classic snowshoe setup. A /24 full of randomized reverse dns records emitting spam that's sent over gre tunnels from a single mothership. Either that or 'seo' on much the same principle. --srs (htc one x) On 05-Jul-2013 7:58 PM, "eric clark" wrote: > I've seen this sort of thing popping up before. > > Don't quite understand how its going to work. Leasing I understand. So long > as you are willing to suffer the revocation of the IP space should the > company that was actually ISSUED the IP space looses it for whatever > reason... > > "Buying" I really don't get. IP space that is issued by a registrar is not > owned. It is assigned. Sure, its yours until they want it back or you give > it back, but its not owned. So, for a person to sell space that was > allocated to them, just doesn't make sense. > > The "provide via GRE or other tunnel" makes me think they're tunneling your > traffic to the actual assignee's environment, which would make sense, but > then that assignee has to deal with your bandwidth, don't they? Obviously, > if you take all of their space, you could physically move it, but if you're > only dealing with a portion, and ARIN has it assigned to AS xxx, then you > have to be running AS xxx... > > Sketchy and messy and I don't see how its appropriate. > > E > > > > > > On Fri, Jul 5, 2013 at 7:05 AM, Clayton Zekelman wrote: > > > > > Sounds sketchy. > > > > Helix Solutions is a specialized IP technology firm, offering the largest > > inventory of IPv4 address space. Our objective is to enable email > marketers > > to overcome the acute IP shortage and communicate with their target > > audiences smoothly and effectively. > > > > > > > > At 09:47 AM 05/07/2013, Alessandro Ratti wrote: > > > >> On Fri, Jul 5, 2013 at 3:38 PM, Eugen Leitl wrote: > >> > >> > On Fri, Jul 05, 2013 at 03:06:19PM +0200, Alessandro Ratti wrote: > >> > > Hi list, > >> > > > >> > > I have a question for you. > >> > > Anyone knows or has had to deal with Helix Solutions? > >> > > >> > The Swiss guys: http://helix-it.ch/ > >> > ? > >> > > >> > >> No seems US company. > >> http://www.helixsolutions.net/ > >> > > > > --- > > > > Clayton Zekelman > > Managed Network Systems Inc. (MNSi) > > 3363 Tecumseh Rd. E > > Windsor, Ontario > > N8W 1H4 > > > > tel. 519-985-8410 > > fax. 519-985-8409 > > > > > From globichen at gmail.com Fri Jul 5 13:17:29 2013 From: globichen at gmail.com (Andy B.) Date: Fri, 5 Jul 2013 15:17:29 +0200 Subject: Helix Solutions In-Reply-To: References: Message-ID: Stay away from them. They contacted us as well and my impression was that they are up to no good. They will burn your IPs in no time. Email contact was rather anonymous. The person I dealt with refused to phone or skype to discuss further. At that point I said goodbye. On Fri, Jul 5, 2013 at 3:06 PM, Alessandro Ratti wrote: > Hi list, > > I have a question for you. > Anyone knows or has had to deal with Helix Solutions? > They ask me IPv4 space but I have a feeling they want that space for spam > activities. > > Any feedback on them would be welcome. > > Thanks > > Regards > > Alessandro From cscora at apnic.net Fri Jul 5 18:33:18 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Jul 2013 04:33:18 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201307051833.r65IXIxl021914@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 06 Jul, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 457245 Prefixes after maximum aggregation: 186378 Deaggregation factor: 2.45 Unique aggregates announced to Internet: 227307 Total ASes present in the Internet Routing Table: 44422 Prefixes per ASN: 10.29 Origin-only ASes present in the Internet Routing Table: 34778 Origin ASes announcing only one prefix: 16159 Transit ASes present in the Internet Routing Table: 5883 Transit-only ASes present in the Internet Routing Table: 149 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 2057 Unregistered ASNs in the Routing Table: 954 Number of 32-bit ASNs allocated by the RIRs: 4849 Number of 32-bit ASNs visible in the Routing Table: 3761 Prefixes from 32-bit ASNs in the Routing Table: 11148 Special use prefixes present in the Routing Table: 26 Prefixes being announced from unallocated address space: 229 Number of addresses announced to Internet: 2627368716 Equivalent to 156 /8s, 154 /16s and 119 /24s Percentage of available address space announced: 71.0 Percentage of allocated address space announced: 71.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.7 Total number of prefixes smaller than registry allocations: 160122 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109526 Total APNIC prefixes after maximum aggregation: 33712 APNIC Deaggregation factor: 3.25 Prefixes being announced from the APNIC address blocks: 111400 Unique aggregates announced from the APNIC address blocks: 45812 APNIC Region origin ASes present in the Internet Routing Table: 4855 APNIC Prefixes per ASN: 22.95 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 823 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 594 Number of APNIC addresses announced to Internet: 725326816 Equivalent to 43 /8s, 59 /16s and 155 /24s Percentage of available APNIC address space announced: 84.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 158961 Total ARIN prefixes after maximum aggregation: 80408 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 159568 Unique aggregates announced from the ARIN address blocks: 73819 ARIN Region origin ASes present in the Internet Routing Table: 15747 ARIN Prefixes per ASN: 10.13 ARIN Region origin ASes announcing only one prefix: 5988 ARIN Region transit ASes present in the Internet Routing Table: 1638 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1065545024 Equivalent to 63 /8s, 130 /16s and 237 /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: 117757 Total RIPE prefixes after maximum aggregation: 60247 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 121219 Unique aggregates announced from the RIPE address blocks: 78510 RIPE Region origin ASes present in the Internet Routing Table: 17267 RIPE Prefixes per ASN: 7.02 RIPE Region origin ASes announcing only one prefix: 8183 RIPE Region transit ASes present in the Internet Routing Table: 2837 Average RIPE Region AS path length visible: 5.2 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2372 Number of RIPE addresses announced to Internet: 656761444 Equivalent to 39 /8s, 37 /16s and 98 /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, 196608-199679 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: 48702 Total LACNIC prefixes after maximum aggregation: 9452 LACNIC Deaggregation factor: 5.15 Prefixes being announced from the LACNIC address blocks: 53152 Unique aggregates announced from the LACNIC address blocks: 24967 LACNIC Region origin ASes present in the Internet Routing Table: 1970 LACNIC Prefixes per ASN: 26.98 LACNIC Region origin ASes announcing only one prefix: 581 LACNIC Region transit ASes present in the Internet Routing Table: 360 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 770 Number of LACNIC addresses announced to Internet: 133069448 Equivalent to 7 /8s, 238 /16s and 122 /24s Percentage of available LACNIC address space announced: 79.3 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: 11061 Total AfriNIC prefixes after maximum aggregation: 2518 AfriNIC Deaggregation factor: 4.39 Prefixes being announced from the AfriNIC address blocks: 11677 Unique aggregates announced from the AfriNIC address blocks: 3988 AfriNIC Region origin ASes present in the Internet Routing Table: 645 AfriNIC Prefixes per ASN: 18.10 AfriNIC Region origin ASes announcing only one prefix: 192 AfriNIC Region transit ASes present in the Internet Routing Table: 134 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46364160 Equivalent to 2 /8s, 195 /16s and 118 /24s Percentage of available AfriNIC address space announced: 46.1 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 2939 11561 922 Korea Telecom (KIX) 17974 2569 855 92 PT TELEKOMUNIKASI INDONESIA 7545 2026 320 108 TPG Internet Pty Ltd 4755 1754 391 192 TATA Communications formerly 9829 1517 1205 40 BSNL National Internet Backbo 9583 1462 117 563 Sify Limited 4808 1173 2151 340 CNCGROUP IP network: China169 9498 1149 309 71 BHARTI Airtel Ltd. 7552 1130 1080 13 Vietel Corporation 24560 1080 394 164 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 2990 3691 69 bellsouth.net, inc. 18566 2066 382 184 Covad Communications 1785 1997 678 126 PaeTec Communications, Inc. 22773 1988 2927 123 Cox Communications, Inc. 20115 1667 1618 620 Charter Communications 4323 1621 1137 403 Time Warner Telecom 701 1531 11127 798 UUNET Technologies, Inc. 30036 1338 300 662 Mediacom Communications Corp 7018 1295 11035 819 AT&T WorldNet Services 11492 1223 218 359 Cable One 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 1607 544 16 Corbina telecom 34984 1280 244 222 BILISIM TELEKOM 2118 1271 97 13 EUnet/RELCOM Autonomous Syste 20940 907 318 712 Akamai Technologies European 31148 808 40 25 FreeNet ISP 13188 788 95 93 Educational Network 6830 782 2375 439 UPC Distribution Services 8551 780 370 45 Bezeq International 12479 673 789 57 Uni2 Autonomous System 34744 656 171 76 SC GVM SISTEM 2003 SRL 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 2918 1576 107 NET Servicos de Comunicao S.A 10620 2684 421 191 TVCABLE BOGOTA 7303 1732 1155 221 Telecom Argentina Stet-France 8151 1256 2743 382 UniNet S.A. de C.V. 18881 1092 844 20 Global Village Telecom 6503 862 434 65 AVANTEL, S.A. 27947 824 94 93 Telconet S.A 3816 717 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 22047 585 334 15 VTR PUNTO NET S.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 1298 80 4 MOBITEL 24863 883 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 461 956 9 TEDATA 24835 345 80 8 RAYA Telecom - Egypt 3741 259 922 218 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 29571 219 17 12 Ci Telecom Autonomous system 36992 203 527 21 Etisalat MISR 12258 194 28 67 Vodacom Internet Company 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 6389 2990 3691 69 bellsouth.net, inc. 4766 2939 11561 922 Korea Telecom (KIX) 28573 2918 1576 107 NET Servicos de Comunicao S.A 10620 2684 421 191 TVCABLE BOGOTA 17974 2569 855 92 PT TELEKOMUNIKASI INDONESIA 18566 2066 382 184 Covad Communications 7545 2026 320 108 TPG Internet Pty Ltd 1785 1997 678 126 PaeTec Communications, Inc. 22773 1988 2927 123 Cox Communications, Inc. 4755 1754 391 192 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2918 2811 NET Servicos de Comunicao S.A 10620 2684 2493 TVCABLE BOGOTA 17974 2569 2477 PT TELEKOMUNIKASI INDONESIA 4766 2939 2017 Korea Telecom (KIX) 7545 2026 1918 TPG Internet Pty Ltd 18566 2066 1882 Covad Communications 1785 1997 1871 PaeTec Communications, Inc. 22773 1988 1865 Cox Communications, Inc. 8402 1607 1591 Corbina telecom 4755 1754 1562 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.42.0/24 60619 >>UNKNOWN<< 128.0.43.0/24 60619 >>UNKNOWN<< 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.57.0/24 60993 Totalsoft SA Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. 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:11 /10:30 /11:92 /12:250 /13:482 /14:899 /15:1603 /16:12708 /17:6636 /18:11097 /19:22496 /20:32068 /21:34463 /22:48120 /23:42352 /24:240124 /25:1274 /26:1533 /27:847 /28:43 /29:67 /30:18 /31:0 /32:16 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2017 2066 Covad Communications 6389 1717 2990 bellsouth.net, inc. 8402 1317 1607 Corbina telecom 22773 1293 1988 Cox Communications, Inc. 36998 1266 1298 MOBITEL 30036 1206 1338 Mediacom Communications Corp 11492 1184 1223 Cable One 1785 1065 1997 PaeTec Communications, Inc. 6983 1015 1144 ITC^Deltacom 10620 998 2684 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:844 2:750 3:3 4:15 5:813 6:16 8:562 12:1920 13:3 14:863 15:11 16:3 17:10 20:17 23:295 24:1771 27:1473 31:1249 32:45 33:2 34:5 36:52 37:1851 38:878 39:2 40:171 41:2791 42:214 44:8 46:1917 47:2 49:664 50:750 52:12 54:35 55:4 57:26 58:1154 59:584 60:328 61:1409 62:1129 63:2013 64:4329 65:2160 66:4173 67:2029 68:1076 69:3279 70:835 71:491 72:1930 74:2465 75:324 76:309 77:1118 78:1011 79:619 80:1274 81:1016 82:630 83:592 84:588 85:1178 86:449 87:1012 88:544 89:1751 90:149 91:5516 92:606 93:1775 94:1895 95:1635 96:523 97:342 98:1016 99:42 100:30 101:320 103:2924 105:519 106:138 107:207 108:513 109:1840 110:912 111:1059 112:543 113:815 114:682 115:964 116:959 117:799 118:1092 119:1315 120:387 121:735 122:1796 123:1216 124:1375 125:1384 128:623 129:225 130:304 131:668 132:359 133:155 134:269 135:68 136:223 137:243 138:340 139:190 140:209 141:326 142:541 143:377 144:482 145:94 146:510 147:386 148:644 149:351 150:146 151:520 152:417 153:189 154:24 155:413 156:265 157:399 158:279 159:712 160:344 161:451 162:470 163:222 164:602 165:498 166:245 167:595 168:1021 169:128 170:1058 171:180 172:21 173:1594 174:544 175:474 176:1118 177:2133 178:1852 179:52 180:1459 181:500 182:1257 183:423 184:668 185:609 186:2303 187:1302 188:2062 189:1274 190:6773 192:6805 193:5850 194:4624 195:3462 196:1362 197:934 198:4504 199:5351 200:5972 201:2149 202:8788 203:8883 204:4510 205:2557 206:2808 207:2848 208:4019 209:3607 210:2923 211:1519 212:2187 213:1985 214:905 215:99 216:5249 217:1619 218:621 219:322 220:1281 221:557 222:321 223:451 End of report From tim at interworx.nl Fri Jul 5 19:40:53 2013 From: tim at interworx.nl (Tim Vollebregt) Date: Fri, 5 Jul 2013 21:40:53 +0200 Subject: Urgent: rack mounting kit / rack shelf Message-ID: Hi, Colleagues are racking some very heavy routers in the Equinix SV1 (San Jose) location and are in need of rack shelf or a universal rack mounting kit. Does anyone know stores which might have these in stock in the SV area? Thanks in advance Tim Sent from my mobile device From johnl at iecc.com Fri Jul 5 19:43:00 2013 From: johnl at iecc.com (John Levine) Date: 5 Jul 2013 19:43:00 -0000 Subject: Helix Solutions In-Reply-To: Message-ID: <20130705194300.28854.qmail@joyce.lan> >No seems US company. >http://www.helixsolutions.net/ They're registered at internet.bs with a private registration in Panama. What more do you need, a big flashing skull and crossbones? From ilan at jobvite.com Fri Jul 5 19:54:30 2013 From: ilan at jobvite.com (Ilan Erenstein) Date: Fri, 5 Jul 2013 19:54:30 +0000 Subject: Urgent: rack mounting kit / rack shelf In-Reply-To: References: Message-ID: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> Tim, You might want to check out Central Computers. I used to work in the area so there are tons of them around. Here is the shelf that might work for you: http://www.centralcomputers.com/ccp85433-startech-adjshelfhdv-1u-19--adjustable-vented-rac-adjshelfhdv-misstashel2r.htm And here is the manufacturer spec for it: http://de.startech.com/en/Server-Management/Racks/1U-Adjustable-Depth-Vented-Rack-Mount-Shelf-Heavy-Duty-Fixed-Server-Rack-Cabinet-Shelf-250lbs-113kg~ADJSHELFHDV My advice is to call ahead and make sure they have it before you go down there. -Ilan On Jul 5, 2013, at 12:40 PM, Tim Vollebregt > wrote: Hi, Colleagues are racking some very heavy routers in the Equinix SV1 (San Jose) location and are in need of rack shelf or a universal rack mounting kit. Does anyone know stores which might have these in stock in the SV area? Thanks in advance Tim Sent from my mobile device From mike.lyon at gmail.com Fri Jul 5 20:16:02 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 5 Jul 2013 13:16:02 -0700 Subject: Urgent: rack mounting kit / rack shelf In-Reply-To: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> References: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> Message-ID: <-4475003402864125749@unknownmsgid> Frys on Kifer have them as does Halted Specialties at Lawrence Expwy and Central Expwy. -Mike Sent from my iPhone On Jul 5, 2013, at 12:56, Ilan Erenstein wrote: > Tim, > > You might want to check out Central Computers. I used to work in the area so there are tons of them around. > > Here is the shelf that might work for you: http://www.centralcomputers.com/ccp85433-startech-adjshelfhdv-1u-19--adjustable-vented-rac-adjshelfhdv-misstashel2r.htm > > And here is the manufacturer spec for it: http://de.startech.com/en/Server-Management/Racks/1U-Adjustable-Depth-Vented-Rack-Mount-Shelf-Heavy-Duty-Fixed-Server-Rack-Cabinet-Shelf-250lbs-113kg~ADJSHELFHDV > > My advice is to call ahead and make sure they have it before you go down there. > > -Ilan > > On Jul 5, 2013, at 12:40 PM, Tim Vollebregt > wrote: > > Hi, > > Colleagues are racking some very heavy routers in the Equinix SV1 (San Jose) location and are in need of rack shelf or a universal rack mounting kit. > > Does anyone know stores which might have these in stock in the SV area? > > Thanks in advance > > Tim > > Sent from my mobile device > From matthew at sorbs.net Fri Jul 5 20:18:22 2013 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 05 Jul 2013 22:18:22 +0200 Subject: Urgent: rack mounting kit / rack shelf In-Reply-To: <-4475003402864125749@unknownmsgid> References: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> <-4475003402864125749@unknownmsgid> Message-ID: If it's not 'standard' weird stuff in Sunnyvale (area) also has a big selection of pre-loved kits.. Michelle Michelle Sullivan http://www.mhix.org/ Sent from my iPad On 05 Jul 2013, at 22:16, Mike Lyon wrote: > Frys on Kifer have them as does Halted Specialties at Lawrence Expwy > and Central Expwy. > > -Mike > > Sent from my iPhone > > On Jul 5, 2013, at 12:56, Ilan Erenstein wrote: > >> Tim, >> >> You might want to check out Central Computers. I used to work in the area so there are tons of them around. >> >> Here is the shelf that might work for you: http://www.centralcomputers.com/ccp85433-startech-adjshelfhdv-1u-19--adjustable-vented-rac-adjshelfhdv-misstashel2r.htm >> >> And here is the manufacturer spec for it: http://de.startech.com/en/Server-Management/Racks/1U-Adjustable-Depth-Vented-Rack-Mount-Shelf-Heavy-Duty-Fixed-Server-Rack-Cabinet-Shelf-250lbs-113kg~ADJSHELFHDV >> >> My advice is to call ahead and make sure they have it before you go down there. >> >> -Ilan >> >> On Jul 5, 2013, at 12:40 PM, Tim Vollebregt > wrote: >> >> Hi, >> >> Colleagues are racking some very heavy routers in the Equinix SV1 (San Jose) location and are in need of rack shelf or a universal rack mounting kit. >> >> Does anyone know stores which might have these in stock in the SV area? >> >> Thanks in advance >> >> Tim >> >> Sent from my mobile device >> > From ka at pacific.net Fri Jul 5 20:19:34 2013 From: ka at pacific.net (Ken A) Date: Fri, 05 Jul 2013 15:19:34 -0500 Subject: Helix Solutions In-Reply-To: References: Message-ID: <51D72A56.7020908@pacific.net> I wonder who that building on their website actually belongs to, or if it even exists? http://www.tineye.com/search/776bee3aea6d8f901758534a2fb3b9d5718ad256/ heh heh. Ken On 7/5/2013 8:06 AM, Alessandro Ratti wrote: > Hi list, > > I have a question for you. > Anyone knows or has had to deal with Helix Solutions? > They ask me IPv4 space but I have a feeling they want that space for spam > activities. > > Any feedback on them would be welcome. > > Thanks > > Regards > > Alessandro > -- Ken Anderson Pacific Internet - http://www.pacific.net From mike.lyon at gmail.com Fri Jul 5 20:23:22 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 5 Jul 2013 13:23:22 -0700 Subject: Urgent: rack mounting kit / rack shelf In-Reply-To: References: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> <-4475003402864125749@unknownmsgid> Message-ID: Yes, they do, and I forgot to mention that place, they have TONS of rack shelves. -Mike On Fri, Jul 5, 2013 at 1:18 PM, Michelle Sullivan wrote: > If it's not 'standard' weird stuff in Sunnyvale (area) also has a big > selection of pre-loved kits.. > > Michelle > > Michelle Sullivan > http://www.mhix.org/ > Sent from my iPad > > On 05 Jul 2013, at 22:16, Mike Lyon wrote: > > > Frys on Kifer have them as does Halted Specialties at Lawrence Expwy > > and Central Expwy. > > > > -Mike > > > > Sent from my iPhone > > > > On Jul 5, 2013, at 12:56, Ilan Erenstein wrote: > > > >> Tim, > >> > >> You might want to check out Central Computers. I used to work in the > area so there are tons of them around. > >> > >> Here is the shelf that might work for you: > http://www.centralcomputers.com/ccp85433-startech-adjshelfhdv-1u-19--adjustable-vented-rac-adjshelfhdv-misstashel2r.htm > >> > >> And here is the manufacturer spec for it: > http://de.startech.com/en/Server-Management/Racks/1U-Adjustable-Depth-Vented-Rack-Mount-Shelf-Heavy-Duty-Fixed-Server-Rack-Cabinet-Shelf-250lbs-113kg~ADJSHELFHDV > >> > >> My advice is to call ahead and make sure they have it before you go > down there. > >> > >> -Ilan > >> > >> On Jul 5, 2013, at 12:40 PM, Tim Vollebregt tim at interworx.nl>> wrote: > >> > >> Hi, > >> > >> Colleagues are racking some very heavy routers in the Equinix SV1 (San > Jose) location and are in need of rack shelf or a universal rack mounting > kit. > >> > >> Does anyone know stores which might have these in stock in the SV area? > >> > >> Thanks in advance > >> > >> Tim > >> > >> Sent from my mobile device > >> > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From gary.buhrmaster at gmail.com Fri Jul 5 20:44:03 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 5 Jul 2013 20:44:03 +0000 Subject: Urgent: rack mounting kit / rack shelf In-Reply-To: <-4475003402864125749@unknownmsgid> References: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> <-4475003402864125749@unknownmsgid> Message-ID: On Fri, Jul 5, 2013 at 8:16 PM, Mike Lyon wrote: > Frys on Kifer Fry's is actually on Arques Ave in Sunnyvale. Not sure about all the Fry's, but the Sunnyvale store has "re-imagined" itself (no longer has rows upon rows of 8' shelves, they are now all about 5' tall, so you get a more open store experience) and no longer has quite the amount of rack stock on display it once had. I presume they have it in the back storeroom if one asks. +1 for Weirdstuff for random new-to-you racks and accessories (and I believe they have even more in their warehouse area, if you ask). Gary From mike.lyon at gmail.com Fri Jul 5 20:46:06 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 5 Jul 2013 13:46:06 -0700 Subject: Urgent: rack mounting kit / rack shelf In-Reply-To: References: <0EEE8563-DC54-4D6E-876E-0407CA31E0FE@jobvite.com> <-4475003402864125749@unknownmsgid> Message-ID: Doh! Yes, Arques! My bad! Halted and WeirdStuf both have rack shelves. -Mike On Fri, Jul 5, 2013 at 1:44 PM, Gary Buhrmaster wrote: > On Fri, Jul 5, 2013 at 8:16 PM, Mike Lyon wrote: > > Frys on Kifer > > Fry's is actually on Arques Ave in Sunnyvale. > > Not sure about all the Fry's, but the Sunnyvale store has "re-imagined" > itself (no longer has rows upon rows of 8' shelves, they are now all > about 5' tall, so you get a more open store experience) and no longer > has quite the amount of rack stock on display it once had. I presume > they have it in the back storeroom if one asks. > > +1 for Weirdstuff for random new-to-you racks and accessories > (and I believe they have even more in their warehouse area, if you > ask). > > Gary > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From cidr-report at potaroo.net Fri Jul 5 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Jul 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201307052200.r65M00p9017063@wattle.apnic.net> This report has been generated at Fri Jul 5 21:13:24 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-06-13 467649 265547 29-06-13 467674 265554 30-06-13 467686 265411 01-07-13 467550 265422 02-07-13 467581 265413 03-07-13 467818 265546 04-07-13 467704 266352 05-07-13 468162 265844 AS Summary 44574 Number of ASes in routing system 18393 Number of ASes announcing only one prefix 4241 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 116932576 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'). --- 05Jul13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 468542 265897 202645 43.3% All ASes AS6389 2990 73 2917 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2900 107 2793 96.3% NET Servi?os de Comunica??o S.A. AS7029 4241 2106 2135 50.3% WINDSTREAM - Windstream Communications Inc AS17974 2568 550 2018 78.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2939 937 2002 68.1% KIXS-AS-KR Korea Telecom AS10620 2685 693 1992 74.2% Telmex Colombia S.A. AS22773 1988 170 1818 91.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2066 468 1598 77.3% COVAD - Covad Communications Co. AS4323 2988 1531 1457 48.8% TWTC - tw telecom holdings, inc. AS7303 1732 454 1278 73.8% Telecom Argentina S.A. AS7545 2031 755 1276 62.8% TPG-INTERNET-AP TPG Telecom Limited AS2118 1271 87 1184 93.2% RELCOM-AS OOO "NPO Relcom" AS4755 1752 584 1168 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18881 1117 43 1074 96.2% Global Village Telecom AS7552 1190 207 983 82.6% VIETEL-AS-AP Vietel Corporation AS36998 1298 420 878 67.6% SDN-MOBITEL AS1785 1997 1152 845 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1002 182 820 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS33363 2031 1249 782 38.5% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS4808 1173 398 775 66.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1532 803 729 47.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 841 139 702 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS22561 1195 516 679 56.8% DIGITAL-TELEPORT - Digital Teleport Inc. AS855 728 54 674 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1144 477 667 58.3% ITCDELTA - ITC^Deltacom AS24560 1080 414 666 61.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1273 613 660 51.8% Uninet S.A. de C.V. AS4788 754 117 637 84.5% TMNET-AS-AP TM Net, Internet Service Provider AS17676 737 114 623 84.5% GIGAINFRA Softbank BB Corp. AS31148 808 198 610 75.5% FREENET-AS Freenet Ltd. Total 52051 15611 36440 70.0% Top 30 total Possible Bogus Routes 5.200.128.0/17 AS59628 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.187.208.0/24 AS174 COGENT Cogent/PSI 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.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 77.75.216.0/21 AS43716 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.68.144.0/20 AS33982 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 115.31.64.0/20 AS17639 COMCLARK-AS ComClark Network & Technology Corp. 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 186.216.216.0/21 AS52999 STARTNET COMERCIO E SERVICOS DE INFORMATICA LTDA 186.224.88.0/21 AS26247 PROVEDOR BRCENTRAL.NET LTDA 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 194.169.237.0/24 AS12968 CDP Netia SA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 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.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.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 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.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 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 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 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.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, 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 Jul 5 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Jul 2013 22:00:00 GMT Subject: BGP Update Report Message-ID: <201307052200.r65M00he017079@wattle.apnic.net> BGP Update Report Interval: 27-Jun-13 -to- 04-Jul-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35819 166916 7.7% 335.8 -- MOBILY-AS Etihad Etisalat Company (Mobily) 2 - AS9829 34666 1.6% 40.9 -- BSNL-NIB National Internet Backbone 3 - AS4755 33298 1.5% 24.8 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 4 - AS5800 32606 1.5% 143.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - AS8402 29695 1.4% 33.5 -- CORBINA-AS OJSC "Vimpelcom" 6 - AS4538 24341 1.1% 43.9 -- ERX-CERNET-BKB China Education and Research Network Center 7 - AS7552 21309 1.0% 18.5 -- VIETEL-AS-AP Vietel Corporation 8 - AS9416 18453 0.8% 2636.1 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 9 - AS27738 18107 0.8% 49.5 -- Ecuadortelecom S.A. 10 - AS18403 17762 0.8% 46.5 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 11 - AS36998 17379 0.8% 13.4 -- SDN-MOBITEL 12 - AS13208 17214 0.8% 8607.0 -- NEWTELSOLUTIONS-AS Newtel Ltd 13 - AS10620 16279 0.8% 8.5 -- Telmex Colombia S.A. 14 - AS4775 15592 0.7% 147.1 -- GLOBE-TELECOM-AS Globe Telecoms 15 - AS34315 13892 0.6% 3473.0 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 16 - AS34969 13304 0.6% 1663.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 17 - AS9198 12855 0.6% 21.2 -- KAZTELECOM-AS JSC Kazakhtelecom 18 - AS9116 12296 0.6% 26.5 -- GOLDENLINES-ASN 012 Smile Communications Ltd. 19 - AS9583 11786 0.5% 9.8 -- SIFY-AS-IN Sify Limited 20 - AS31148 11134 0.5% 16.5 -- FREENET-AS Freenet Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13208 17214 0.8% 8607.0 -- NEWTELSOLUTIONS-AS Newtel Ltd 2 - AS9854 5639 0.3% 5639.0 -- KTO-AS-KR KTO 3 - AS11017 4630 0.2% 4630.0 -- CSN - CSN Support Services 4 - AS6629 8733 0.4% 4366.5 -- NOAA-AS - NOAA 5 - AS31461 3539 0.2% 3539.0 -- MORAVIA-IT-AS Moravia IT, a.s. 6 - AS34315 13892 0.6% 3473.0 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 7 - AS6174 6922 0.3% 3461.0 -- SPRINTLINK8 - Sprint 8 - AS4 5794 0.3% 30.0 -- COMUNICALO DE MEXICO S.A. DE C.V 9 - AS14733 7926 0.4% 2642.0 -- AS14733 - Barclays Capital Inc. 10 - AS9416 18453 0.8% 2636.1 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - AS8137 4933 0.2% 2466.5 -- DISNEYONLINE-AS - Disney Online 12 - AS36976 2158 0.1% 2158.0 -- SONANGOL 13 - AS34969 13304 0.6% 1663.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 14 - AS37367 1602 0.1% 1602.0 -- CALLKEY 15 - AS23394 5582 0.3% 1395.5 -- PSPINC-BDC - Pacific Software Publishing, Inc. 16 - AS37373 1211 0.1% 1211.0 -- AUC-ASN 17 - AS52572 2394 0.1% 1197.0 -- Easy Call SCM do Brasil LTDA 18 - AS23295 929 0.0% 929.0 -- EA-01 - Extend America 19 - AS22688 908 0.0% 908.0 -- DOLGENCORP - Dollar General Corporation 20 - AS55150 837 0.0% 837.0 -- DST-01 - DST Resources TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.118.224.0/21 9279 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 2 - 203.118.232.0/21 9164 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 3 - 5.108.104.0/22 8791 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 4 - 5.108.84.0/22 8781 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 5 - 5.108.64.0/22 8781 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 6 - 5.108.72.0/22 8778 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 7 - 5.108.92.0/22 8776 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 8 - 5.108.76.0/22 8773 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 9 - 5.108.80.0/22 8773 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 10 - 5.108.68.0/22 8771 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 11 - 5.108.108.0/22 8771 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 12 - 5.108.100.0/22 8769 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 13 - 5.108.96.0/22 8767 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 14 - 5.108.88.0/22 8758 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 15 - 5.108.126.0/23 8747 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 16 - 5.108.124.0/23 8747 0.4% AS35819 -- MOBILY-AS Etihad Etisalat Company (Mobily) 17 - 92.246.207.0/24 8744 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 18 - 192.58.232.0/24 8729 0.4% AS6629 -- NOAA-AS - NOAA 19 - 213.133.193.0/24 8647 0.4% AS13208 -- NEWTELSOLUTIONS-AS Newtel Ltd 20 - 213.133.192.0/24 8567 0.4% AS13208 -- NEWTELSOLUTIONS-AS Newtel Ltd 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 saku at ytti.fi Tue Jul 9 08:38:37 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 9 Jul 2013 11:38:37 +0300 Subject: disregard, test Message-ID: <20130709083837.GA21000@pob.ytti.fi> https://i.chzbgr.com/maxW500/7644490752/h49306FE3/ many complain that they've not seen emails from nanog in few days (since 5th day of 'The Cidr Report') -- ++ytti From froztbyte at froztbyte.net Tue Jul 9 08:45:31 2013 From: froztbyte at froztbyte.net (JP) Date: Tue, 9 Jul 2013 10:45:31 +0200 Subject: disregard, test In-Reply-To: <20130709083837.GA21000@pob.ytti.fi> References: <20130709083837.GA21000@pob.ytti.fi> Message-ID: <20130709084531.GA25579@elegua.za.net> On Tue, Jul 09, 2013 at 11:38:37AM +0300, Saku Ytti wrote: > https://i.chzbgr.com/maxW500/7644490752/h49306FE3/ > > many complain that they've not seen emails from nanog in few days (since > 5th day of 'The Cidr Report') Test win condition not specified. -J From shrdlu at deaddrop.org Tue Jul 9 12:31:13 2013 From: shrdlu at deaddrop.org (Shrdlu) Date: Tue, 09 Jul 2013 05:31:13 -0700 Subject: disregard, test In-Reply-To: <20130709083837.GA21000@pob.ytti.fi> References: <20130709083837.GA21000@pob.ytti.fi> Message-ID: <51DC0291.2080501@deaddrop.org> On 7/9/2013 1:38 AM, Saku Ytti wrote: > https://i.chzbgr.com/maxW500/7644490752/h49306FE3/ > > many complain that they've not seen emails from nanog in few days (since > 5th day of 'The Cidr Report') Next time? Please consider just examining the archives, so that you may verify that indeed, a miracle has occurred, and that indeed, no one has anything in particular to say. I admit that I checked the archives myself, when it seemed to quiet. http://mailman.nanog.org/pipermail/nanog/ Here's hoping for a quiet week, with no operational (or other) issues that need NANOG participants' attention. From saku at ytti.fi Tue Jul 9 12:42:22 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 9 Jul 2013 15:42:22 +0300 Subject: disregard, test In-Reply-To: <51DC0291.2080501@deaddrop.org> References: <20130709083837.GA21000@pob.ytti.fi> <51DC0291.2080501@deaddrop.org> Message-ID: <20130709124222.GA15225@pob.ytti.fi> On (2013-07-09 05:31 -0700), Shrdlu wrote: > Next time? Please consider just examining the archives, so that you may > verify that indeed, a miracle has occurred, and that indeed, no one has > anything in particular to say. I admit that I checked the archives > myself, when it seemed to quiet. I'm not sure how no mails arriving to the archive prove that the list is working? :) But I could sell you mailing list as service, if that is acceptable SLA metric for the service being up. 100% availability guaranteed. :) -- ++ytti From obrith at gmail.com Tue Jul 9 23:02:21 2013 From: obrith at gmail.com (Mike McLaughlin) Date: Tue, 9 Jul 2013 16:02:21 -0700 Subject: Comcast using private space and trying to use pool.ntp.org Message-ID: This is a friendly note to any Comcast net admins who might be interested: We have a Business Fiber circuit and run a public NTP server in the pool. It seems Comcast is using private IP space (mostly 10.29.0.0/16 and 10.183.0.0/16) for equipment and are trying to use the NTP pool for time services (without NAT). Clearly that isn't working out so hot - my firewall logs are chalk full of requests from those two networks, so I'd assume it's a pretty large number of misconfigured devices since I'm one of many many pool servers - and it's fairly safe to assume they're Comcast devices since they aren't getting eaten before hitting my firewall from Cocmast. Just for laughs, I suspect, Comcast blocks bogons at my gateway, so I couldn't even let them get time from me if I wanted to. Clearly not a critical (to me) issue, but I figured it was worth passing along since I count on Comcast for interwebs and it's likely Comcast could see time sync issues related to this. Sincerely, Mike McLaughlin From janets at nairial.net Tue Jul 9 20:41:10 2013 From: janets at nairial.net (Janet Sullivan) Date: Tue, 9 Jul 2013 20:41:10 +0000 Subject: Anyone from frontiernet.net on here? Message-ID: <8efc4e2baff7443f8dfd052e560f4d98@BY2PR07MB043.namprd07.prod.outlook.com> I've been seeing really bad packet loss between PCCW and frontier, and so far haven't been able to make any traction with anyone on either side. I'm betting that the ??? is a peering point either in London or Ashburn. uk.bgp4.net (0.0.0.0) Tue Jul 9 20:39:53 2013 Keys: Help Display mode Restart statistics Order of fields qu it Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 212.111.33.230 0.0% 43 1.7 0.7 0.5 1.8 0.3 2. 212.111.33.237 0.0% 43 2.3 1.9 1.1 22.7 3.3 3. 63.218.13.221 0.0% 43 2.3 15.6 1.1 230.3 45.9 4. ??? 5. 74.40.2.173 23.3% 43 177.9 150.3 147.8 177.9 7.0 6. 74.40.2.193 20.9% 43 149.9 149.9 149.1 161.2 2.1 7. 74.40.3.241 18.6% 43 149.6 152.4 149.1 193.2 8.8 8. 74.40.5.49 28.6% 43 148.1 150.8 147.8 192.1 9.9 9. 74.40.5.54 26.2% 43 148.3 150.5 147.9 218.7 12.6 10. 74.40.5.46 33.3% 42 149.5 154.0 149.2 212.8 14.0 11. 74.40.3.137 16.7% 42 147.4 148.7 146.9 163.0 4.1 12. 74.40.1.154 29.3% 42 148.2 153.6 147.7 206.7 14.2 13. 50.34.2.162 35.7% 42 150.2 150.4 149.8 156.3 1.2 14. 50.46.150.55 26.2% 42 150.7 151.0 150.5 152.0 0.4 From darlewis at cisco.com Wed Jul 10 01:57:21 2013 From: darlewis at cisco.com (Darrel Lewis (darlewis)) Date: Wed, 10 Jul 2013 01:57:21 +0000 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Jun 28, 2013, at 7:12 PM, Octavio Alvarez wrote: >> >> Lisp is actually very much about multihoming... In fact that was one of the key reasons it got started. It actually could make >multihoming and mobility very much simpler at the applications if it were used. > > Yeah, but LISP is as [in]accessible to end-users as BGP is and it will > be like that forever. It requires ISPs to opt-in to provide this. LISP > is not a universal option. > > LISP matters to the Internet core, it doesn't matter to the whole Internet. > It is just not universal. LISP does not require your physical ISP to support LISP in order to receive service. It is available in open source as well as low end CPE routers, in addition to larger, more expensive (and capable) routers sold by various vendors. I don't know what you mean by universal, so I can't really respond to that. However, if you'd like a list of LISP service providers to provide you the benefits of multi-homing in a non BGP environment, or to deliver IPv6 packets over an IPv4 intent connection, please contact me off line. -Darrel From wbailey at satelliteintelligencegroup.com Wed Jul 10 02:18:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 10 Jul 2013 02:18:54 +0000 Subject: Anyone from frontiernet.net on here? In-Reply-To: <8efc4e2baff7443f8dfd052e560f4d98@BY2PR07MB043.namprd07.prod.outlook.com> References: <8efc4e2baff7443f8dfd052e560f4d98@BY2PR07MB043.namprd07.prod.outlook.com> Message-ID: There are some decent sized attacks taking place on gear near London, I believe. Could be a result of that? Sent from my Mobile Device. -------- Original message -------- From: Janet Sullivan Date: 07/09/2013 5:01 PM (GMT-08:00) To: nanog at nanog.org Subject: Anyone from frontiernet.net on here? I've been seeing really bad packet loss between PCCW and frontier, and so far haven't been able to make any traction with anyone on either side. I'm betting that the ??? is a peering point either in London or Ashburn. uk.bgp4.net (0.0.0.0) Tue Jul 9 20:39:53 2013 Keys: Help Display mode Restart statistics Order of fields qu it Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 212.111.33.230 0.0% 43 1.7 0.7 0.5 1.8 0.3 2. 212.111.33.237 0.0% 43 2.3 1.9 1.1 22.7 3.3 3. 63.218.13.221 0.0% 43 2.3 15.6 1.1 230.3 45.9 4. ??? 5. 74.40.2.173 23.3% 43 177.9 150.3 147.8 177.9 7.0 6. 74.40.2.193 20.9% 43 149.9 149.9 149.1 161.2 2.1 7. 74.40.3.241 18.6% 43 149.6 152.4 149.1 193.2 8.8 8. 74.40.5.49 28.6% 43 148.1 150.8 147.8 192.1 9.9 9. 74.40.5.54 26.2% 43 148.3 150.5 147.9 218.7 12.6 10. 74.40.5.46 33.3% 42 149.5 154.0 149.2 212.8 14.0 11. 74.40.3.137 16.7% 42 147.4 148.7 146.9 163.0 4.1 12. 74.40.1.154 29.3% 42 148.2 153.6 147.7 206.7 14.2 13. 50.34.2.162 35.7% 42 150.2 150.4 149.8 156.3 1.2 14. 50.46.150.55 26.2% 42 150.7 151.0 150.5 152.0 0.4 From erik.levinson at uberflip.com Wed Jul 10 03:28:14 2013 From: erik.levinson at uberflip.com (Erik Levinson) Date: Tue, 9 Jul 2013 23:28:14 -0400 (EDT) Subject: What to expect after a cooling failure Message-ID: <1373426894.69598008@apps.rackspace.com> As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? Thanks -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From jeff.richmond at gmail.com Wed Jul 10 03:35:31 2013 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Tue, 9 Jul 2013 20:35:31 -0700 Subject: Anyone from frontiernet.net on here? In-Reply-To: References: <8efc4e2baff7443f8dfd052e560f4d98@BY2PR07MB043.namprd07.prod.outlook.com> Message-ID: All it looks like I am seeing packet loss there across all of our peering sessions with them, so looks like a problem on their network. I'll ask our NOC to open up a ticket with them though just to see if we can find out what the issue is. Thanks, -Jeff On Jul 9, 2013, at 7:18 PM, Warren Bailey wrote: > There are some decent sized attacks taking place on gear near London, I believe. Could be a result of that? > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Janet Sullivan > Date: 07/09/2013 5:01 PM (GMT-08:00) > To: nanog at nanog.org > Subject: Anyone from frontiernet.net on here? > > > I've been seeing really bad packet loss between PCCW and frontier, and so far haven't been able to make any traction with anyone on either side. I'm betting that the ??? is a peering point either in London or Ashburn. > > uk.bgp4.net (0.0.0.0) Tue Jul 9 20:39:53 2013 > Keys: Help Display mode Restart statistics Order of fields qu > it Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. 212.111.33.230 0.0% 43 1.7 0.7 0.5 1.8 0.3 > 2. 212.111.33.237 0.0% 43 2.3 1.9 1.1 22.7 3.3 > 3. 63.218.13.221 0.0% 43 2.3 15.6 1.1 230.3 45.9 > 4. ??? > 5. 74.40.2.173 23.3% 43 177.9 150.3 147.8 177.9 7.0 > 6. 74.40.2.193 20.9% 43 149.9 149.9 149.1 161.2 2.1 > 7. 74.40.3.241 18.6% 43 149.6 152.4 149.1 193.2 8.8 > 8. 74.40.5.49 28.6% 43 148.1 150.8 147.8 192.1 9.9 > 9. 74.40.5.54 26.2% 43 148.3 150.5 147.9 218.7 12.6 > 10. 74.40.5.46 33.3% 42 149.5 154.0 149.2 212.8 14.0 > 11. 74.40.3.137 16.7% 42 147.4 148.7 146.9 163.0 4.1 > 12. 74.40.1.154 29.3% 42 148.2 153.6 147.7 206.7 14.2 > 13. 50.34.2.162 35.7% 42 150.2 150.4 149.8 156.3 1.2 > 14. 50.46.150.55 26.2% 42 150.7 151.0 150.5 152.0 0.4 > From contact at nullivex.com Wed Jul 10 03:42:41 2013 From: contact at nullivex.com (Bryan Tong) Date: Tue, 9 Jul 2013 21:42:41 -0600 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: Hello, In my experience with heating issues the only thing that really degrades quickly in event of overheating are hard drives. If you had them spun down it should be fine. CPU / Memory / Motherboards will be fine. The only other thing I can think of having possible issues are PSU's but if they were powered off should be fine as well. Maybe melted wires but I dont think it was hot enough for that. Thanks On Tue, Jul 9, 2013 at 9:28 PM, Erik Levinson wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after > Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much > longer and some of our gear shutdown automatically due to overheating. We > shut down remotely many redundant and non-essential systems in the hotter > suite, and transferred remotely some others to the cooler suite, to ensure > that we had a minimum of all core systems running in the hotter suite. We > waited until the temperatures returned to normal, and brought everything > back online. The entire event lasted from approx 18:45 until 01:15. > Apparently ambient temperature was above 43 degrees Celcius at one point on > the cool side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From erik.levinson at uberflip.com Wed Jul 10 03:50:58 2013 From: erik.levinson at uberflip.com (Erik Levinson) Date: Tue, 9 Jul 2013 23:50:58 -0400 (EDT) Subject: What to expect after a cooling failure In-Reply-To: References: <1373426894.69598008@apps.rackspace.com> Message-ID: <1373428258.880721959@apps.rackspace.com> Thanks. I should also mention that most of the gear was still on but we had turned off many VMs on physical servers within the first 2.5 hours, so the CPU and hard drive / io load was around zero on such servers. Most of the servers in the hotter suite had fans running at over 75% vs. about 35% in the cooler suite and ambient temp was down to 32 degrees Celcius within four hours. -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com -----Original Message----- From: "Bryan Tong" Sent: Tuesday, July 9, 2013 11:42pm To: "Erik Levinson" Cc: "NANOG mailing list" Subject: Re: What to expect after a cooling failure Hello, In my experience with heating issues the only thing that really degrades quickly in event of overheating are hard drives. If you had them spun down it should be fine. CPU / Memory / Motherboards will be fine. The only other thing I can think of having possible issues are PSU's but if they were powered off should be fine as well. Maybe melted wires but I dont think it was hot enough for that. Thanks On Tue, Jul 9, 2013 at 9:28 PM, Erik Levinson wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after > Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much > longer and some of our gear shutdown automatically due to overheating. We > shut down remotely many redundant and non-essential systems in the hotter > suite, and transferred remotely some others to the cooler suite, to ensure > that we had a minimum of all core systems running in the hotter suite. We > waited until the temperatures returned to normal, and brought everything > back online. The entire event lasted from approx 18:45 until 01:15. > Apparently ambient temperature was above 43 degrees Celcius at one point on > the cool side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From jra at baylink.com Wed Jul 10 04:04:23 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 10 Jul 2013 00:04:23 -0400 (EDT) Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> Message-ID: <12057756.1096.1373429063527.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Erik Levinson" > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? If the HDDs were spinning while above rated maximum ambient intake temp, *especially* if they're not *right out front in the intake path* (is anything not built that way anymore? Yeah; the back side of 45-drive Supermicro racks, among other things), you should probably plan on doing a preemptive replacement cycle, or at the very least, pay *very* close attention to smartctld, and have a good stock of pre-trayed replacements. Remember that you may fall in the RAID Hole if you wait for failures, and hence lose data which isn't backed up anyway -- if more drives in a raid group fail *during rebuilds*, you're essentially screwed. If your raid groups were properly dispersed across drive build dates, then this will probably be *slightly* less dangerous, but still. Also watch bearing-type fans. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From LarrySheldon at cox.net Wed Jul 10 04:17:04 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 09 Jul 2013 23:17:04 -0500 Subject: What to expect after a cooling failure In-Reply-To: References: Message-ID: <51DCE040.4070407@cox.net> On 7/9/2013 10:28 PM, Erik Levinson wrote: > As some may know, yesterday 151 Front St suffered a cooling failure > after Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took > much longer and some of our gear shutdown automatically due to > overheating. We shut down remotely many redundant and non-essential > systems in the hotter suite, and transferred remotely some others to > the cooler suite, to ensure that we had a minimum of all core systems > running in the hotter suite. We waited until the temperatures > returned to normal, and brought everything back online. The entire > event lasted from approx 18:45 until 01:15. Apparently ambient > temperature was above 43 degrees Celcius at one point on the cool > side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? No stats, but way back in the day of very large computers (1 each) in very large facilities, it seems like the thing we worried most about at restart was too-rapid cooling and the resulting condensation if the conditions were right. After power-up the next thing was disk crashes that occurred on the way down (this was a long time ago discs and drums are different now). Lastly was overheat failures which were relatively few and always in components with a weakness reputation. -- 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 janets at nairial.net Wed Jul 10 04:18:56 2013 From: janets at nairial.net (Janet Sullivan) Date: Wed, 10 Jul 2013 04:18:56 +0000 Subject: Anyone from frontiernet.net on here? In-Reply-To: References: <8efc4e2baff7443f8dfd052e560f4d98@BY2PR07MB043.namprd07.prod.outlook.com> Message-ID: Thank you, I really appreciate you looking into this. In return, I'll offer up that I'm a senior network engineer at Microsoft - if you ever have issues with AS8075, ping me, and I'll see what I can do. -----Original Message----- From: Jeff Richmond [mailto:jeff.richmond at gmail.com] Sent: Tuesday, July 9, 2013 8:36 PM To: Warren Bailey Cc: Janet Sullivan; nanog at nanog.org Subject: Re: Anyone from frontiernet.net on here? All it looks like I am seeing packet loss there across all of our peering sessions with them, so looks like a problem on their network. I'll ask our NOC to open up a ticket with them though just to see if we can find out what the issue is. Thanks, -Jeff On Jul 9, 2013, at 7:18 PM, Warren Bailey wrote: > There are some decent sized attacks taking place on gear near London, I believe. Could be a result of that? > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Janet Sullivan > Date: 07/09/2013 5:01 PM (GMT-08:00) > To: nanog at nanog.org > Subject: Anyone from frontiernet.net on here? > > > I've been seeing really bad packet loss between PCCW and frontier, and so far haven't been able to make any traction with anyone on either side. I'm betting that the ??? is a peering point either in London or Ashburn. > > uk.bgp4.net (0.0.0.0) Tue Jul 9 20:39:53 2013 > Keys: Help Display mode Restart statistics Order of fields qu > it Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. 212.111.33.230 0.0% 43 1.7 0.7 0.5 1.8 0.3 > 2. 212.111.33.237 0.0% 43 2.3 1.9 1.1 22.7 3.3 > 3. 63.218.13.221 0.0% 43 2.3 15.6 1.1 230.3 45.9 > 4. ??? > 5. 74.40.2.173 23.3% 43 177.9 150.3 147.8 177.9 7.0 > 6. 74.40.2.193 20.9% 43 149.9 149.9 149.1 161.2 2.1 > 7. 74.40.3.241 18.6% 43 149.6 152.4 149.1 193.2 8.8 > 8. 74.40.5.49 28.6% 43 148.1 150.8 147.8 192.1 9.9 > 9. 74.40.5.54 26.2% 43 148.3 150.5 147.9 218.7 12.6 > 10. 74.40.5.46 33.3% 42 149.5 154.0 149.2 212.8 14.0 > 11. 74.40.3.137 16.7% 42 147.4 148.7 146.9 163.0 4.1 > 12. 74.40.1.154 29.3% 42 148.2 153.6 147.7 206.7 14.2 > 13. 50.34.2.162 35.7% 42 150.2 150.4 149.8 156.3 1.2 > 14. 50.46.150.55 26.2% 42 150.7 151.0 150.5 152.0 0.4 > From mysidia at gmail.com Wed Jul 10 05:07:11 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 10 Jul 2013 00:07:11 -0500 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: On 7/9/13, Erik Levinson wrote: > For those who have gone through such events in the past, what can one expect > in terms of long-term impact...should we expect some premature component > failures? Does anyone have any stats to share? Realistically... you had a single short-lived stress event. There are likely to be some number of random component failures in the future. It is unlikely that you will be able to attribute the failures to such a short lived stress event of that magnitude -- there might on average be a small increase over normal failure rates. The bigger concern, may be that /a lot of different components/ could have been subject to the same kind of abuse at the same time: including sets of components that are supposed to be in a redundant pair and not fail simultaneously. I wouldn't necessarily be so concerned about premature failures --- I would be more concerned, that you may have redundant components that were exposed to the same stress event at the same time; now the assumption that their chances of failure are independent may become more questionable --- the chance of a correlated failure in the future might be greatly increased, reducing the level of effective redundancy/risk reduction today. That would apply mainly to mechanical devices such as HDDs. > Thanks -- -JH From contact at nullivex.com Wed Jul 10 05:30:25 2013 From: contact at nullivex.com (Bryan Tong) Date: Tue, 9 Jul 2013 23:30:25 -0600 Subject: What to expect after a cooling failure In-Reply-To: References: <1373426894.69598008@apps.rackspace.com> Message-ID: Honestly, I think your hardware will be fine just like everyone else said keep an eye on your hard drives they are by far the most sensitive. Anything not mechanical if it didnt melt you're good. One data center we had equipment in was 153F for about a week and all we saw were drive failures and they were still fairly sparse. 1 out of 10 I would say. Thanks On Tue, Jul 9, 2013 at 11:07 PM, Jimmy Hess wrote: > On 7/9/13, Erik Levinson wrote: > > For those who have gone through such events in the past, what can one > expect > > in terms of long-term impact...should we expect some premature component > > failures? Does anyone have any stats to share? > > Realistically... you had a single short-lived stress event. There > are likely to be some number of random component failures in the > future. It is unlikely that you will be able to attribute the > failures to such a short lived stress event of that magnitude -- > there might on average be a small increase over normal failure rates. > > The bigger concern, may be that /a lot of different components/ > could have been subject to the same kind of abuse at the same time: > including sets of components that are supposed to be in a redundant > pair and not fail simultaneously. > > I wouldn't necessarily be so concerned about premature failures --- > I would be more concerned, that you may have redundant components > that were exposed to the same stress event at the same time; now > the assumption that their chances of failure are independent may > become more questionable --- the chance of a correlated failure in > the future might be greatly increased, reducing the level of > effective redundancy/risk reduction today. > > That would apply mainly to mechanical devices such as HDDs. > > > > Thanks > -- > -JH > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From khuon at NEEBU.Net Wed Jul 10 05:36:41 2013 From: khuon at NEEBU.Net (Jake Khuon) Date: Tue, 09 Jul 2013 22:36:41 -0700 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: <51DCF2E9.3010308@NEEBU.Net> On 09/07/13 20:28, Erik Levinson wrote: > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? While others have already talked about what to look out for in terms of systems and drives, I haven't seen anyone mention things like your UPS batteries. Were they also heat-soaked? At one place I worked at, we lost a whole bank of batteries in the UPS room when it overheated. I think that was somewhere around a $95,000 replacement and required rush-delivery of a lot of SLAs from all over the place. From swmike at swm.pp.se Wed Jul 10 05:47:20 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jul 2013 07:47:20 +0200 (CEST) Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: On Tue, 9 Jul 2013, Erik Levinson wrote: > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? I have experience with a different kind of event that might be of interest to a wider audience. When the fire suppression system went off in a site, we had a lot of instant harddrive failures. I don't have any numbers, but let's say 5-10% of all hdd:s in the room died more or less instantly. Supposedly this was because of the air pressure shock when the inert fire suppression gas was released and the vents weren't big enough to release the overpressurised air outside. I did some research and there are forum posts etc about these kinds of events happening in other places. So, takeaway from this was RAID is an uptime tool, not a substitute for backups, and also, get a qualified ventilation/fire supression systems engineer to inspect your sites from this aspect. -- Mikael Abrahamsson email: swmike at swm.pp.se From tritran at cox.net Wed Jul 10 05:56:07 2013 From: tritran at cox.net (Tri Tran) Date: Wed, 10 Jul 2013 05:56:07 +0000 Subject: What to expect after a cooling failure In-Reply-To: References: <1373426894.69598008@apps.rackspace.com> Message-ID: <810063175-1373435768-cardhu_decombobulator_blackberry.rim.net-1486247678-@b25.c19.bise6.blackberry> I have seen DDR2 RAM give random errors from inadequate cooling. The cabinets were stacked to the max with severs but the doors were not meshed. DDR2 run fairly hot, especially when all the banks are filled. Tri Tran -----Original Message----- From: Jay Ashworth Date: Wed, 10 Jul 2013 00:04:23 To: NANOG Subject: Re: What to expect after a cooling failure ----- Original Message ----- > From: "Erik Levinson" > For those who have gone through such events in the past, what can one > expect in terms of long-term impact...should we expect some premature > component failures? Does anyone have any stats to share? If the HDDs were spinning while above rated maximum ambient intake temp, *especially* if they're not *right out front in the intake path* (is anything not built that way anymore? Yeah; the back side of 45-drive Supermicro racks, among other things), you should probably plan on doing a preemptive replacement cycle, or at the very least, pay *very* close attention to smartctld, and have a good stock of pre-trayed replacements. Remember that you may fall in the RAID Hole if you wait for failures, and hence lose data which isn't backed up anyway -- if more drives in a raid group fail *during rebuilds*, you're essentially screwed. If your raid groups were properly dispersed across drive build dates, then this will probably be *slightly* less dangerous, but still. Also watch bearing-type fans. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bygg at cafax.se Wed Jul 10 08:09:38 2013 From: bygg at cafax.se (Johnny Eriksson) Date: Wed, 10 Jul 2013 8:09:38 WET DST Subject: What to expect after a cooling failure In-Reply-To: Your message of Tue, 09 Jul 2013 22:36:41 -0700 Message-ID: Jake Khuon wrote: > While others have already talked about what to look out for in terms of > systems and drives, I haven't seen anyone mention things like your UPS > batteries. Were they also heat-soaked? At one place I worked at, we > lost a whole bank of batteries in the UPS room when it overheated. I > think that was somewhere around a $95,000 replacement and required > rush-delivery of a lot of SLAs from all over the place. That is one reason to have the UPS and the batteries in separate rooms. --Johnny From cite+nanog at incertum.net Wed Jul 10 06:46:51 2013 From: cite+nanog at incertum.net (Stefan =?utf-8?Q?F=C3=B6rster?=) Date: Wed, 10 Jul 2013 08:46:51 +0200 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: <20130710064650.GA10139@mail.incertum.net> * Erik Levinson : [cooling failure] > For those who have gone through such events in the past, what can > one expect in terms of long-term impact...should we expect some > premature component failures? Does anyone have any stats to share? We had a similar event (temperatures were a bit higher at 49?C, duration was a bit shorter, 10am to 3pm) this January. In the two days after the event, two of our HP servers had drives that went from "OK" to "Predictive Failure", which is the SmartArray controller's way of telling about high error rates. Two weeks after, we had a single DIMM with an uncorrectable ECC error, causing a server reboot. Three weeks after, a single PSU failed. In our opinion, the disk problems were caused by the cooling failure, while the ECC error and the faulted PSU were probably not related. I believe that your hardware will be fine, but it probably wouldn't be a bad idea to check if you have current maintenance contracts/warranty for your servers, or any other way of obtaining replacement drives in a reasonably short time. Cheers Stefan From george.herbert at gmail.com Wed Jul 10 09:07:29 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 10 Jul 2013 02:07:29 -0700 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: Numbers from memory and filed off a bit for anonymity, but.... A site I was consulting with had statistically large numbers of x86 servers (say, 3000), SPARC enterprise gear (100), NetApp units (60) and NetApp drives (5000+) go through a roughly 42C excursion. It was much hotter at ceiling level but fortunately high (20 foot) ceilings. Within about 1C of the (wet pipes) sprinkler system head fuse temp... (shudder) Both NetApp and X86 server PSUs had significantly increased failure rates for the next year. Say in rough numbers 10% failed in the year. About 2% were instant fails. Hard drives had a significantly higher fail rate for the next year, also in the 10% range. No change in rate of motherboard or CPU or RAM failures was noted that I recall. George William Herbert Sent from my iPhone On Jul 9, 2013, at 8:28 PM, "Erik Levinson" wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > > From lorell at hathcock.org Wed Jul 10 12:25:16 2013 From: lorell at hathcock.org (Lorell Hathcock) Date: Wed, 10 Jul 2013 07:25:16 -0500 Subject: What to expect after a cooling failure In-Reply-To: References: <1373426894.69598008@apps.rackspace.com> Message-ID: <02fc01ce7d68$89012ef0$9b038cd0$@hathcock.org> Ugly. If the batteries that were in the facility's power distribution system were affected by the heat, then their life is likely significantly shortened. This is in terms of their capacity to supply power in the event of an outage and a shortened shelf life. Lorell On Jul 9, 2013, at 8:28 PM, "Erik Levinson" wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > > From dtaylor at vocalabs.com Wed Jul 10 14:12:55 2013 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Wed, 10 Jul 2013 09:12:55 -0500 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: <51DD6BE7.7050602@vocalabs.com> Another failure I've seen connected to overheating events is AC power supply failures. On 07/09/2013 10:28 PM, Erik Levinson wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > > From blair.trosper at gmail.com Wed Jul 10 14:28:05 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 10 Jul 2013 09:28:05 -0500 Subject: google troubles? Message-ID: Seeing lots of reports of people unable to get to many Google services. Seems to be affecting Comcast users disproportionately. It's fine for me, but a lot of my staff are basically out of luck...but according to the Google Apps Status page, everything is fine. It's anecdotal, but it would seem like there's an issue based on these reports. Oh, and this: http://www.cnn.com/2013/07/10/tech/web/google-down/index.html Anyone know what's up? Fiber cut? DC outages? -- blair From tony at swalter.com Wed Jul 10 14:39:10 2013 From: tony at swalter.com (Tony Patti) Date: Wed, 10 Jul 2013 10:39:10 -0400 Subject: What to expect after a cooling failure In-Reply-To: <1373426894.69598008@apps.rackspace.com> References: <1373426894.69598008@apps.rackspace.com> Message-ID: <030201ce7d7b$3d77bdb0$b8673910$@swalter.com> This has been a very interesting thread. Google pointed me to this Dell document which specs some of their servers having an expanded operating temperature range *** based on the amount of time spent at the elevated temperature, as a percentage of annual operating hours. *** ftp://ftp.dell.com/Manuals/all-products/esuprt_ser_stor_net/esuprt_poweredge/poweredge-r710_User%27s%20Guide4_en-us.pdf I mention that because the "1% of annual operating hours" at 45 C would be two degrees higher than the 43 C stated as reached in the original email. It would seem that Dell recognizes that there might be situations, such as this, where the "continuous operation" range (35 C) is briefly exceeded. Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Erik Levinson [mailto:erik.levinson at uberflip.com] Sent: Tuesday, July 09, 2013 11:28 PM To: NANOG mailing list Subject: What to expect after a cooling failure As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? Thanks -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From ben.brown at sunlessinc.com Wed Jul 10 14:42:21 2013 From: ben.brown at sunlessinc.com (BEN BROWN) Date: Wed, 10 Jul 2013 14:42:21 +0000 Subject: google troubles? In-Reply-To: References: Message-ID: I did have connectivity issues for mobile devices this AM between 8:00am-10:00am EST. I am in NE Ohio. Seems to be resolved now. -----Original Message----- From: Blair Trosper [mailto:blair.trosper at gmail.com] Sent: Wednesday, July 10, 2013 10:28 AM To: nanog at nanog.org Subject: google troubles? Seeing lots of reports of people unable to get to many Google services. Seems to be affecting Comcast users disproportionately. It's fine for me, but a lot of my staff are basically out of luck...but according to the Google Apps Status page, everything is fine. It's anecdotal, but it would seem like there's an issue based on these reports. Oh, and this: http://www.cnn.com/2013/07/10/tech/web/google-down/index.html Anyone know what's up? Fiber cut? DC outages? -- blair From johny at griffintechnology.com Wed Jul 10 14:45:46 2013 From: johny at griffintechnology.com (John York) Date: Wed, 10 Jul 2013 09:45:46 -0500 Subject: google troubles? In-Reply-To: References: Message-ID: We saw the same thing, but seems to be cleared up now. All our providers that routed to Google addresses in ATL had the issue. We have one provider that lands on Google addresses in DFW, and it was working. ...And now I see that it isn't completely resolved. Some Google apps are still inaccessible via the Atlanta routes. On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper wrote: > Seeing lots of reports of people unable to get to many Google services. > Seems to be affecting Comcast users disproportionately. It's fine for me, > but a lot of my staff are basically out of luck...but according to the > Google Apps Status page, everything is fine. > > It's anecdotal, but it would seem like there's an issue based on these > reports. > > Oh, and this: > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > Anyone know what's up? Fiber cut? DC outages? > > -- blair > -- John York Information Technology | Network Administrator Phone: 615-399-7000 x:333 Griffin Technology 2030 Lindell Avenue Nashville, TN 37203 USA This message and any attachments should be treated as confidential information of Griffin Technology, Inc. From shortdudey123 at gmail.com Wed Jul 10 14:56:43 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 10 Jul 2013 07:56:43 -0700 Subject: google troubles? In-Reply-To: References: Message-ID: Does anyone have traceroutes showing where the issues are? -Grant On Wed, Jul 10, 2013 at 7:45 AM, John York wrote: > We saw the same thing, but seems to be cleared up now. All our providers > that routed to Google addresses in ATL had the issue. We have one provider > that lands on Google addresses in DFW, and it was working. > > ...And now I see that it isn't completely resolved. Some Google apps are > still inaccessible via the Atlanta routes. > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >wrote: > > > Seeing lots of reports of people unable to get to many Google services. > > Seems to be affecting Comcast users disproportionately. It's fine for > me, > > but a lot of my staff are basically out of luck...but according to the > > Google Apps Status page, everything is fine. > > > > It's anecdotal, but it would seem like there's an issue based on these > > reports. > > > > Oh, and this: > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > Anyone know what's up? Fiber cut? DC outages? > > > > -- blair > > > > > > -- > > John York > > Information Technology | Network Administrator > > Phone: 615-399-7000 x:333 > > Griffin Technology > 2030 Lindell Avenue Nashville, TN 37203 USA > > This message and any attachments should be treated as confidential > information of Griffin Technology, Inc. > From nmaxpierson at gmail.com Wed Jul 10 14:59:47 2013 From: nmaxpierson at gmail.com (N. Max Pierson) Date: Wed, 10 Jul 2013 09:59:47 -0500 Subject: google troubles? In-Reply-To: References: Message-ID: Traceroutes worked fine for me during the outage. Seems to have been something at L4-L7. -- max On Wed, Jul 10, 2013 at 9:56 AM, Grant Ridder wrote: > Does anyone have traceroutes showing where the issues are? > > -Grant > > On Wed, Jul 10, 2013 at 7:45 AM, John York >wrote: > > > We saw the same thing, but seems to be cleared up now. All our providers > > that routed to Google addresses in ATL had the issue. We have one > provider > > that lands on Google addresses in DFW, and it was working. > > > > ...And now I see that it isn't completely resolved. Some Google apps are > > still inaccessible via the Atlanta routes. > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > >wrote: > > > > > Seeing lots of reports of people unable to get to many Google services. > > > Seems to be affecting Comcast users disproportionately. It's fine for > > me, > > > but a lot of my staff are basically out of luck...but according to the > > > Google Apps Status page, everything is fine. > > > > > > It's anecdotal, but it would seem like there's an issue based on these > > > reports. > > > > > > Oh, and this: > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > -- blair > > > > > > > > > > > -- > > > > John York > > > > Information Technology | Network Administrator > > > > Phone: 615-399-7000 x:333 > > > > Griffin Technology > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > This message and any attachments should be treated as confidential > > information of Griffin Technology, Inc. > > > From dhill at mindcry.org Wed Jul 10 15:02:04 2013 From: dhill at mindcry.org (David Hill) Date: Wed, 10 Jul 2013 11:02:04 -0400 Subject: www.att.net ipv6 traceroute In-Reply-To: <20945.58411.851583.636356@oz.mt.att.com> References: <20130701143421.GB14901@d4f4ef01f7f3a8c3526c7461b9d857e63ca45e1f3a91c2cc> <20945.58411.851583.636356@oz.mt.att.com> Message-ID: <20130710150204.GA26667@dd9aff0454f18aef7cd8c4f7ff5be3cf3637e7de3e218fa0> On Mon, Jul 01, 2013 at 04:18:51PM -0400, Jay Borkenhagen wrote: > David Hill writes: > > Anyone else noticing odd ipv6 traceroutes to www.att.net > > (2001:1890:1c01:2::40)? > > > > David, > > We see what's going on. It currently affects only a portion of the v6 > Internet. Working on a fix... > > Jay B. > > Jay - Any update? David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From milt at net2atlanta.com Wed Jul 10 15:16:19 2013 From: milt at net2atlanta.com (Milt Aitken) Date: Wed, 10 Jul 2013 11:16:19 -0400 Subject: google troubles? References: Message-ID: We (were) peered with Google in Atlanta. We were unable to bring up web pages for google.com or gmail.com. Traceroute worked, though. I shut off the peering & my outbound route switched to Cogent, which works now. I'll try peering again tonight. Maybe they'll have fixed it by then. -----Original Message----- From: N. Max Pierson [mailto:nmaxpierson at gmail.com] Sent: Wednesday, July 10, 2013 11:00 AM To: Grant Ridder Cc: nanog at nanog.org Subject: Re: google troubles? Traceroutes worked fine for me during the outage. Seems to have been something at L4-L7. -- max On Wed, Jul 10, 2013 at 9:56 AM, Grant Ridder wrote: > Does anyone have traceroutes showing where the issues are? > > -Grant > > On Wed, Jul 10, 2013 at 7:45 AM, John York >wrote: > > > We saw the same thing, but seems to be cleared up now. All our providers > > that routed to Google addresses in ATL had the issue. We have one > provider > > that lands on Google addresses in DFW, and it was working. > > > > ...And now I see that it isn't completely resolved. Some Google apps are > > still inaccessible via the Atlanta routes. > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > >wrote: > > > > > Seeing lots of reports of people unable to get to many Google services. > > > Seems to be affecting Comcast users disproportionately. It's fine for > > me, > > > but a lot of my staff are basically out of luck...but according to the > > > Google Apps Status page, everything is fine. > > > > > > It's anecdotal, but it would seem like there's an issue based on these > > > reports. > > > > > > Oh, and this: > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > -- blair > > > > > > > > > > > -- > > > > John York > > > > Information Technology | Network Administrator > > > > Phone: 615-399-7000 x:333 > > > > Griffin Technology > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > This message and any attachments should be treated as confidential > > information of Griffin Technology, Inc. > > > From shortdudey123 at gmail.com Wed Jul 10 16:27:07 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 10 Jul 2013 09:27:07 -0700 Subject: google troubles? In-Reply-To: References: Message-ID: tcptraceroutes working fine too? On Wed, Jul 10, 2013 at 8:16 AM, Milt Aitken wrote: > We (were) peered with Google in Atlanta. > We were unable to bring up web pages for google.com or gmail.com. > Traceroute worked, though. > I shut off the peering & my outbound route switched to Cogent, which > works now. > > I'll try peering again tonight. Maybe they'll have fixed it by then. > > -----Original Message----- > From: N. Max Pierson [mailto:nmaxpierson at gmail.com] > Sent: Wednesday, July 10, 2013 11:00 AM > To: Grant Ridder > Cc: nanog at nanog.org > Subject: Re: google troubles? > > Traceroutes worked fine for me during the outage. Seems to have been > something at L4-L7. > > -- > max > > On Wed, Jul 10, 2013 at 9:56 AM, Grant Ridder > wrote: > > > Does anyone have traceroutes showing where the issues are? > > > > -Grant > > > > On Wed, Jul 10, 2013 at 7:45 AM, John York > > >wrote: > > > > > We saw the same thing, but seems to be cleared up now. All our > providers > > > that routed to Google addresses in ATL had the issue. We have one > > provider > > > that lands on Google addresses in DFW, and it was working. > > > > > > ...And now I see that it isn't completely resolved. Some Google apps > are > > > still inaccessible via the Atlanta routes. > > > > > > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > > > >wrote: > > > > > > > Seeing lots of reports of people unable to get to many Google > services. > > > > Seems to be affecting Comcast users disproportionately. It's > fine for > > > me, > > > > but a lot of my staff are basically out of luck...but according to > the > > > > Google Apps Status page, everything is fine. > > > > > > > > It's anecdotal, but it would seem like there's an issue based on > these > > > > reports. > > > > > > > > Oh, and this: > > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > > > -- blair > > > > > > > > > > > > > > > > -- > > > > > > John York > > > > > > Information Technology | Network Administrator > > > > > > Phone: 615-399-7000 x:333 > > > > > > Griffin Technology > > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > > > This message and any attachments should be treated as confidential > > > information of Griffin Technology, Inc. > > > > > > From mike at routed.ca Wed Jul 10 15:28:40 2013 From: mike at routed.ca (Mike Jackson) Date: Wed, 10 Jul 2013 11:28:40 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but not from Rogers/AS812 in Toronto. I've done a few other test traceroutes through Rogers to verify that they didn't filter UDP/ICMP. At this point nothing would surprise me from Rogers. AS701 ===== TOR2-CORE-R1#traceroute www.google.com Translating "www.google.com"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Tracing the route to www.google.com (74.125.26.99) VRF info: (vrf in name/id, vrf out name/id) 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec 4 msec 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec 16 msec 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec 9 216.239.48.159 [AS 15169] 36 msec 32 msec 216.239.48.59 [AS 15169] 32 msec 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) =================================================== *Query:* *tr 64.71.249.45* Type escape sequence to abort. Tracing the route to 64.71.249.45 1 64.71.255.62 0 msec 0 msec 0 msec 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec 4 msec 3 69.63.250.189 4 msec 4 msec 4 msec 4 69.63.250.174 4 msec 4 msec 4 msec 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Cheers, - MJ -----Original Message----- > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > Sent: July-10-13 10:57 AM > To: John York > Cc: nanog at nanog.org > Subject: Re: google troubles? > > Does anyone have traceroutes showing where the issues are? > > -Grant > > On Wed, Jul 10, 2013 at 7:45 AM, John York > wrote: > > > We saw the same thing, but seems to be cleared up now. All our > > providers that routed to Google addresses in ATL had the issue. We > > have one provider that lands on Google addresses in DFW, and it was > working. > > > > ...And now I see that it isn't completely resolved. Some Google apps > > are still inaccessible via the Atlanta routes. > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > > > >wrote: > > > > > Seeing lots of reports of people unable to get to many Google > services. > > > Seems to be affecting Comcast users disproportionately. It's fine > > > for > > me, > > > but a lot of my staff are basically out of luck...but according to > > > the Google Apps Status page, everything is fine. > > > > > > It's anecdotal, but it would seem like there's an issue based on > > > these reports. > > > > > > Oh, and this: > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > -- blair > > > > > > > > > > > -- > > > > John York > > > > Information Technology | Network Administrator > > > > Phone: 615-399-7000 x:333 > > > > Griffin Technology > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > This message and any attachments should be treated as confidential > > information of Griffin Technology, Inc. > > > > > > From mike at routed.ca Wed Jul 10 16:20:34 2013 From: mike at routed.ca (Mike Jackson) Date: Wed, 10 Jul 2013 12:20:34 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: I just realized that it's not Google IP space (74.125.0.0/16), Rogers is hijacking the DNS and resolving www.google.com to space within 64.71.240.0/20 which is Rogers IP space! (note the name server set as 8.8.8.8) davinci#traceroute www.google.com Translating "www.google.com"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Tracing the route to www.google.com (66.185.85.29) 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] 8 msec 8 msec 4 msec 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * TOR2-CORE-R1#show ip bgp 66.185.85.29 BGP routing table entry for 66.185.80.0/20, version 13095115 Paths: (1 available, best #1, table default) Advertised to update-groups: 14 701 6461 812 205.205.23.121 from 205.205.23.121 (137.39.8.42) Origin IGP, localpref 100, valid, external, best TOR2-CORE-R1# Thanks, - Mike On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but > not from Rogers/AS812 in Toronto. I've done a few other test traceroutes > through Rogers to verify that they didn't filter UDP/ICMP. At this point > nothing would surprise me from Rogers. > > AS701 > ===== > > TOR2-CORE-R1#traceroute www.google.com > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > Type escape sequence to abort. > Tracing the route to www.google.com (74.125.26.99) > VRF info: (vrf in name/id, vrf out name/id) > 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec > 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec > 4 msec > 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec > 16 msec > 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec > TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec > TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec > 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec > 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec > 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec > 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec > 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec > 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec > 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec > 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec > 9 216.239.48.159 [AS 15169] 36 msec 32 msec > 216.239.48.59 [AS 15169] 32 msec > 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec > > > > AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) > =================================================== > > *Query:* *tr 64.71.249.45* > > Type escape sequence to abort. > Tracing the route to 64.71.249.45 > > 1 64.71.255.62 0 msec 0 msec 0 msec > 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec 4 msec > 3 69.63.250.189 4 msec 4 msec 4 msec > 4 69.63.250.174 4 msec 4 msec 4 msec > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Cheers, > > - MJ > > > -----Original Message----- >> From: Grant Ridder [mailto:shortdudey123 at gmail.com] >> Sent: July-10-13 10:57 AM >> To: John York >> Cc: nanog at nanog.org >> Subject: Re: google troubles? >> >> Does anyone have traceroutes showing where the issues are? >> >> -Grant >> >> On Wed, Jul 10, 2013 at 7:45 AM, John York >> wrote: >> >> > We saw the same thing, but seems to be cleared up now. All our >> > providers that routed to Google addresses in ATL had the issue. We >> > have one provider that lands on Google addresses in DFW, and it was >> working. >> > >> > ...And now I see that it isn't completely resolved. Some Google apps >> > are still inaccessible via the Atlanta routes. >> > >> > >> > >> > >> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >> > > > >wrote: >> > >> > > Seeing lots of reports of people unable to get to many Google >> services. >> > > Seems to be affecting Comcast users disproportionately. It's fine >> > > for >> > me, >> > > but a lot of my staff are basically out of luck...but according to >> > > the Google Apps Status page, everything is fine. >> > > >> > > It's anecdotal, but it would seem like there's an issue based on >> > > these reports. >> > > >> > > Oh, and this: >> > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html >> > > >> > > Anyone know what's up? Fiber cut? DC outages? >> > > >> > > -- blair >> > > >> > >> > >> > >> > -- >> > >> > John York >> > >> > Information Technology | Network Administrator >> > >> > Phone: 615-399-7000 x:333 >> > >> > Griffin Technology >> > 2030 Lindell Avenue Nashville, TN 37203 USA >> > >> > This message and any attachments should be treated as confidential >> > information of Griffin Technology, Inc. >> > >> >> >> >> > > From morrowc.lists at gmail.com Wed Jul 10 18:18:12 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Jul 2013 14:18:12 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: > I just realized that it's not Google IP space (74.125.0.0/16), Rogers is > hijacking the DNS and resolving www.google.com to space within > 64.71.240.0/20 which is Rogers IP space! (note the name server set as > 8.8.8.8) > so: 1) rogers is hijacking traffic to 8.8.8.8 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect information for google properties (at least). err... any idea if it's lying about other things too? :) > davinci#traceroute www.google.com > > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > Type escape sequence to abort. > Tracing the route to www.google.com (66.185.85.29) > > 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec > 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] 8 > msec 8 msec 4 msec > 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec > 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > > TOR2-CORE-R1#show ip bgp 66.185.85.29 > BGP routing table entry for 66.185.80.0/20, version 13095115 > Paths: (1 available, best #1, table default) > Advertised to update-groups: > 14 > 701 6461 812 > 205.205.23.121 from 205.205.23.121 (137.39.8.42) > Origin IGP, localpref 100, valid, external, best > TOR2-CORE-R1# > > > Thanks, > > - Mike > > > On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > >> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but >> not from Rogers/AS812 in Toronto. I've done a few other test traceroutes >> through Rogers to verify that they didn't filter UDP/ICMP. At this point >> nothing would surprise me from Rogers. >> >> AS701 >> ===== >> >> TOR2-CORE-R1#traceroute www.google.com >> Translating "www.google.com"...domain server (8.8.8.8) [OK] >> >> Type escape sequence to abort. >> Tracing the route to www.google.com (74.125.26.99) >> VRF info: (vrf in name/id, vrf out name/id) >> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec >> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec >> 4 msec >> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec >> 16 msec >> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec >> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec >> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec >> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec >> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec >> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec >> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec >> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec >> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec >> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec >> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec >> 9 216.239.48.159 [AS 15169] 36 msec 32 msec >> 216.239.48.59 [AS 15169] 32 msec >> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec >> >> >> >> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) >> =================================================== >> >> *Query:* *tr 64.71.249.45* >> >> Type escape sequence to abort. >> Tracing the route to 64.71.249.45 >> >> 1 64.71.255.62 0 msec 0 msec 0 msec >> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec 4 msec >> 3 69.63.250.189 4 msec 4 msec 4 msec >> 4 69.63.250.174 4 msec 4 msec 4 msec >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> 11 * * * >> 12 * * * >> 13 * * * >> 14 * * * >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * * * >> 28 * * * >> 29 * * * >> 30 * * * >> >> >> Cheers, >> >> - MJ >> >> >> -----Original Message----- >>> From: Grant Ridder [mailto:shortdudey123 at gmail.com] >>> Sent: July-10-13 10:57 AM >>> To: John York >>> Cc: nanog at nanog.org >>> Subject: Re: google troubles? >>> >>> Does anyone have traceroutes showing where the issues are? >>> >>> -Grant >>> >>> On Wed, Jul 10, 2013 at 7:45 AM, John York >>> wrote: >>> >>> > We saw the same thing, but seems to be cleared up now. All our >>> > providers that routed to Google addresses in ATL had the issue. We >>> > have one provider that lands on Google addresses in DFW, and it was >>> working. >>> > >>> > ...And now I see that it isn't completely resolved. Some Google apps >>> > are still inaccessible via the Atlanta routes. >>> > >>> > >>> > >>> > >>> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >>> > >> > >wrote: >>> > >>> > > Seeing lots of reports of people unable to get to many Google >>> services. >>> > > Seems to be affecting Comcast users disproportionately. It's fine >>> > > for >>> > me, >>> > > but a lot of my staff are basically out of luck...but according to >>> > > the Google Apps Status page, everything is fine. >>> > > >>> > > It's anecdotal, but it would seem like there's an issue based on >>> > > these reports. >>> > > >>> > > Oh, and this: >>> > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html >>> > > >>> > > Anyone know what's up? Fiber cut? DC outages? >>> > > >>> > > -- blair >>> > > >>> > >>> > >>> > >>> > -- >>> > >>> > John York >>> > >>> > Information Technology | Network Administrator >>> > >>> > Phone: 615-399-7000 x:333 >>> > >>> > Griffin Technology >>> > 2030 Lindell Avenue Nashville, TN 37203 USA >>> > >>> > This message and any attachments should be treated as confidential >>> > information of Griffin Technology, Inc. >>> > >>> >>> >>> >>> >> >> From rodrick.brown at gmail.com Wed Jul 10 18:20:34 2013 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Wed, 10 Jul 2013 14:20:34 -0400 Subject: Diverse sub-sea carrier links London / Tokyo Message-ID: I'm looking for a diverse carrier circuits to/from the following POP's over different sub-sea links. I'm not too comfortable getting diverse path(s) from the same carrier (Hibernia) so I'm interested in getting input from others who have dealt with other carriers in these locations who can offer connectivity over different sub-sea links than my current provider. 755 Secaucus-350 Cermak-Seattle-*PC1 Cable*-Ajigaura-TY3 (Equinix) 755 Secaucus-300 Blvd-111 8th-*AC1 Standard*-Slough-Telehouse North-London Hosting Center (Savvis) Sorry if this is off-list. --RB From morrowc.lists at gmail.com Wed Jul 10 18:39:24 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Jul 2013 14:39:24 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 2:18 PM, Christopher Morrow wrote: > On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: >> I just realized that it's not Google IP space (74.125.0.0/16), Rogers is >> hijacking the DNS and resolving www.google.com to space within >> 64.71.240.0/20 which is Rogers IP space! (note the name server set as >> 8.8.8.8) >> > > so: > 1) rogers is hijacking traffic to 8.8.8.8 > 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect > information for google properties (at least). > > err... any idea if it's lying about other things too? :) > oops, so a polite caller noted that google often ships people at a local 'google global cache' node if they have one... it seems like that might be what's going on here with 8.8.8.8 sending you to 64.71 and/or 66.185 addresses. so maybe rogers isn't doing something untoward after all! -chris (thanks for the headslap polite caller) >> davinci#traceroute www.google.com >> >> Translating "www.google.com"...domain server (8.8.8.8) [OK] >> >> Type escape sequence to abort. >> Tracing the route to www.google.com (66.185.85.29) >> >> 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec >> 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] 8 >> msec 8 msec 4 msec >> 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec >> 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> >> TOR2-CORE-R1#show ip bgp 66.185.85.29 >> BGP routing table entry for 66.185.80.0/20, version 13095115 >> Paths: (1 available, best #1, table default) >> Advertised to update-groups: >> 14 >> 701 6461 812 >> 205.205.23.121 from 205.205.23.121 (137.39.8.42) >> Origin IGP, localpref 100, valid, external, best >> TOR2-CORE-R1# >> >> >> Thanks, >> >> - Mike >> >> >> On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: >> >>> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but >>> not from Rogers/AS812 in Toronto. I've done a few other test traceroutes >>> through Rogers to verify that they didn't filter UDP/ICMP. At this point >>> nothing would surprise me from Rogers. >>> >>> AS701 >>> ===== >>> >>> TOR2-CORE-R1#traceroute www.google.com >>> Translating "www.google.com"...domain server (8.8.8.8) [OK] >>> >>> Type escape sequence to abort. >>> Tracing the route to www.google.com (74.125.26.99) >>> VRF info: (vrf in name/id, vrf out name/id) >>> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec >>> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec >>> 4 msec >>> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec >>> 16 msec >>> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec >>> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec >>> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec >>> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec >>> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec >>> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec >>> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec >>> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec >>> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec >>> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec >>> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec >>> 9 216.239.48.159 [AS 15169] 36 msec 32 msec >>> 216.239.48.59 [AS 15169] 32 msec >>> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec >>> >>> >>> >>> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) >>> =================================================== >>> >>> *Query:* *tr 64.71.249.45* >>> >>> Type escape sequence to abort. >>> Tracing the route to 64.71.249.45 >>> >>> 1 64.71.255.62 0 msec 0 msec 0 msec >>> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec 4 msec >>> 3 69.63.250.189 4 msec 4 msec 4 msec >>> 4 69.63.250.174 4 msec 4 msec 4 msec >>> 5 * * * >>> 6 * * * >>> 7 * * * >>> 8 * * * >>> 9 * * * >>> 10 * * * >>> 11 * * * >>> 12 * * * >>> 13 * * * >>> 14 * * * >>> 15 * * * >>> 16 * * * >>> 17 * * * >>> 18 * * * >>> 19 * * * >>> 20 * * * >>> 21 * * * >>> 22 * * * >>> 23 * * * >>> 24 * * * >>> 25 * * * >>> 26 * * * >>> 27 * * * >>> 28 * * * >>> 29 * * * >>> 30 * * * >>> >>> >>> Cheers, >>> >>> - MJ >>> >>> >>> -----Original Message----- >>>> From: Grant Ridder [mailto:shortdudey123 at gmail.com] >>>> Sent: July-10-13 10:57 AM >>>> To: John York >>>> Cc: nanog at nanog.org >>>> Subject: Re: google troubles? >>>> >>>> Does anyone have traceroutes showing where the issues are? >>>> >>>> -Grant >>>> >>>> On Wed, Jul 10, 2013 at 7:45 AM, John York >>>> wrote: >>>> >>>> > We saw the same thing, but seems to be cleared up now. All our >>>> > providers that routed to Google addresses in ATL had the issue. We >>>> > have one provider that lands on Google addresses in DFW, and it was >>>> working. >>>> > >>>> > ...And now I see that it isn't completely resolved. Some Google apps >>>> > are still inaccessible via the Atlanta routes. >>>> > >>>> > >>>> > >>>> > >>>> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >>>> > >>> > >wrote: >>>> > >>>> > > Seeing lots of reports of people unable to get to many Google >>>> services. >>>> > > Seems to be affecting Comcast users disproportionately. It's fine >>>> > > for >>>> > me, >>>> > > but a lot of my staff are basically out of luck...but according to >>>> > > the Google Apps Status page, everything is fine. >>>> > > >>>> > > It's anecdotal, but it would seem like there's an issue based on >>>> > > these reports. >>>> > > >>>> > > Oh, and this: >>>> > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html >>>> > > >>>> > > Anyone know what's up? Fiber cut? DC outages? >>>> > > >>>> > > -- blair >>>> > > >>>> > >>>> > >>>> > >>>> > -- >>>> > >>>> > John York >>>> > >>>> > Information Technology | Network Administrator >>>> > >>>> > Phone: 615-399-7000 x:333 >>>> > >>>> > Griffin Technology >>>> > 2030 Lindell Avenue Nashville, TN 37203 USA >>>> > >>>> > This message and any attachments should be treated as confidential >>>> > information of Griffin Technology, Inc. >>>> > >>>> >>>> >>>> >>>> >>> >>> From sfrost at snowman.net Wed Jul 10 18:45:46 2013 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 10 Jul 2013 14:45:46 -0400 Subject: whois.internic.net / whois.crsnic.net IPv6 timeouts Message-ID: <20130710184546.GV3286@tamriel.snowman.net> All, Don't know if it'll help or if this is simply old news to most, but the whois systems (whois.internic.net/whois.crsnic.net) have AAAA records and happily answer TCP/43 requests w/ the usual blurb, but all the servers I've hit then fail to actually provide data and instead the whois client (Ubuntu 13.04) simply time-outs. sfrost at tamriel:/home/sfrost> whois -h 2001:503:5ae2:1060::74 networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Timeout. Servers that I've tried so far (all IPv6 addresses I got through running 'host whois.crsnic.net'): 2001:503:5419:1060::74 2001:503:3227:1060::74 2001:503:6810:1060::74 2001:503:bfb0:1060::74 2001:500:30ff:1060::74 2001:503:7bbf:1060::74 2001:502:be98:1060::74 2001:502:8c25:1060::74 Anyone from NetSol care? It's not the end of the world, but it certainly is quite annoying.. Judging by some complaints on the 'net, looks to be a rather long-standing issue too (there's a Debian bug #683187 which mentions similar issues from nearly a year ago..). Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From lists at tigertech.com Wed Jul 10 19:41:11 2013 From: lists at tigertech.com (Robert L Mathews) Date: Wed, 10 Jul 2013 12:41:11 -0700 Subject: whois.internic.net / whois.crsnic.net IPv6 timeouts In-Reply-To: <20130710184546.GV3286@tamriel.snowman.net> References: <20130710184546.GV3286@tamriel.snowman.net> Message-ID: <51DDB8D7.9060404@tigertech.com> On 7/10/13 11:45 AM, Stephen Frost wrote: > Don't know if it'll help or if this is simply old news to most, but > the whois systems (whois.internic.net/whois.crsnic.net) have AAAA > records and happily answer TCP/43 requests w/ the usual blurb, but all > the servers I've hit then fail to actually provide data and instead > the whois client (Ubuntu 13.04) simply time-outs. > > sfrost at tamriel:/home/sfrost> whois -h 2001:503:5ae2:1060::74 networksolutions.com These work for me on multiple IPv6 carriers, using both the Mac OS X and Debian squeeze whois clients: ---- $ whois -h 2001:503:5ae2:1060::74 networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. NETWORKSOLUTIONS.COM.RESPECTED.BY.WWW.DNDIALOG.COM NETWORKSOLUTIONS.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record. ---- $ whois -h 2001:503:5ae2:1060::74 =networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Server Name: NETWORKSOLUTIONS.COM.RESPECTED.BY.WWW.DNDIALOG.COM IP Address: 81.177.3.240 Registrar: MONIKER ONLINE SERVICES LLC Whois Server: whois.moniker.com Referral URL: http://www.moniker.com Domain Name: NETWORKSOLUTIONS.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com/en_US/ Name Server: NS1.NETSOL.COM Name Server: NS2.NETSOL.COM Name Server: NS3.NETSOL.COM [etc.] ---- Perhaps your WHOIS client is choking on the first type of response without the "="? WHOIS should work fine via telnet to eliminate possible WHOIS client issues; you can just: $ telnet 2001:503:5ae2:1060::74 43 ... and type "=networksolutions.com" to get the raw response. > Anyone from NetSol care? Network Solutions hasn't been involved with the running of whois.internic.net and whois.crsnic.net for many years. They're currently run by VeriSign Global Registry Services. > there's a Debian bug #683187 which mentions similar issues from > nearly a year ago..). Right, but other people couldn't duplicate it. I suspect VeriSign uses rate-limiting; is it possible that your source IP address is just being rate-limited? -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ From morrowc.lists at gmail.com Wed Jul 10 19:45:39 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Jul 2013 15:45:39 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 2:55 PM, Mike Jackson wrote: > That makes sense, I figured it was some type of a CDN caching environment. I forget that we do this at times... :) > I've found that youtube.com is in the same boat: > > Translating "www.youtube.com"...domain server (8.8.8.8) [OK] yup, so this makes sense as well... good. From morrowc.lists at gmail.com Wed Jul 10 19:47:13 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Jul 2013 15:47:13 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 2:41 PM, Mike Jackson wrote: > Hey Chris, long time! > > From what I can tell, it's only Google Services (that I've found so far; > other things appear to resolve correctly). I'm wondering if they're > bouncing Google based traffic through some type of caching / accelerator? > Or maybe it's an NSA/DPI box ;) in .CA? :) don't you mean the meat-helmet-wearing CSE folks? :) > I've tested Maps, Gmail, Translate as well as www.google.com, www.google.ca > and they're all hijacked replies ---->> > yup... well, not hijacked in a bad sense... it's actually supposed to be making things better. > > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > (www.google.com) > > Type escape sequence to abort. > Tracing the route to www.google.com (66.185.84.44) > > (www.google.ca) > > Type escape sequence to abort. > Tracing the route to www.google.ca (66.185.95.44) > > (gmail) > > Type escape sequence to abort. > Tracing the route to www3.l.google.com (66.185.85.39) > > (maps) > > Type escape sequence to abort. > Tracing the route to maps.l.google.com (64.71.249.114) > > (translate) > > Type escape sequence to abort. > Tracing the route to www3.l.google.com (66.185.84.30) those all seem properly done, yes. -chris From sfrost at snowman.net Wed Jul 10 19:52:35 2013 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 10 Jul 2013 15:52:35 -0400 Subject: whois.internic.net / whois.crsnic.net IPv6 timeouts In-Reply-To: <51DDB8D7.9060404@tigertech.com> References: <20130710184546.GV3286@tamriel.snowman.net> <51DDB8D7.9060404@tigertech.com> Message-ID: <20130710195235.GW3286@tamriel.snowman.net> * Robert L Mathews (lists at tigertech.com) wrote: > These work for me on multiple IPv6 carriers, using both the Mac OS X and > Debian squeeze whois clients: Interesting.. > Perhaps your WHOIS client is choking on the first type of response > without the "="? WHOIS should work fine via telnet to eliminate possible > WHOIS client issues; you can just: It's Ubuntu 13.04's 5.0.20ubuntu1 client, so it really shouldn't be much different from the Debian whois you're using. Also, whois -h 199.7.50.74 networksolutions.com works just fine (and includes the blurb). > $ telnet 2001:503:5ae2:1060::74 43 > > ... and type "=networksolutions.com" to get the raw response. Doing this results in it just hanging, similar to with the whois client: sfrost at tamriel:/home/sfrost> telnet 2001:503:5ae2:1060::74 43 Trying 2001:503:5ae2:1060::74... Connected to 2001:503:5ae2:1060::74. Escape character is '^]'. =networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. [... hanging here, still ...] > > Anyone from NetSol care? > > Network Solutions hasn't been involved with the running of > whois.internic.net and whois.crsnic.net for many years. They're > currently run by VeriSign Global Registry Services. Ah, yea, good point. :) > > there's a Debian bug #683187 which mentions similar issues from > > nearly a year ago..). > > Right, but other people couldn't duplicate it. I suspect VeriSign uses > rate-limiting; is it possible that your source IP address is just being > rate-limited? It usually tells you that, actually, and so I doubt that's the case. Also, attempting from other IPv6 addresses results in the same hang (even with the telnet approach). Thanks! Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From johnl at iecc.com Wed Jul 10 19:52:59 2013 From: johnl at iecc.com (John Levine) Date: 10 Jul 2013 19:52:59 -0000 Subject: whois.internic.net / whois.crsnic.net IPv6 timeouts In-Reply-To: <20130710184546.GV3286@tamriel.snowman.net> Message-ID: <20130710195259.73177.qmail@joyce.lan> > Don't know if it'll help or if this is simply old news to most, but > the whois systems (whois.internic.net/whois.crsnic.net) have AAAA > records and happily answer TCP/43 requests w/ the usual blurb, but all > the servers I've hit then fail to actually provide data and instead > the whois client (Ubuntu 13.04) simply time-outs. "It works fine for me." I've had problems before and would guess that it's a routing issue. It my impression that they're anycasted. > Anyone from NetSol care? Since they haven't had anything to do with internic.net or crsnic.net for over a decade, probably not. R's, John From sfrost at snowman.net Wed Jul 10 20:00:30 2013 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 10 Jul 2013 16:00:30 -0400 Subject: whois.internic.net / whois.crsnic.net IPv6 timeouts In-Reply-To: <20130710195259.73177.qmail@joyce.lan> References: <20130710184546.GV3286@tamriel.snowman.net> <20130710195259.73177.qmail@joyce.lan> Message-ID: <20130710200030.GX3286@tamriel.snowman.net> * John Levine (johnl at iecc.com) wrote: > "It works fine for me." Very curious. > I've had problems before and would guess that it's a routing issue. > It my impression that they're anycasted. traceroute6's take me to various places, so I think it may just be a simply DNS round-robin rather than anycast. Now I'm starting to really wonder- I'm having this trouble over a SixXS tunnel but some of the non-tunnel'd IPv6 environments I have access to are working fine. Perhaps the issue here is actually MTU or MSS related? I've not had any problem with SSH connections to regular IPv6 hosts (even transferring large files), either inbound or outbound.. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mike at routed.ca Wed Jul 10 18:41:00 2013 From: mike at routed.ca (Mike Jackson) Date: Wed, 10 Jul 2013 14:41:00 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: Hey Chris, long time! >From what I can tell, it's only Google Services (that I've found so far; other things appear to resolve correctly). I'm wondering if they're bouncing Google based traffic through some type of caching / accelerator? Or maybe it's an NSA/DPI box ;) I've tested Maps, Gmail, Translate as well as www.google.com, www.google.caand they're all hijacked replies ---->> Translating "www.google.com"...domain server (8.8.8.8) [OK] (www.google.com) Type escape sequence to abort. Tracing the route to www.google.com (66.185.84.44) (www.google.ca) Type escape sequence to abort. Tracing the route to www.google.ca (66.185.95.44) (gmail) Type escape sequence to abort. Tracing the route to www3.l.google.com (66.185.85.39) (maps) Type escape sequence to abort. Tracing the route to maps.l.google.com (64.71.249.114) (translate) Type escape sequence to abort. Tracing the route to www3.l.google.com (66.185.84.30) Cheers, - Mike On Wed, Jul 10, 2013 at 2:18 PM, Christopher Morrow wrote: > On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: > > I just realized that it's not Google IP space (74.125.0.0/16), Rogers is > > hijacking the DNS and resolving www.google.com to space within > > 64.71.240.0/20 which is Rogers IP space! (note the name server set as > > 8.8.8.8) > > > > so: > 1) rogers is hijacking traffic to 8.8.8.8 > 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect > information for google properties (at least). > > err... any idea if it's lying about other things too? :) > > > davinci#traceroute www.google.com > > > > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > > > Type escape sequence to abort. > > Tracing the route to www.google.com (66.185.85.29) > > > > 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec > > 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] > 8 > > msec 8 msec 4 msec > > 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec > > 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec > > 5 * * * > > 6 * * * > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > > > TOR2-CORE-R1#show ip bgp 66.185.85.29 > > BGP routing table entry for 66.185.80.0/20, version 13095115 > > Paths: (1 available, best #1, table default) > > Advertised to update-groups: > > 14 > > 701 6461 812 > > 205.205.23.121 from 205.205.23.121 (137.39.8.42) > > Origin IGP, localpref 100, valid, external, best > > TOR2-CORE-R1# > > > > > > Thanks, > > > > - Mike > > > > > > On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > > > >> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but > >> not from Rogers/AS812 in Toronto. I've done a few other test > traceroutes > >> through Rogers to verify that they didn't filter UDP/ICMP. At this > point > >> nothing would surprise me from Rogers. > >> > >> AS701 > >> ===== > >> > >> TOR2-CORE-R1#traceroute www.google.com > >> Translating "www.google.com"...domain server (8.8.8.8) [OK] > >> > >> Type escape sequence to abort. > >> Tracing the route to www.google.com (74.125.26.99) > >> VRF info: (vrf in name/id, vrf out name/id) > >> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec > >> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 > msec > >> 4 msec > >> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 > msec > >> 16 msec > >> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec > >> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec > >> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec > >> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec > >> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec > >> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec > >> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec > >> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec > >> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec > >> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec > >> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec > >> 9 216.239.48.159 [AS 15169] 36 msec 32 msec > >> 216.239.48.59 [AS 15169] 32 msec > >> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec > >> > >> > >> > >> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) > >> =================================================== > >> > >> *Query:* *tr 64.71.249.45* > >> > >> Type escape sequence to abort. > >> Tracing the route to 64.71.249.45 > >> > >> 1 64.71.255.62 0 msec 0 msec 0 msec > >> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec > 4 msec 4 msec > >> 3 69.63.250.189 4 msec 4 msec 4 msec > >> 4 69.63.250.174 4 msec 4 msec 4 msec > >> 5 * * * > >> 6 * * * > >> 7 * * * > >> 8 * * * > >> 9 * * * > >> 10 * * * > >> 11 * * * > >> 12 * * * > >> 13 * * * > >> 14 * * * > >> 15 * * * > >> 16 * * * > >> 17 * * * > >> 18 * * * > >> 19 * * * > >> 20 * * * > >> 21 * * * > >> 22 * * * > >> 23 * * * > >> 24 * * * > >> 25 * * * > >> 26 * * * > >> 27 * * * > >> 28 * * * > >> 29 * * * > >> 30 * * * > >> > >> > >> Cheers, > >> > >> - MJ > >> > >> > >> -----Original Message----- > >>> From: Grant Ridder [mailto:shortdudey123 at gmail.com] > >>> Sent: July-10-13 10:57 AM > >>> To: John York > >>> Cc: nanog at nanog.org > >>> Subject: Re: google troubles? > >>> > >>> Does anyone have traceroutes showing where the issues are? > >>> > >>> -Grant > >>> > >>> On Wed, Jul 10, 2013 at 7:45 AM, John York > >>> wrote: > >>> > >>> > We saw the same thing, but seems to be cleared up now. All our > >>> > providers that routed to Google addresses in ATL had the issue. We > >>> > have one provider that lands on Google addresses in DFW, and it was > >>> working. > >>> > > >>> > ...And now I see that it isn't completely resolved. Some Google apps > >>> > are still inaccessible via the Atlanta routes. > >>> > > >>> > > >>> > > >>> > > >>> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > >>> > >>> > >wrote: > >>> > > >>> > > Seeing lots of reports of people unable to get to many Google > >>> services. > >>> > > Seems to be affecting Comcast users disproportionately. It's fine > >>> > > for > >>> > me, > >>> > > but a lot of my staff are basically out of luck...but according to > >>> > > the Google Apps Status page, everything is fine. > >>> > > > >>> > > It's anecdotal, but it would seem like there's an issue based on > >>> > > these reports. > >>> > > > >>> > > Oh, and this: > >>> > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > >>> > > > >>> > > Anyone know what's up? Fiber cut? DC outages? > >>> > > > >>> > > -- blair > >>> > > > >>> > > >>> > > >>> > > >>> > -- > >>> > > >>> > John York > >>> > > >>> > Information Technology | Network Administrator > >>> > > >>> > Phone: 615-399-7000 x:333 > >>> > > >>> > Griffin Technology > >>> > 2030 Lindell Avenue Nashville, TN 37203 USA > >>> > > >>> > This message and any attachments should be treated as confidential > >>> > information of Griffin Technology, Inc. > >>> > > >>> > >>> > >>> > >>> > >> > >> > From mike at routed.ca Wed Jul 10 18:55:55 2013 From: mike at routed.ca (Mike Jackson) Date: Wed, 10 Jul 2013 14:55:55 -0400 Subject: google troubles? In-Reply-To: References: Message-ID: That makes sense, I figured it was some type of a CDN caching environment. I've found that youtube.com is in the same boat: Translating "www.youtube.com"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Tracing the route to youtube-ui.l.google.com (24.156.153.40) [synkro:ROOT](~): jwhois 24.156.153.40 | grep -i orgname OrgName: Rogers Cable Communications Inc. [synkro:ROOT](~): Thanks! - MJ On Wed, Jul 10, 2013 at 2:39 PM, Christopher Morrow wrote: > On Wed, Jul 10, 2013 at 2:18 PM, Christopher Morrow > wrote: > > On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: > >> I just realized that it's not Google IP space (74.125.0.0/16), Rogers > is > >> hijacking the DNS and resolving www.google.com to space within > >> 64.71.240.0/20 which is Rogers IP space! (note the name server set as > >> 8.8.8.8) > >> > > > > so: > > 1) rogers is hijacking traffic to 8.8.8.8 > > 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect > > information for google properties (at least). > > > > err... any idea if it's lying about other things too? :) > > > > oops, so a polite caller noted that google often ships people at a > local 'google global cache' node if they have one... it seems like > that might be what's going on here with 8.8.8.8 sending you to 64.71 > and/or 66.185 addresses. > > so maybe rogers isn't doing something untoward after all! > > -chris > (thanks for the headslap polite caller) > > >> davinci#traceroute www.google.com > >> > >> Translating "www.google.com"...domain server (8.8.8.8) [OK] > >> > >> Type escape sequence to abort. > >> Tracing the route to www.google.com (66.185.85.29) > >> > >> 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec > >> 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS > 812] 8 > >> msec 8 msec 4 msec > >> 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec > >> 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec > >> 5 * * * > >> 6 * * * > >> 7 * * * > >> 8 * * * > >> 9 * * * > >> 10 * * * > >> > >> TOR2-CORE-R1#show ip bgp 66.185.85.29 > >> BGP routing table entry for 66.185.80.0/20, version 13095115 > >> Paths: (1 available, best #1, table default) > >> Advertised to update-groups: > >> 14 > >> 701 6461 812 > >> 205.205.23.121 from 205.205.23.121 (137.39.8.42) > >> Origin IGP, localpref 100, valid, external, best > >> TOR2-CORE-R1# > >> > >> > >> Thanks, > >> > >> - Mike > >> > >> > >> On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > >> > >>> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but > >>> not from Rogers/AS812 in Toronto. I've done a few other test > traceroutes > >>> through Rogers to verify that they didn't filter UDP/ICMP. At this > point > >>> nothing would surprise me from Rogers. > >>> > >>> AS701 > >>> ===== > >>> > >>> TOR2-CORE-R1#traceroute www.google.com > >>> Translating "www.google.com"...domain server (8.8.8.8) [OK] > >>> > >>> Type escape sequence to abort. > >>> Tracing the route to www.google.com (74.125.26.99) > >>> VRF info: (vrf in name/id, vrf out name/id) > >>> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec > >>> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 > msec > >>> 4 msec > >>> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 > msec > >>> 16 msec > >>> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec > >>> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec > >>> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec > >>> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec > >>> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec > >>> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec > >>> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec > >>> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec > >>> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec > >>> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec > >>> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 > msec > >>> 9 216.239.48.159 [AS 15169] 36 msec 32 msec > >>> 216.239.48.59 [AS 15169] 32 msec > >>> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec > >>> > >>> > >>> > >>> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) > >>> =================================================== > >>> > >>> *Query:* *tr 64.71.249.45* > >>> > >>> Type escape sequence to abort. > >>> Tracing the route to 64.71.249.45 > >>> > >>> 1 64.71.255.62 0 msec 0 msec 0 msec > >>> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec > 4 msec 4 msec > >>> 3 69.63.250.189 4 msec 4 msec 4 msec > >>> 4 69.63.250.174 4 msec 4 msec 4 msec > >>> 5 * * * > >>> 6 * * * > >>> 7 * * * > >>> 8 * * * > >>> 9 * * * > >>> 10 * * * > >>> 11 * * * > >>> 12 * * * > >>> 13 * * * > >>> 14 * * * > >>> 15 * * * > >>> 16 * * * > >>> 17 * * * > >>> 18 * * * > >>> 19 * * * > >>> 20 * * * > >>> 21 * * * > >>> 22 * * * > >>> 23 * * * > >>> 24 * * * > >>> 25 * * * > >>> 26 * * * > >>> 27 * * * > >>> 28 * * * > >>> 29 * * * > >>> 30 * * * > >>> > >>> > >>> Cheers, > >>> > >>> - MJ > >>> > >>> > >>> -----Original Message----- > >>>> From: Grant Ridder [mailto:shortdudey123 at gmail.com] > >>>> Sent: July-10-13 10:57 AM > >>>> To: John York > >>>> Cc: nanog at nanog.org > >>>> Subject: Re: google troubles? > >>>> > >>>> Does anyone have traceroutes showing where the issues are? > >>>> > >>>> -Grant > >>>> > >>>> On Wed, Jul 10, 2013 at 7:45 AM, John York > >>>> wrote: > >>>> > >>>> > We saw the same thing, but seems to be cleared up now. All our > >>>> > providers that routed to Google addresses in ATL had the issue. We > >>>> > have one provider that lands on Google addresses in DFW, and it was > >>>> working. > >>>> > > >>>> > ...And now I see that it isn't completely resolved. Some Google apps > >>>> > are still inaccessible via the Atlanta routes. > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > >>>> > >>>> > >wrote: > >>>> > > >>>> > > Seeing lots of reports of people unable to get to many Google > >>>> services. > >>>> > > Seems to be affecting Comcast users disproportionately. It's > fine > >>>> > > for > >>>> > me, > >>>> > > but a lot of my staff are basically out of luck...but according to > >>>> > > the Google Apps Status page, everything is fine. > >>>> > > > >>>> > > It's anecdotal, but it would seem like there's an issue based on > >>>> > > these reports. > >>>> > > > >>>> > > Oh, and this: > >>>> > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > >>>> > > > >>>> > > Anyone know what's up? Fiber cut? DC outages? > >>>> > > > >>>> > > -- blair > >>>> > > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > > >>>> > John York > >>>> > > >>>> > Information Technology | Network Administrator > >>>> > > >>>> > Phone: 615-399-7000 x:333 > >>>> > > >>>> > Griffin Technology > >>>> > 2030 Lindell Avenue Nashville, TN 37203 USA > >>>> > > >>>> > This message and any attachments should be treated as confidential > >>>> > information of Griffin Technology, Inc. > >>>> > > >>>> > >>>> > >>>> > >>>> > >>> > >>> > From johnl at iecc.com Wed Jul 10 20:14:08 2013 From: johnl at iecc.com (John R. Levine) Date: 10 Jul 2013 16:14:08 -0400 Subject: whois.internic.net / whois.crsnic.net IPv6 timeouts In-Reply-To: <20130710200030.GX3286@tamriel.snowman.net> References: <20130710184546.GV3286@tamriel.snowman.net> <20130710195259.73177.qmail@joyce.lan> <20130710200030.GX3286@tamriel.snowman.net> Message-ID: > Now I'm starting to really wonder- I'm having this trouble over a SixXS > tunnel but some of the non-tunnel'd IPv6 environments I have access to > are working fine. Perhaps the issue here is actually MTU or MSS > related? Possibly. It works fine for me through a HE tunnel, but I think I had problems when I was using a gogonet/freenet6 tunnel. 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 luan20176 at gmail.com Thu Jul 11 14:04:52 2013 From: luan20176 at gmail.com (Luan Nguyen) Date: Thu, 11 Jul 2013 10:04:52 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa Message-ID: Hello folks, Does anyone know what's the average speed for windows file transferring (SMB2) between Hong Kong and Johannesburg? Any guide on how to calculate/estimate this? Thanks. Regards, -Luan From chris.burri at hotmail.ch Thu Jul 11 14:10:20 2013 From: chris.burri at hotmail.ch (chris burri) Date: Thu, 11 Jul 2013 16:10:20 +0200 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: A pointer here: http://en.wikipedia.org/wiki/Bandwidth-delay_product Cheers Chris --- -= Amat Victoria Curam =- > Date: Thu, 11 Jul 2013 10:04:52 -0400 > Subject: File transfer speed between Hong Kong and Johannesburg, South Africa > From: luan20176 at gmail.com > To: nanog at nanog.org > > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan From jrmitche at puck.nether.net Thu Jul 11 14:27:28 2013 From: jrmitche at puck.nether.net (Jon Mitchell) Date: Thu, 11 Jul 2013 07:27:28 -0700 Subject: On topic of domains Message-ID: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> After .nyc thread, thought this IAB announcement may be of interest. http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ -Jon From jared at puck.nether.net Thu Jul 11 14:30:29 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 11 Jul 2013 10:30:29 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: <69FE9AE8-C5C5-4D8B-B0FD-536D40289380@puck.nether.net> Honestly, this depends on what OS you are using. Anything prior to Win7 you are likely to suffer from the TCP stack. Add in anything weird like ICMP filtering, load balancers or something else that eats the packets you are going to see varying results. - Jared On Jul 11, 2013, at 10:04 AM, Luan Nguyen wrote: > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan From tony.mccrory at gmail.com Thu Jul 11 14:47:20 2013 From: tony.mccrory at gmail.com (Tony McCrory) Date: Thu, 11 Jul 2013 15:47:20 +0100 Subject: On topic of domains In-Reply-To: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> Message-ID: Here's a list of TLD's who currently have A records on the TLD as mentioned by IAB AC 193.223.78.210 AI 209.59.119.34 BO 166.114.1.28 CM 195.24.205.60 DK 193.163.102.24 GG 87.117.196.80 IO 193.223.78.212 JE 87.117.196.80 KH 203.223.32.21 PN 80.68.93.100 SH 193.223.78.211 TK 217.119.57.22 TM 193.223.78.213 TO 216.74.32.107 UZ 91.212.89.8 VI 193.0.0.198 WS 64.70.19.33 Tony On 11 July 2013 15:27, Jon Mitchell wrote: > > After .nyc thread, thought this IAB announcement may be of interest. > > > http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ > > -Jon From swmike at swm.pp.se Thu Jul 11 14:48:43 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Jul 2013 16:48:43 +0200 (CEST) Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: On Thu, 11 Jul 2013, Luan Nguyen wrote: > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? Worst case would be that XP is involved, then you're going to be limited by xmodem-like behaviour of SMB, which means you'll get 60 kilobyte of data per RTT. http://blogs.technet.com/b/josebda/archive/2012/06/06/windows-server-2012-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-or-smb-3-0-you-are-using-on-your-file-server.aspx says SMB2 is vista and later, so you will probably be able to get higher speeds than that. If you look at 5, then "request compounding" is probably what solved the problem I mentioned earlier. Unfortunately I dont have further details than this. -- Mikael Abrahamsson email: swmike at swm.pp.se From maxsec at gmail.com Thu Jul 11 15:21:41 2013 From: maxsec at gmail.com (Martin Hepworth) Date: Thu, 11 Jul 2013 16:21:41 +0100 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: Probably quite nasty delays as anything over a few milliseconds delays really badly affects SMB around 90 ms it's just about usable and above 120 ms forget it. have a look at some of the WAN accelerator products esp Aryaka who'll be able to set you up in minutes with no capital outlay.. http://www.aryaka.com/products/network-as-a-service/global-network/ -- Martin Hepworth, CISSP Oxford, UK On 11 July 2013 15:04, Luan Nguyen wrote: > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan > From clayton at MNSi.Net Thu Jul 11 15:32:13 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 11 Jul 2013 11:32:13 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: <1373556736_247918@duplo.mnsi.net> It all depends on the air speed velocity of an unladen swallow, and varies if it is African or Eurpoean. In all seriousness, you need to know the speed and latency of the link before that question can be answered. At 10:04 AM 11/07/2013, Luan Nguyen wrote: >Hello folks, > >Does anyone know what's the average speed for windows file transferring >(SMB2) between Hong Kong and Johannesburg? >Any guide on how to calculate/estimate this? > >Thanks. > >Regards, > >-Luan --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jloiacon at csc.com Thu Jul 11 15:37:51 2013 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 11 Jul 2013 11:37:51 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: The maximum you can expect is: Rate < (MSS/RTT)*(1 / sqrt(p)) where p is the probability of packet loss. Credit: Mathis, Semke, Mahdavi & Ott in Computer Communication Review, 27 (3), July 1997, titled The macroscopic behavior of the TCP congestion avoidance algorithm. ( http://www.infoblox.com/community/blog/tcp-performance-and-mathis-equation ) Joe From: Luan Nguyen To: nanog at nanog.org Date: 07/11/2013 10:06 AM Subject: File transfer speed between Hong Kong and Johannesburg, South Africa Hello folks, Does anyone know what's the average speed for windows file transferring (SMB2) between Hong Kong and Johannesburg? Any guide on how to calculate/estimate this? Thanks. Regards, -Luan -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From chaz at chaz6.com Thu Jul 11 15:54:49 2013 From: chaz at chaz6.com (Chris Hills) Date: Thu, 11 Jul 2013 16:54:49 +0100 Subject: On topic of domains In-Reply-To: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> Message-ID: On 11/07/2013 15:27, Jon Mitchell wrote: > > After .nyc thread, thought this IAB announcement may be of interest. > > http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ > > -Jon > Whilst I am not a fan of dotless domains, as long as one uses the fully qualified domain name (e.g. http://ac./), there should not be any trouble using it in any sane software. It seems that most people aren't aware these days that a fqdn includes the trailing period (by definition). From john at west-canaan.net Thu Jul 11 16:14:08 2013 From: john at west-canaan.net (John Zettlemoyer) Date: Thu, 11 Jul 2013 12:14:08 -0400 Subject: verizon postmaster Message-ID: <89082f00-67a9-4881-bf77-f9e81a587bb9@west-canaan.net> Could someone from Verizon Postmaster please contact me off list? Thank you John Zettlemoyer Sr. Director of I.T. Infrastructure WCiT - West-Canaan LLC john at wcit.net From asullivan at dyn.com Thu Jul 11 16:41:33 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 11 Jul 2013 12:41:33 -0400 Subject: On topic of domains In-Reply-To: References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> Message-ID: If the definition of "FQDN" in some RFCs (Informational or not) always included the trailing dot, I'd be inclined to agree with you. But that's not the case, so protocol slots have been established for "FQDNs" that are actually domains qualified relative to the root. Since this ambiguity has been around since the very dawn of the DNS, I suspect there is little chance of re-educating everyone in the world about this. A On Thu, Jul 11, 2013 at 11:54 AM, Chris Hills wrote: > On 11/07/2013 15:27, Jon Mitchell wrote: > > > > After .nyc thread, thought this IAB announcement may be of interest. > > > > > http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ > > > > -Jon > > > > Whilst I am not a fan of dotless domains, as long as one uses the fully > qualified domain name (e.g. http://ac./), there should not be any > trouble using it in any sane software. It seems that most people aren't > aware these days that a fqdn includes the trailing period (by definition). > > > From luan20176 at gmail.com Thu Jul 11 17:14:39 2013 From: luan20176 at gmail.com (Luan Nguyen) Date: Thu, 11 Jul 2013 13:14:39 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: Thanks guys. We do have Riverbed Steelhead appliances at both end. According to calculation, maximum throughput can be attained is ~330KB/sec. With the Riverbed "cold" transfer, we should get ~600KB/sec. But I can only get ~250KB/sec with the Steelhead doing its stuff for 500M file so plenty of time for whatever to kick in. Iperf and netperf show great results though. I guess I will be sampling results hourly for comparison. Regards, -Luan On Thu, Jul 11, 2013 at 11:37 AM, Joe Loiacono wrote: > The maximum you can expect is: > > Rate < (MSS/RTT)*(1 / sqrt(p)) where p is the probability of packet loss. > > Credit: Mathis, Semke, Mahdavi & Ott in Computer Communication Review, > 27(3), July 1997, titled The macroscopic behavior of the TCP congestion > avoidance algorithm. ( > http://www.infoblox.com/community/blog/tcp-performance-and-mathis-equation) > > Joe > > [image: Inactive hide details for Luan Nguyen ---07/11/2013 10:06:19 > AM---Hello folks, Does anyone know what's the average speed for wi]Luan > Nguyen ---07/11/2013 10:06:19 AM---Hello folks, Does anyone know what's the > average speed for windows file transferring > > From: Luan Nguyen > To: nanog at nanog.org > Date: 07/11/2013 10:06 AM > Subject: File transfer speed between Hong Kong and Johannesburg, South > Africa > ------------------------------ > > > > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan > > From wbailey at satelliteintelligencegroup.com Thu Jul 11 17:36:24 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 11 Jul 2013 17:36:24 +0000 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: , Message-ID: Look at your MTU on links.. Sent from my Mobile Device. -------- Original message -------- From: Luan Nguyen Date: 07/11/2013 10:16 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: File transfer speed between Hong Kong and Johannesburg, South Africa Thanks guys. We do have Riverbed Steelhead appliances at both end. According to calculation, maximum throughput can be attained is ~330KB/sec. With the Riverbed "cold" transfer, we should get ~600KB/sec. But I can only get ~250KB/sec with the Steelhead doing its stuff for 500M file so plenty of time for whatever to kick in. Iperf and netperf show great results though. I guess I will be sampling results hourly for comparison. Regards, -Luan On Thu, Jul 11, 2013 at 11:37 AM, Joe Loiacono wrote: > The maximum you can expect is: > > Rate < (MSS/RTT)*(1 / sqrt(p)) where p is the probability of packet loss. > > Credit: Mathis, Semke, Mahdavi & Ott in Computer Communication Review, > 27(3), July 1997, titled The macroscopic behavior of the TCP congestion > avoidance algorithm. ( > http://www.infoblox.com/community/blog/tcp-performance-and-mathis-equation) > > Joe > > [image: Inactive hide details for Luan Nguyen ---07/11/2013 10:06:19 > AM---Hello folks, Does anyone know what's the average speed for wi]Luan > Nguyen ---07/11/2013 10:06:19 AM---Hello folks, Does anyone know what's the > average speed for windows file transferring > > From: Luan Nguyen > To: nanog at nanog.org > Date: 07/11/2013 10:06 AM > Subject: File transfer speed between Hong Kong and Johannesburg, South > Africa > ------------------------------ > > > > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan > > From luan20176 at gmail.com Thu Jul 11 17:51:02 2013 From: luan20176 at gmail.com (Luan Nguyen) Date: Thu, 11 Jul 2013 13:51:02 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: Is there a tool to do that end to end? Path MTU discovery tool? We use GRE/IPSEC with a WS-IPSEC 3 setting the tunnel to MTU 1400 with MSS = 1360 both end. The steelhead set to 1400 MTU as well since I was told the steelhead will set the DF bit. Steelhead log doesn't show timeout, unable to connect/ retry or anything to suggest drop packets though. Thanks. Regards, -Luan On Thu, Jul 11, 2013 at 1:36 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Look at your MTU on links.. > > > Sent from my Mobile Device. > > > > -------- Original message -------- > From: Luan Nguyen > Date: 07/11/2013 10:16 AM (GMT-08:00) > To: nanog at nanog.org > Subject: Re: File transfer speed between Hong Kong and Johannesburg, South > Africa > > > Thanks guys. > > We do have Riverbed Steelhead appliances at both end. > According to calculation, maximum throughput can be attained is ~330KB/sec. > With the Riverbed "cold" transfer, we should get ~600KB/sec. But I can only > get ~250KB/sec with the Steelhead doing its stuff for 500M file so plenty > of time for whatever to kick in. Iperf and netperf show great results > though. > I guess I will be sampling results hourly for comparison. > > Regards, > > -Luan > > > On Thu, Jul 11, 2013 at 11:37 AM, Joe Loiacono wrote: > > > The maximum you can expect is: > > > > Rate < (MSS/RTT)*(1 / sqrt(p)) where p is the probability of packet loss. > > > > Credit: Mathis, Semke, Mahdavi & Ott in Computer Communication Review, > > 27(3), July 1997, titled The macroscopic behavior of the TCP congestion > > avoidance algorithm. ( > > > http://www.infoblox.com/community/blog/tcp-performance-and-mathis-equation > ) > > > > Joe > > > > [image: Inactive hide details for Luan Nguyen ---07/11/2013 10:06:19 > > AM---Hello folks, Does anyone know what's the average speed for wi]Luan > > Nguyen ---07/11/2013 10:06:19 AM---Hello folks, Does anyone know what's > the > > average speed for windows file transferring > > > > From: Luan Nguyen > > To: nanog at nanog.org > > Date: 07/11/2013 10:06 AM > > Subject: File transfer speed between Hong Kong and Johannesburg, South > > Africa > > ------------------------------ > > > > > > > > > Hello folks, > > > > Does anyone know what's the average speed for windows file transferring > > (SMB2) between Hong Kong and Johannesburg? > > Any guide on how to calculate/estimate this? > > > > Thanks. > > > > Regards, > > > > -Luan > > > > > From nick at foobar.org Thu Jul 11 17:51:41 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 11 Jul 2013 18:51:41 +0100 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: <51DEF0AD.9070206@foobar.org> On 11/07/2013 18:14, Luan Nguyen wrote: > We do have Riverbed Steelhead appliances at both end. > According to calculation, maximum throughput can be attained is ~330KB/sec. > With the Riverbed "cold" transfer, we should get ~600KB/sec. But I can only > get ~250KB/sec with the Steelhead doing its stuff for 500M file so plenty > of time for whatever to kick in. Iperf and netperf show great results > though. > I guess I will be sampling results hourly for comparison. I can't think of a worse protocol you could use in this situation. Well maybe if it were layered on top of IPX... You may want to consider alternative proposals for handling file transfer between these two locations. E.g. google docs, office 365, etc. Alternatively something simple like using mounts which are r/w on one side but r/o on the other, and using tools like rsync to mirror the r/w on the local side to the r/o mount on other. Live SMB filesharing is a disaster over large rtt links. Nick From nick at foobar.org Thu Jul 11 18:04:04 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 11 Jul 2013 19:04:04 +0100 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: <51DEF394.302@foobar.org> On 11/07/2013 18:51, Luan Nguyen wrote: > Is there a tool to do that end to end? Path MTU discovery tool? yes: scamper > We use GRE/IPSEC with a WS-IPSEC 3 setting the tunnel to MTU 1400 with MSS > = 1360 both end. if you're using cisco kit for the ipsec tunnel, I'd recommend the following: crypto ipsec fragmentation before-encryption crypto ipsec df-bit clear if you handle the fragmentation properly, 1360 should be ok for the mtu. Nick > The steelhead set to 1400 MTU as well since I was told the steelhead will > set the DF bit. > Steelhead log doesn't show timeout, unable to connect/ retry or anything to > suggest drop packets though. > > Thanks. > > Regards, > > -Luan > > > On Thu, Jul 11, 2013 at 1:36 PM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> Look at your MTU on links.. >> >> >> Sent from my Mobile Device. >> >> >> >> -------- Original message -------- >> From: Luan Nguyen >> Date: 07/11/2013 10:16 AM (GMT-08:00) >> To: nanog at nanog.org >> Subject: Re: File transfer speed between Hong Kong and Johannesburg, South >> Africa >> >> >> Thanks guys. >> >> We do have Riverbed Steelhead appliances at both end. >> According to calculation, maximum throughput can be attained is ~330KB/sec. >> With the Riverbed "cold" transfer, we should get ~600KB/sec. But I can only >> get ~250KB/sec with the Steelhead doing its stuff for 500M file so plenty >> of time for whatever to kick in. Iperf and netperf show great results >> though. >> I guess I will be sampling results hourly for comparison. >> >> Regards, >> >> -Luan >> >> >> On Thu, Jul 11, 2013 at 11:37 AM, Joe Loiacono wrote: >> >>> The maximum you can expect is: >>> >>> Rate < (MSS/RTT)*(1 / sqrt(p)) where p is the probability of packet loss. >>> >>> Credit: Mathis, Semke, Mahdavi & Ott in Computer Communication Review, >>> 27(3), July 1997, titled The macroscopic behavior of the TCP congestion >>> avoidance algorithm. ( >>> >> http://www.infoblox.com/community/blog/tcp-performance-and-mathis-equation >> ) >>> >>> Joe >>> >>> [image: Inactive hide details for Luan Nguyen ---07/11/2013 10:06:19 >>> AM---Hello folks, Does anyone know what's the average speed for wi]Luan >>> Nguyen ---07/11/2013 10:06:19 AM---Hello folks, Does anyone know what's >> the >>> average speed for windows file transferring >>> >>> From: Luan Nguyen >>> To: nanog at nanog.org >>> Date: 07/11/2013 10:06 AM >>> Subject: File transfer speed between Hong Kong and Johannesburg, South >>> Africa >>> ------------------------------ >> >>> >>> >>> >>> Hello folks, >>> >>> Does anyone know what's the average speed for windows file transferring >>> (SMB2) between Hong Kong and Johannesburg? >>> Any guide on how to calculate/estimate this? >>> >>> Thanks. >>> >>> Regards, >>> >>> -Luan >>> >>> >> From wbailey at satelliteintelligencegroup.com Thu Jul 11 18:36:44 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 11 Jul 2013 18:36:44 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages Message-ID: Anyone else planning on bailing from office365? http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data Sent from my Mobile Device. From jfmezei_nanog at vaxination.ca Thu Jul 11 18:40:08 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 11 Jul 2013 14:40:08 -0400 Subject: Typical link speeds between COs Message-ID: <51DEFC08.1020609@vaxination.ca> What are the typical speeds used on fibre links between COs in North American and elsewhere ? I realise that there are special cases, such as Shaw using WDM to reach 400gigabits/sec in a link in Western Canada. But what are the most common speeds ? Is WDM in common use to multiplex multiple 10gbps, 40gbps links ? Or is that used mostly for intercity trunks and intra-city trunks tend to not bother with WDM because of ample supply of fibre ? Do telcos typically quickly upgrade fibre strands to newer speeds, or are there still many strands handling only 100mbps or 1gbps between COs because telcos never got around to upgrading legacy equipment/services (such as ATM etc) ? Also in terms of costing WDM, would one typically have a card that has the multiple colours in the card and outputs a single multi-colour signal or would one typically have separate cards for each colour and then use a WDM "filter" to combine/separate colours onto the single strand ? From jared at puck.nether.net Thu Jul 11 19:25:54 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 11 Jul 2013 15:25:54 -0400 Subject: Typical link speeds between COs In-Reply-To: <51DEFC08.1020609@vaxination.ca> References: <51DEFC08.1020609@vaxination.ca> Message-ID: On Jul 11, 2013, at 2:40 PM, Jean-Francois Mezei wrote: > What are the typical speeds used on fibre links between COs in North > American and elsewhere ? So, with a single pair of fiber, you can easily purchase a system (including amps) to do 40x10G. How far you it reaches all depends on the equipment you use. > I realise that there are special cases, such as Shaw using WDM to reach > 400gigabits/sec in a link in Western Canada. But what are the most > common speeds ? Most common increment these days is OTU2 or ~10G client side. You can get 100G solutions from vendors as well. > Is WDM in common use to multiplex multiple 10gbps, 40gbps links ? Or is > that used mostly for intercity trunks and intra-city trunks tend to not > bother with WDM because of ample supply of fibre ? Much of this depends on the existing services on a path, what's in-use, etc. > Do telcos typically quickly upgrade fibre strands to newer speeds, or > are there still many strands handling only 100mbps or 1gbps between COs > because telcos never got around to upgrading legacy equipment/services > (such as ATM etc) ? I'm sure there are plenty of legacy services out there. I've seen pricing of ethernet-over-copper services for 5-10megs that are the same as existing T1 pricing. Carriers like to move away from the T1/DS1/DS3 business as it's lower cost and typically unregulated. > Also in terms of costing WDM, would one typically have a card that has > the multiple colours in the card and outputs a single multi-colour > signal or would one typically have separate cards for each colour and > then use a WDM "filter" to combine/separate colours onto the single strand ? This depends on many things. I've seen people doing all variants of this, and they work with varying degrees depending on the equipment involved. You also will see that within datacenters or buildings where you may hit 1km, 2km or even 10km limits on a campus. There should be plenty of vendors that will be happy to talk to you about active/passive cwdm/dwdm systems. - Jared From surfer at mauigateway.com Thu Jul 11 19:26:51 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 11 Jul 2013 12:26:51 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages Message-ID: <20130711122651.CBC3CA5F@m0005311.ppops.net> --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey Anyone else planning on bailing from office365? http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data ---------------------------------------------------------- Bail on M$ period. If they give the data willingly this way, I'm sure they also do it in other currently unknown ways. Company culture and all that... scott From scott at doc.net.au Thu Jul 11 20:02:26 2013 From: scott at doc.net.au (Scott Howard) Date: Thu, 11 Jul 2013 22:02:26 +0200 Subject: gTLDs opened up In-Reply-To: References: Message-ID: On Wed, Jun 19, 2013 at 12:05 PM, Randy Bush wrote: > AfriNIC put these wonderful people on stage at the African Internet > Summit. > At least they are good enough to include the facts in their FAQ : * 5 - Do business firms use open roots?* *Nowadays, no, or they are not identified. * Scott From alex.buie at frozenfeline.net Thu Jul 11 20:08:41 2013 From: alex.buie at frozenfeline.net (Alex Buie) Date: Thu, 11 Jul 2013 13:08:41 -0700 Subject: gTLDs opened up In-Reply-To: References: Message-ID: Am I missing something, or is that purporting to be an IPv4 address beginning with 478? http://www.open-root.eu/about-open-root/how-to-install-an-open-root-website-69/ On Thu, Jul 11, 2013 at 1:02 PM, Scott Howard wrote: > On Wed, Jun 19, 2013 at 12:05 PM, Randy Bush wrote: > > > AfriNIC put these wonderful people on stage at the African Internet > > Summit. > > > > At least they are good enough to include the facts in their FAQ : > > * 5 - Do business firms use open roots?* > *Nowadays, no, or they are not identified. * > > Scott > From james at cs.fiu.edu Thu Jul 11 14:08:54 2013 From: james at cs.fiu.edu (James Grace) Date: Thu, 11 Jul 2013 10:08:54 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: <6F4BACD8-410F-4252-A512-F5BE23267241@cs.fiu.edu> Hey Luan, Here is a good guide that will help you optimise your throughput. As for knowing the average, it all depends on pipe size, network topology, end host configurations to even conjure a guess. http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ -James On Jul11 2013, at 10:04, Luan Nguyen wrote: > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan From mshaw at fairpoint.com Thu Jul 11 14:52:59 2013 From: mshaw at fairpoint.com (Shaw, Matthew) Date: Thu, 11 Jul 2013 14:52:59 +0000 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: <69FE9AE8-C5C5-4D8B-B0FD-536D40289380@puck.nether.net> References: <69FE9AE8-C5C5-4D8B-B0FD-536D40289380@puck.nether.net> Message-ID: <457F9455036417428963A59E3B3887412023C323@0NH1C2P10.fairpoint.com> He specified SMBv2 so I think you're on track with him being on a Win7 / WinSrv2008 box. There are a number of variables at play here though, one of which is who the provider's in-between the two locations are and the quality / number of peering points you'd have to cross. If the endpoints were already setup, I'd schedule a number of decently sized (big enough that it takes at least 5 - 10 minutes for scaling to do its thing) test transfers hourly or once every couple hours over the course of a week to get a baseline and understanding of how time of day traffic affects the transfer. If it's live traffic on the other hand, where a user is pulling up some massive file from the other office, you're likely better off looking into a WAN accelerator appliance. - Matt -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Thursday, July 11, 2013 10:30 AM To: Luan Nguyen Cc: nanog at nanog.org Subject: Re: File transfer speed between Hong Kong and Johannesburg, South Africa Honestly, this depends on what OS you are using. Anything prior to Win7 you are likely to suffer from the TCP stack. Add in anything weird like ICMP filtering, load balancers or something else that eats the packets you are going to see varying results. - Jared On Jul 11, 2013, at 10:04 AM, Luan Nguyen wrote: > Hello folks, > > Does anyone know what's the average speed for windows file transferring > (SMB2) between Hong Kong and Johannesburg? > Any guide on how to calculate/estimate this? > > Thanks. > > Regards, > > -Luan _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From gparent at gparent.org Thu Jul 11 16:42:50 2013 From: gparent at gparent.org (Guillaume Parent) Date: Thu, 11 Jul 2013 12:42:50 -0400 Subject: On topic of domains In-Reply-To: References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> Message-ID: Most of us would have no problem doing it, but the majority of users don't even understand why there's dots in the first place let any why they'd need to put one for nyc but not for facebook.com -gp On Thu, Jul 11, 2013 at 11:54 AM, Chris Hills wrote: > On 11/07/2013 15:27, Jon Mitchell wrote: > > > > After .nyc thread, thought this IAB announcement may be of interest. > > > > > http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ > > > > -Jon > > > > Whilst I am not a fan of dotless domains, as long as one uses the fully > qualified domain name (e.g. http://ac./), there should not be any > trouble using it in any sane software. It seems that most people aren't > aware these days that a fqdn includes the trailing period (by definition). > > > From michael at supermathie.net Thu Jul 11 20:26:34 2013 From: michael at supermathie.net (Michael Brown) Date: Thu, 11 Jul 2013 16:26:34 -0400 Subject: gTLDs opened up In-Reply-To: References: Message-ID: <51DF14FA.2080505@supermathie.net> On 13-07-11 04:08 PM, Alex Buie wrote: > Am I missing something, or is that purporting to be an IPv4 address > beginning with 478? Heh... it seems as though they mistyped '*78.47.115.194*' there. > 7 - How to distinguish between identical TLDs? > Within the Icann framework, names such as: tube.com, tube.net, tube.org, etc. allow in principle to differentiate different domains under the same name. > Within the open root framework, if there are several .tube, one will distinguish them according to the root being activated. Wait... so 'open root' isn't a single alternative root namespace? It's different depending on... near as I can tell which part of the planet you're in? Or is the product multiple independent roots... are you buying your own '.' tree or a 'tld.' tree? Clearly, this will work? Is this the future? "Visit my site at http://fluttershy.turgid.wonka.^78.47.115.194/index.go" -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From scott at doc.net.au Thu Jul 11 20:35:06 2013 From: scott at doc.net.au (Scott Howard) Date: Thu, 11 Jul 2013 22:35:06 +0200 Subject: gTLDs opened up In-Reply-To: References: Message-ID: If you're re-defining the general perception of DNS, why not re-define IPv4 whilst you're at it? It looks like the 4 at the start shouldn't be there - or at least, there is a DNS server at the IP address you get without the 4... Scott On Thu, Jul 11, 2013 at 10:08 PM, Alex Buie wrote: > Am I missing something, or is that purporting to be an IPv4 address > beginning with 478? > > > http://www.open-root.eu/about-open-root/how-to-install-an-open-root-website-69/ > > > On Thu, Jul 11, 2013 at 1:02 PM, Scott Howard wrote: > > > On Wed, Jun 19, 2013 at 12:05 PM, Randy Bush wrote: > > > > > AfriNIC put these wonderful people on stage at the African Internet > > > Summit. > > > > > > > At least they are good enough to include the facts in their FAQ : > > > > * 5 - Do business firms use open roots?* > > *Nowadays, no, or they are not identified. * > > > > Scott > > > From morrowc.lists at gmail.com Thu Jul 11 20:49:17 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jul 2013 16:49:17 -0400 Subject: gTLDs opened up In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 4:08 PM, Alex Buie wrote: > Am I missing something, or is that purporting to be an IPv4 address > beginning with 478? > > http://www.open-root.eu/about-open-root/how-to-install-an-open-root-website-69/ you clearly are being limited by your bias to binary maths. http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-10 From alex.buie at frozenfeline.net Thu Jul 11 20:51:49 2013 From: alex.buie at frozenfeline.net (Alex Buie) Date: Thu, 11 Jul 2013 13:51:49 -0700 Subject: gTLDs opened up In-Reply-To: <51DF14FA.2080505@supermathie.net> References: <51DF14FA.2080505@supermathie.net> Message-ID: They apparently have different "zones" (ie, they run 5 different, separate roots), and you pay a different price depending on how many "zones" you want your TLD to be active in. (cf http://www.open-root.eu/our-rates/list-of-zones-and-pricing/) On Thu, Jul 11, 2013 at 1:26 PM, Michael Brown wrote: > On 13-07-11 04:08 PM, Alex Buie wrote: > > Am I missing something, or is that purporting to be an IPv4 address > beginning with 478? > > Heh? it seems as though they mistyped '*78.47.115.194*' there. > > > 7 - How to distinguish between identical TLDs? > > > Within the Icann framework, names such as: tube.com, tube.net, tube.org, > etc. allow in principle to differentiate different domains under the same > name. > > > Within the open root framework, if there are several .tube, one will > distinguish them according to the root being activated. > Wait? so 'open root' isn't a single alternative root namespace? It's > different depending on? near as I can tell which part of the planet you're > in? > > Or is the product multiple independent roots? are you buying your own '.' > tree or a 'tld.' tree? > > Clearly, this will work? > > Is this the future? "Visit my site at > http://fluttershy.turgid.wonka.^78.47.115.194/index.go" > > -- > Michael Brown | The true sysadmin does not adjust his behaviour > Systems Administrator | to fit the machine. He adjusts the machinemichael at supermathie.net | until it behaves properly. With a hammer, > | if necessary. - Brian > > From maxsec at gmail.com Thu Jul 11 20:56:30 2013 From: maxsec at gmail.com (Martin Hepworth) Date: Thu, 11 Jul 2013 21:56:30 +0100 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: also check the steelhead isn't getting swamped by too many connections. The Units are rated at and have a fixed max number of connections per device.If you need more connections you need a bigger/more costly device. -- Martin Hepworth, CISSP Oxford, UK On 11 July 2013 18:14, Luan Nguyen wrote: > Thanks guys. > > We do have Riverbed Steelhead appliances at both end. > According to calculation, maximum throughput can be attained is ~330KB/sec. > With the Riverbed "cold" transfer, we should get ~600KB/sec. But I can only > get ~250KB/sec with the Steelhead doing its stuff for 500M file so plenty > of time for whatever to kick in. Iperf and netperf show great results > though. > I guess I will be sampling results hourly for comparison. > > Regards, > > -Luan > > > On Thu, Jul 11, 2013 at 11:37 AM, Joe Loiacono wrote: > > > The maximum you can expect is: > > > > Rate < (MSS/RTT)*(1 / sqrt(p)) where p is the probability of packet loss. > > > > Credit: Mathis, Semke, Mahdavi & Ott in Computer Communication Review, > > 27(3), July 1997, titled The macroscopic behavior of the TCP congestion > > avoidance algorithm. ( > > > http://www.infoblox.com/community/blog/tcp-performance-and-mathis-equation > ) > > > > Joe > > > > [image: Inactive hide details for Luan Nguyen ---07/11/2013 10:06:19 > > AM---Hello folks, Does anyone know what's the average speed for wi]Luan > > Nguyen ---07/11/2013 10:06:19 AM---Hello folks, Does anyone know what's > the > > average speed for windows file transferring > > > > From: Luan Nguyen > > To: nanog at nanog.org > > Date: 07/11/2013 10:06 AM > > Subject: File transfer speed between Hong Kong and Johannesburg, South > > Africa > > ------------------------------ > > > > > > > > Hello folks, > > > > Does anyone know what's the average speed for windows file transferring > > (SMB2) between Hong Kong and Johannesburg? > > Any guide on how to calculate/estimate this? > > > > Thanks. > > > > Regards, > > > > -Luan > > > > > From randy at iij.ad.jp Thu Jul 11 20:56:45 2013 From: randy at iij.ad.jp (Randy Bush) Date: Thu, 11 Jul 2013 10:56:45 -1000 Subject: roadrunner takes a really long excursion Message-ID: ryuu.psg.com:/Users/randy> traceroute wrt-tokyo traceroute to wrt-tokyo.rg.net (210.138.216.50), 64 hops max, 52 byte packets 1 wrt-hawi.lan (192.168.0.1) 1.089 ms 0.838 ms 0.805 ms 2 cpe-72-130-240-1.hawaii.res.rr.com (72.130.240.1) 28.964 ms 27.591 ms 27.825 ms 3 tge7-5.klaohias-cer03.hawaii.rr.com (24.25.231.29) 40.011 ms 25.291 ms 48.273 ms 4 tge8-1.klaohias-cer02.hawaii.rr.com (72.129.46.144) 61.741 ms 62.058 ms 60.293 ms 5 tge0-4-0-2.kmlahi07-ccr01.hawaii.rr.com (72.129.46.128) 63.927 ms 74.082 ms 64.340 ms 6 agg31.tustcaft-ccr01.socal.rr.com (72.129.45.2) 71.929 ms 64.954 ms 64.037 ms 7 107.14.17.134 (107.14.17.134) 60.455 ms 65.103 ms 63.598 ms 8 ae-5-0.cr0.dca20.tbone.rr.com (66.109.6.3) 130.063 ms 133.030 ms 134.285 ms 9 107.14.17.178 (107.14.17.178) 133.206 ms ae-0-0.cr0.dca10.tbone.rr.com (66.109.6.30) 130.485 ms 107.14.17.178 (107.14.17.178) 132.164 ms 10 ae0.pr1.dca10.tbone.rr.com (107.14.17.200) 185.126 ms ae1.pr1.dca10.tbone.rr.com (107.14.17.202) 132.416 ms ae0.pr1.dca10.tbone.rr.com (107.14.17.200) 132.197 ms 11 209.48.38.225 (209.48.38.225) 153.804 ms 149.394 ms 152.942 ms 12 vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66) 158.140 ms 168.326 ms 168.755 ms 13 te-11-0-0.rar3.sanjose-ca.us.xo.net (207.88.12.69) 156.495 ms 160.694 ms 158.592 ms 14 207.88.14.226.ptr.us.xo.net (207.88.14.226) 158.936 ms 161.480 ms 149.665 ms 15 216.98.100.253 (216.98.100.253) 142.506 ms 141.179 ms 140.945 ms 16 sjc002bf02.iij.net (206.132.169.9) 141.301 ms 143.095 ms sea001bf00.iij.net (206.132.168.1) 157.606 ms 17 tky009bf01.iij.net (206.132.169.122) 409.387 ms tky008bf00.iij.net (206.132.169.110) 325.051 ms tky008bf01.iij.net (206.132.169.174) 248.289 ms 18 tky001bb11.iij.net (58.138.80.42) 259.764 ms tky001bb10.iij.net (58.138.80.10) 243.385 ms tky001bb11.iij.net (58.138.80.42) 352.163 ms 19 tky001lip20.iij.net (58.138.100.214) 409.185 ms 406.441 ms tky001lip20.iij.net (58.138.100.210) 409.536 ms 20 tokyo10-ntteast0.flets.2iij.net (210.149.34.98) 257.222 ms 409.180 ms 314.596 ms 21 tokyo10-f03.flets.2iij.net (210.149.34.158) 299.887 ms 306.765 ms 307.255 ms 22 50.216.138.210.bn.2iij.net (210.138.216.50) 409.697 ms 409.540 ms 409.365 ms well, i guess it could have gone through europe after dca to get to their xo peering in san jose. randy From randy at psg.com Thu Jul 11 21:01:56 2013 From: randy at psg.com (Randy Bush) Date: Thu, 11 Jul 2013 11:01:56 -1000 Subject: roadrunner takes a really long excursion Message-ID: ryuu.psg.com:/Users/randy> traceroute wrt-tokyo.rg.net traceroute to wrt-tokyo.rg.net (210.138.216.50), 64 hops max, 52 byte packets 1 wrt-hawi.lan (192.168.0.1) 1.089 ms 0.838 ms 0.805 ms 2 cpe-72-130-240-1.hawaii.res.rr.com (72.130.240.1) 28.964 ms 27.591 ms 27.825 ms 3 tge7-5.klaohias-cer03.hawaii.rr.com (24.25.231.29) 40.011 ms 25.291 ms 48.273 ms 4 tge8-1.klaohias-cer02.hawaii.rr.com (72.129.46.144) 61.741 ms 62.058 ms 60.293 ms 5 tge0-4-0-2.kmlahi07-ccr01.hawaii.rr.com (72.129.46.128) 63.927 ms 74.082 ms 64.340 ms 6 agg31.tustcaft-ccr01.socal.rr.com (72.129.45.2) 71.929 ms 64.954 ms 64.037 ms 7 107.14.17.134 (107.14.17.134) 60.455 ms 65.103 ms 63.598 ms 8 ae-5-0.cr0.dca20.tbone.rr.com (66.109.6.3) 130.063 ms 133.030 ms 134.285 ms 9 107.14.17.178 (107.14.17.178) 133.206 ms ae-0-0.cr0.dca10.tbone.rr.com (66.109.6.30) 130.485 ms 107.14.17.178 (107.14.17.178) 132.164 ms 10 ae0.pr1.dca10.tbone.rr.com (107.14.17.200) 185.126 ms ae1.pr1.dca10.tbone.rr.com (107.14.17.202) 132.416 ms ae0.pr1.dca10.tbone.rr.com (107.14.17.200) 132.197 ms 11 209.48.38.225 (209.48.38.225) 153.804 ms 149.394 ms 152.942 ms 12 vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66) 158.140 ms 168.326 ms 168.755 ms 13 te-11-0-0.rar3.sanjose-ca.us.xo.net (207.88.12.69) 156.495 ms 160.694 ms 158.592 ms 14 207.88.14.226.ptr.us.xo.net (207.88.14.226) 158.936 ms 161.480 ms 149.665 ms 15 216.98.100.253 (216.98.100.253) 142.506 ms 141.179 ms 140.945 ms 16 sjc002bf02.iij.net (206.132.169.9) 141.301 ms 143.095 ms sea001bf00.iij.net (206.132.168.1) 157.606 ms 17 tky009bf01.iij.net (206.132.169.122) 409.387 ms tky008bf00.iij.net (206.132.169.110) 325.051 ms tky008bf01.iij.net (206.132.169.174) 248.289 ms 18 tky001bb11.iij.net (58.138.80.42) 259.764 ms tky001bb10.iij.net (58.138.80.10) 243.385 ms tky001bb11.iij.net (58.138.80.42) 352.163 ms 19 tky001lip20.iij.net (58.138.100.214) 409.185 ms 406.441 ms tky001lip20.iij.net (58.138.100.210) 409.536 ms 20 tokyo10-ntteast0.flets.2iij.net (210.149.34.98) 257.222 ms 409.180 ms 314.596 ms 21 tokyo10-f03.flets.2iij.net (210.149.34.158) 299.887 ms 306.765 ms 307.255 ms 22 50.216.138.210.bn.2iij.net (210.138.216.50) 409.697 ms 409.540 ms 409.365 ms well, i guess it could have gone through europe after dca to get to their xo peering. i guess the root cause is that roadrunner is poorly peered. are they not actually twt? randy From jared at puck.nether.net Thu Jul 11 21:14:06 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 11 Jul 2013 17:14:06 -0400 Subject: roadrunner takes a really long excursion In-Reply-To: References: Message-ID: <56FB1679-7063-4A71-875D-8F098EE55FA6@puck.nether.net> I think they are twc which is not twt. Jared Mauch > On Jul 11, 2013, at 5:01 PM, Randy Bush wrote: > > are they not actually twt? From randy at psg.com Thu Jul 11 21:18:53 2013 From: randy at psg.com (Randy Bush) Date: Thu, 11 Jul 2013 11:18:53 -1000 Subject: roadrunner takes a really long excursion In-Reply-To: <56FB1679-7063-4A71-875D-8F098EE55FA6@puck.nether.net> References: <56FB1679-7063-4A71-875D-8F098EE55FA6@puck.nether.net> Message-ID: > I think they are twc which is not twt. uh doh. sorreee From drais at icantclick.org Thu Jul 11 21:20:23 2013 From: drais at icantclick.org (david raistrick) Date: Thu, 11 Jul 2013 17:20:23 -0400 (EDT) Subject: roadrunner takes a really long excursion In-Reply-To: References: Message-ID: On Thu, 11 Jul 2013, Randy Bush wrote: > their xo peering. i guess the root cause is that roadrunner is poorly > peered. are they not actually twt? Nope. TWT vs TWC. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From tshaw at oitc.com Thu Jul 11 21:35:18 2013 From: tshaw at oitc.com (TR Shaw) Date: Thu, 11 Jul 2013 17:35:18 -0400 Subject: roadrunner takes a really long excursion In-Reply-To: References: Message-ID: <5966F2D6-A8E3-439D-AD3E-D6352F0D4FD0@oitc.com> TWT spun off from TW in 1998 or 9 if I remember. TWC ala RoadRunner is a build out of what was left of TW's residential footprint and services. RoadRunner also supports portions of old TWC plant that was sold off to Brighthouse Communications. Tom On Jul 11, 2013, at 5:20 PM, david raistrick wrote: > On Thu, 11 Jul 2013, Randy Bush wrote: > >> their xo peering. i guess the root cause is that roadrunner is poorly >> peered. are they not actually twt? > > Nope. TWT vs TWC. > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org ascii ribbon campaign - stop html mail > http://www.asciiribbon.org/ > > > > From rwebb at ropeguru.com Thu Jul 11 21:15:33 2013 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 11 Jul 2013 21:15:33 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <20130711122651.CBC3CA5F@m0005311.ppops.net> References: <20130711122651.CBC3CA5F@m0005311.ppops.net> Message-ID: <031d4b9618de489b82490767892bd662@BN1PR08MB124.namprd08.prod.outlook.com> Trying my best here to bail. Between this and the fact they are pulling Technet, along with lots of other little things, I am working my way out. Robert ________________________________________ From: Scott Weeks Sent: Thursday, July 11, 2013 15:26 To: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey Anyone else planning on bailing from office365? http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data ---------------------------------------------------------- Bail on M$ period. If they give the data willingly this way, I'm sure they also do it in other currently unknown ways. Company culture and all that... scott From marka at isc.org Thu Jul 11 22:45:50 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Jul 2013 08:45:50 +1000 Subject: On topic of domains In-Reply-To: Your message of "Thu, 11 Jul 2013 16:54:49 +0100." References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> Message-ID: <20130711224552.7630137352F2@drugs.dv.isc.org> In message , Chris Hills writes: > On 11/07/2013 15:27, Jon Mitchell wrote: > > > > After .nyc thread, thought this IAB announcement may be of interest. > > > > http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-st > atement-dotless-domains-considered-harmful/ > > > > -Jon > > > > Whilst I am not a fan of dotless domains, as long as one uses the fully > qualified domain name (e.g. http://ac./), there should not be any > trouble using it in any sane software. It seems that most people aren't > aware these days that a fqdn includes the trailing period (by definition). No it does not. Period at the end is a local convention to stop searching on some platforms. It is not syntactically legal. Note the words 'a sequence of domain labels separated by "."'. Periods at the end are NOT legal. RFC 1738 host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jmamodio at gmail.com Thu Jul 11 22:53:47 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 11 Jul 2013 17:53:47 -0500 Subject: roadrunner takes a really long excursion In-Reply-To: <56FB1679-7063-4A71-875D-8F098EE55FA6@puck.nether.net> References: <56FB1679-7063-4A71-875D-8F098EE55FA6@puck.nether.net> Message-ID: <6A57E394-1D68-42A2-9230-9C9A9636830C@gmail.com> for what is worth twc sucks -J From geoffk at geoffk.org Thu Jul 11 22:57:59 2013 From: geoffk at geoffk.org (Geoffrey Keating) Date: 11 Jul 2013 15:57:59 -0700 Subject: On topic of domains In-Reply-To: <20130711224552.7630137352F2@drugs.dv.isc.org> References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> <20130711224552.7630137352F2@drugs.dv.isc.org> Message-ID: Mark Andrews writes: > In message , Chris Hills writes: > > Whilst I am not a fan of dotless domains, as long as one uses the fully > > qualified domain name (e.g. http://ac./), there should not be any > > trouble using it in any sane software. It seems that most people aren't > > aware these days that a fqdn includes the trailing period (by definition). > > No it does not. Period at the end is a local convention to stop > searching on some platforms. It is not syntactically legal. Note > the words 'a sequence of domain labels separated by "."'. Periods > at the end are NOT legal. > > RFC 1738 > > host > The fully qualified domain name of a network host, or its IP > address as a set of four decimal digit groups separated by > ".". Fully qualified domain names take the form as described > in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 > [5]: a sequence of domain labels separated by ".", each domain > label starting and ending with an alphanumerical character and > possibly also containing "-" characters. The rightmost domain > label will never start with a digit, though, which > syntactically distinguishes all domain names from the IP > addresses. That was fixed in RFC 2396: host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] ... The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single "." if it is necessary to distinguish between the complete domain name and any local domain. However, I think it's safe to say this is an edge case and chances are you'll have trouble using dotless domains with some software and processes. For example, you'll probably have trouble getting a SSL certificate. From bmanning at karoshi.com Thu Jul 11 22:58:48 2013 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Thu, 11 Jul 2013 22:58:48 +0000 Subject: On topic of domains In-Reply-To: <20130711224552.7630137352F2@drugs.dv.isc.org> References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> <20130711224552.7630137352F2@drugs.dv.isc.org> Message-ID: <20130711225848.GA1595@vacation.karoshi.com.> On Fri, Jul 12, 2013 at 08:45:50AM +1000, Mark Andrews wrote: > > In message , Chris Hills writes: > > On 11/07/2013 15:27, Jon Mitchell wrote: > > > > > > After .nyc thread, thought this IAB announcement may be of interest. > > > > > > http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-st > > atement-dotless-domains-considered-harmful/ > > > > > > -Jon > > > > > > > Whilst I am not a fan of dotless domains, as long as one uses the fully > > qualified domain name (e.g. http://ac./), there should not be any > > trouble using it in any sane software. It seems that most people aren't > > aware these days that a fqdn includes the trailing period (by definition). > > No it does not. Period at the end is a local convention to stop > searching on some platforms. It is not syntactically legal. Note > the words 'a sequence of domain labels separated by "."'. Periods > at the end are NOT legal. > > RFC 1738 > > host > The fully qualified domain name of a network host, or its IP > address as a set of four decimal digit groups separated by > ".". Fully qualified domain names take the form as described > in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 > [5]: a sequence of domain labels separated by ".", each domain > label starting and ending with an alphanumerical character and > possibly also containing "-" characters. The rightmost domain > label will never start with a digit, though, which > syntactically distinguishes all domain names from the IP > addresses. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org which explains domains like 3com.net. the trailing dot is not illegal. /bill From dougb at dougbarton.us Thu Jul 11 23:27:58 2013 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 11 Jul 2013 16:27:58 -0700 Subject: On topic of dotless domains In-Reply-To: References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> <20130711224552.7630137352F2@drugs.dv.isc.org> Message-ID: <51DF3F7E.9070407@dougbarton.us> On 07/11/2013 03:57 PM, Geoffrey Keating wrote: > Mark Andrews writes: > >> In message , Chris Hills writes: >>> Whilst I am not a fan of dotless domains, as long as one uses the fully >>> qualified domain name (e.g. http://ac./), there should not be any >>> trouble using it in any sane software. It seems that most people aren't >>> aware these days that a fqdn includes the trailing period (by definition). >> >> No it does not. Period at the end is a local convention to stop >> searching on some platforms. It is not syntactically legal. Note >> the words 'a sequence of domain labels separated by "."'. Periods >> at the end are NOT legal. >> >> RFC 1738 >> >> host >> The fully qualified domain name of a network host, or its IP >> address as a set of four decimal digit groups separated by >> ".". Fully qualified domain names take the form as described >> in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 >> [5]: a sequence of domain labels separated by ".", each domain >> label starting and ending with an alphanumerical character and >> possibly also containing "-" characters. The rightmost domain >> label will never start with a digit, though, which >> syntactically distinguishes all domain names from the IP >> addresses. > > That was fixed in RFC 2396: ... which has the title, "Uniform Resource Identifiers (URI): Generic Syntax," so not necessarily a treatise on host name syntax. :) > host = hostname | IPv4address > hostname = *( domainlabel "." ) toplabel [ "." ] > > ... The rightmost > domain label of a fully qualified domain name will never start with a > digit, thus syntactically distinguishing domain names from IPv4 > addresses, and may be followed by a single "." if it is necessary to > distinguish between the complete domain name and any local domain. > > However, I think it's safe to say this is an edge case and chances are > you'll have trouble using dotless domains with some software and > processes. Right-o. And even if 2396 was authoritative, the "may" in "may be followed" highlights the point Mark made earlier: Such syntax is not universally recognized over all operating systems, or even all applications. And that's totally aside from the difficulty in user education. > For example, you'll probably have trouble getting a SSL > certificate. Given that some CAs have already issued certs for host names that are not valid in the public DNS now, and have been doing so for years, dotless domains may have a higher barrier to entry for SSL, but the barrier is not infinitely high. All that said, I am a proponent of the slightly heretical view that ICANN should not prohibit this for gTLDs, however I do think they should provide good user education as to why it will likely be a bad idea. The key factor for me is that the ccTLDs are already doing it, and there is nothing ICANN can do to stop them from doing so. Thus it would be "unfair" in a philosophical sense for ICANN to restrict the gTLDs in this manner. (I think one could even make an argument that for ICANN to attempt to do so would be restraint of trade, but IANAL.) While I recognize that widespread use of dotless domains would undoubtedly break stuff in the short term, I also think that both application and OS developers would adapt to the changing landscape over time. It's also worth mentioning that at least some of the things that would "break" in the short term are things we've been telling people for many years not to do in the first place ... Doug From shortdudey123 at gmail.com Fri Jul 12 01:03:04 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 11 Jul 2013 18:03:04 -0700 Subject: Google bot contact Message-ID: Can someone that works with the Google Bot contact me off list? I am seeing some really weird access activity for a site I manage. -Grant From shortdudey123 at gmail.com Fri Jul 12 01:11:41 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 11 Jul 2013 18:11:41 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <031d4b9618de489b82490767892bd662@BN1PR08MB124.namprd08.prod.outlook.com> References: <20130711122651.CBC3CA5F@m0005311.ppops.net> <031d4b9618de489b82490767892bd662@BN1PR08MB124.namprd08.prod.outlook.com> Message-ID: I really hope that this doesn't surprise anyone on this list On Thu, Jul 11, 2013 at 2:15 PM, Robert Webb wrote: > Trying my best here to bail. Between this and the fact they are pulling > Technet, along with lots of other little things, I am working my way out. > > Robert > > ________________________________________ > From: Scott Weeks > Sent: Thursday, July 11, 2013 15:26 > To: nanog at nanog.org > Subject: Re: Office 365..? how Microsoft handed the NSA access to > encrypted messages > > --- wbailey at satelliteintelligencegroup.com wrote: > From: Warren Bailey > > Anyone else planning on bailing from office365? > > http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data > ---------------------------------------------------------- > > > Bail on M$ period. If they give the data willingly this > way, I'm sure they also do it in other currently unknown > ways. Company culture and all that... > > scott > > > From mysidia at gmail.com Fri Jul 12 01:23:07 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Jul 2013 20:23:07 -0500 Subject: On topic of domains In-Reply-To: <51df3a0f.a118ec0a.4f84.ffff8e99SMTPIN_ADDED_BROKEN@mx.google.com> References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> <20130711224552.7630137352F2@drugs.dv.isc.org> <51df3a0f.a118ec0a.4f84.ffff8e99SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On 7/11/13, bmanning at karoshi.com wrote: > which explains domains like 3com.net. > the trailing dot is not illegal. Domain names can be presented with a trailing dot. A fully qualified domain always contains at least one explicit dot. The rightmost domain label of 3com.net. is "NET"; which does not start with a digit, so that domain name is OK. Although "3com.net" would not be a valid hostname; as a DNS name, it is fine. > /bill -- -JH From rodrick.brown at gmail.com Fri Jul 12 01:27:39 2013 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Thu, 11 Jul 2013 21:27:39 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: Message-ID: <-7573758388908123780@unknownmsgid> ::::: off topic rant ::::: Just assume no data you store and or traverses any public cloud service is private or secure this is just silly. I can't believe people are so naive to believe messages sent over the public Internet isn't intercepted stored and analyzed by the same government bodies who gave it to us in the first place. I've always heard rumors as a kid that the NSA had systems long in place that could record all voice calls based on certain key phrases ever since the Nixon era so please tell me why are most people shocked with all the spying by governments? Sent from my iPhone On Jul 11, 2013, at 2:39 PM, Warren Bailey wrote: > Anyone else planning on bailing from office365? > > > http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data > > > > Sent from my Mobile Device. From shortdudey123 at gmail.com Fri Jul 12 01:40:12 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 11 Jul 2013 18:40:12 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <-7573758388908123780@unknownmsgid> References: <-7573758388908123780@unknownmsgid> Message-ID: I 2nd Rodrick's statement of "so please tell me why are most people shocked with all the spying by governments?". All this leak does is confirm what most people already suspected or assumed. -Grant On Thu, Jul 11, 2013 at 6:27 PM, Rodrick Brown wrote: > ::::: off topic rant ::::: > > Just assume no data you store and or traverses any public cloud > service is private or secure this is just silly. > > I can't believe people are so naive to believe messages sent over the > public Internet isn't intercepted stored and analyzed by the same > government bodies who gave it to us in the first place. > > I've always heard rumors as a kid that the NSA had systems long in > place that could record all voice calls based on certain key phrases > ever since the Nixon era so please tell me why are most people shocked > with all the spying by governments? > > Sent from my iPhone > > On Jul 11, 2013, at 2:39 PM, Warren Bailey > wrote: > > > Anyone else planning on bailing from office365? > > > > > > > http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data > > > > > > > > Sent from my Mobile Device. > > From LarrySheldon at cox.net Fri Jul 12 01:47:06 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 11 Jul 2013 20:47:06 -0500 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: References: Message-ID: <51DF601A.90200@cox.net> On 7/11/2013 10:32 AM, Clayton Zekelman wrote: > > It all depends on the air speed velocity of an unladen swallow, and > varies if it is African or Eurpoean. > > In all seriousness, you need to know the speed and latency of the link > before that question can be answered. > > At 10:04 AM 11/07/2013, Luan Nguyen wrote: >> Hello folks, >> >> Does anyone know what's the average speed for windows file transferring >> (SMB2) between Hong Kong and Johannesburg? >> Any guide on how to calculate/estimate this? An old-timers-uncalibrated-guess" If you are going to do large transfers using a protocol designed (for want of a term) for local area networks with near-fault free performance over a long multihop network, you are not going to like it. What criteria drive the selection of such an unlikely protocol? -- 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 rwebb at ropeguru.com Fri Jul 12 01:48:32 2013 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 12 Jul 2013 01:48:32 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <-7573758388908123780@unknownmsgid> References: , <-7573758388908123780@unknownmsgid> Message-ID: <917ed76ad74d4f61844492fd2182082e@BN1PR08MB124.namprd08.prod.outlook.com> Certainly NOT shocked. Just get more and more appalled as to how cooperative some of these companies have become just for the profit margin. At least there are some that try and take a stand for their customer and not just hand over the keys to the palace when the good ole boys ask. Robert ________________________________________ From: Rodrick Brown Sent: Thursday, July 11, 2013 21:27 To: Warren Bailey Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages ::::: off topic rant ::::: Just assume no data you store and or traverses any public cloud service is private or secure this is just silly. I can't believe people are so naive to believe messages sent over the public Internet isn't intercepted stored and analyzed by the same government bodies who gave it to us in the first place. I've always heard rumors as a kid that the NSA had systems long in place that could record all voice calls based on certain key phrases ever since the Nixon era so please tell me why are most people shocked with all the spying by governments? Sent from my iPhone On Jul 11, 2013, at 2:39 PM, Warren Bailey wrote: > Anyone else planning on bailing from office365? > > > http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data > > > > Sent from my Mobile Device. From LarrySheldon at cox.net Fri Jul 12 01:53:53 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 11 Jul 2013 20:53:53 -0500 Subject: On topic of domains In-Reply-To: References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> Message-ID: <51DF61B1.6080801@cox.net> On 7/11/2013 11:41 AM, Andrew Sullivan wrote: > If the definition of "FQDN" in some RFCs (Informational or not) > always included the trailing dot, I'd be inclined to agree with you. > But that's not the case, so protocol slots have been established for > "FQDNs" that are actually domains qualified relative to the root. > Since this ambiguity has been around since the very dawn of the DNS, > I suspect there is little chance of re-educating everyone in the > world about this. I seem to recall back in the day being annoyed that some interfaces would not allow the trailing dot. My failing memory does not provide and example. (A test of Firefox and a URL I had just used, modified works. en.wikipedia.org./wiki/Server_Message_Block #) > > A > > > On Thu, Jul 11, 2013 at 11:54 AM, Chris Hills > wrote: > >> On 11/07/2013 15:27, Jon Mitchell wrote: >>> >>> After .nyc thread, thought this IAB announcement may be of >>> interest. >>> >>> >> http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ >>> >>> >> -Jon >>> >> >> Whilst I am not a fan of dotless domains, as long as one uses the >> fully qualified domain name (e.g. http://ac./), there should not be >> any trouble using it in any sane software. It seems that most >> people aren't aware these days that a fqdn includes the trailing >> period (by definition). >> >> >> > -- 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 surfer at mauigateway.com Fri Jul 12 02:02:33 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 11 Jul 2013 19:02:33 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages Message-ID: <20130711190233.CBC3EDFD@m0005311.ppops.net> --- rwebb at ropeguru.com wrote: From: Robert Webb At least there are some that try and take a stand for their customer and not just hand over the keys to the palace when the good ole boys ask. ----------------------- Like web search engine startpage.com scott From mysidia at gmail.com Fri Jul 12 03:21:37 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Jul 2013 22:21:37 -0500 Subject: gTLDs opened up In-Reply-To: References: <51DF14FA.2080505@supermathie.net> Message-ID: On 7/11/13, Alex Buie wrote: Wow... that's pretty exciting; long has the internet been plagued by the scourge of global DNS name uniqueness. The 10,000 fee to register in all zones, practically guarantees, that for some TLDs, you could take advantage of the fact that the company only registered in one zone -- in order to piggyback on their good name in other regions, to display pages dedicated to advertising in those regions, for the 2 or 3 people in that region using a DNS resolver that consults their root. Now they just need to work on overcoming the fact that their root would nonetheless be inaccessible to fewer than 0.01bps of internet users' DNS resolvers. > They apparently have different "zones" (ie, they run 5 different, separate > roots), and you pay a different price depending on how many "zones" you > want your TLD to be active in. (cf > http://www.open-root.eu/our-rates/list-of-zones-and-pricing/) > -- -JH From mpetach at netflight.com Fri Jul 12 04:07:09 2013 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 11 Jul 2013 21:07:09 -0700 Subject: gTLDs opened up In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 1:49 PM, Christopher Morrow wrote: > On Thu, Jul 11, 2013 at 4:08 PM, Alex Buie > wrote: > > Am I missing something, or is that purporting to be an IPv4 address > > beginning with 478? > > > > > http://www.open-root.eu/about-open-root/how-to-install-an-open-root-website-69/ > > you clearly are being limited by your bias to binary maths. > > > http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-10 > > I hate you, Chris. My brain just ran and hid under a rock, and won't come back out anymore. :P Matt From pfsinoz at gmail.com Fri Jul 12 05:59:57 2013 From: pfsinoz at gmail.com (Philip Smith) Date: Fri, 12 Jul 2013 15:59:57 +1000 Subject: Call for presentations: APNIC 36, Xi'an Message-ID: <51DF9B5D.7000506@gmail.com> Hi everyone, If any of you are starting to plan your late August travel, please think about joining us at the APNIC 36 Conference, being held in Xi'an, China (home of the Terracotta Warriors). The Programme Committee would like your help. We are still on the look out for presentations and tutorial proposals of technical/operational relevance, with the technical sessions running from Monday 26th through to Thursday 29th August. The first round of paper acceptances closes at the end of today, and submissions received between tomorrow and 12th August will be reviewed on a first come first served basis. Please submit your proposal now to avoid disappointment: http://conference.apnic.net/36/program. And if you are planning to come to Xi'an, once you have submitted your presentation proposal, please register for the conference (http://conference.apnic.net/36/register) and book your hotel room now (http://conference.apnic.net/36/travel) - late August is busy holiday season and there are not many hotel rooms left! Thanks! Philip Smith/Mark Tinka/Dean Pemberton For the APNIC 36 PC -- From koalafil at gmail.com Fri Jul 12 09:23:26 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Fri, 12 Jul 2013 11:23:26 +0200 Subject: Updated CFP for RIPE 67 Message-ID: Dear colleagues, RIPE PC is now also accepting "Workshop" proposals for RIPE 67. Please find the updated CFP with pointers to all possible presentation formats below and at: https://ripe67.ripe.net/programme/cfp/ Note that the deadline for submissions is still 4 August 2013. Kind regards Filiz Yilmaz Chair, RIPE Programme Committee 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 67 will take place from 14-18 October 2013 in Athens, Greece. 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 67. 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://ripe67.ripe.net/programme/i-want-to-present/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 4 August 2013, using the meeting submission system (https://ripe67.ripe.net/submit-topic/). 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://ripe67.ripe.net/submit-topic/) 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 (https://ripe67.ripe.net/programme/i-want-to-present/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 wbailey at satelliteintelligencegroup.com Fri Jul 12 09:26:32 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 12 Jul 2013 09:26:32 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <-7573758388908123780@unknownmsgid> References: , <-7573758388908123780@unknownmsgid> Message-ID: It's not a shock. What is shocking, is the blatant disregard for general privacy. Because it exists on a medium other than something I own, it does not somehow become property of another. If this isn't a big deal, I imagine a search of your home isn't an issue either? The point is, these companies have the power (they, after all, pay for elections) to tell these people.. It's not your call. You cannot simply say we are collecting everything, to avert an attack. The Boston guys were both from out of the country, with foreign names, and foreign governments had warned us before. How effective is a machine that scans data for terrorist machines, if a FLAGGED person can still cause us harm? This jihad against America has accomplished one thing, we are going broke trying to fend off an invisible enemy. A kid from Nigeria hopped on a plane with a bomb in his shorts and MADE IT TO AMERICAN SOIL. If I am giving up privacy, I expect a tangible return. A couple of bedroom bombers slipping through the cracks and killing people is not a tangible return, in my opinion. The NSA needs to be spying on OTHER people, we are apparently innocent until proven guilty.. Ymmv Sent from my Mobile Device. -------- Original message -------- From: Rodrick Brown Date: 07/11/2013 6:27 PM (GMT-08:00) To: Warren Bailey Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages ::::: off topic rant ::::: Just assume no data you store and or traverses any public cloud service is private or secure this is just silly. I can't believe people are so naive to believe messages sent over the public Internet isn't intercepted stored and analyzed by the same government bodies who gave it to us in the first place. I've always heard rumors as a kid that the NSA had systems long in place that could record all voice calls based on certain key phrases ever since the Nixon era so please tell me why are most people shocked with all the spying by governments? Sent from my iPhone On Jul 11, 2013, at 2:39 PM, Warren Bailey wrote: > Anyone else planning on bailing from office365? > > > http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data > > > > Sent from my Mobile Device. From cdel at firsthand.net Fri Jul 12 09:27:10 2013 From: cdel at firsthand.net (Christian de Larrinaga) Date: Fri, 12 Jul 2013 10:27:10 +0100 Subject: gTLDs opened up In-Reply-To: References: <51DF14FA.2080505@supermathie.net> Message-ID: <51DFCBEE.5020308@firsthand.net> hilarious! Now we know that open really means ... closed. C Alex Buie wrote: > They apparently have different "zones" (ie, they run 5 different, separate > roots), and you pay a different price depending on how many "zones" you > want your TLD to be active in. (cf > http://www.open-root.eu/our-rates/list-of-zones-and-pricing/) > > > On Thu, Jul 11, 2013 at 1:26 PM, Michael Brown wrote: > >> On 13-07-11 04:08 PM, Alex Buie wrote: >> >> Am I missing something, or is that purporting to be an IPv4 address >> beginning with 478? >> >> Heh? it seems as though they mistyped '*78.47.115.194*' there. >> >>> 7 - How to distinguish between identical TLDs? >>> Within the Icann framework, names such as: tube.com, tube.net, tube.org, >> etc. allow in principle to differentiate different domains under the same >> name. >> >>> Within the open root framework, if there are several .tube, one will >> distinguish them according to the root being activated. >> Wait? so 'open root' isn't a single alternative root namespace? It's >> different depending on? near as I can tell which part of the planet you're >> in? >> >> Or is the product multiple independent roots? are you buying your own '.' >> tree or a 'tld.' tree? >> >> Clearly, this will work? >> >> Is this the future? "Visit my site at >> http://fluttershy.turgid.wonka.^78.47.115.194/index.go" >> >> -- >> Michael Brown | The true sysadmin does not adjust his behaviour >> Systems Administrator | to fit the machine. He adjusts the machinemichael at supermathie.net | until it behaves properly. With a hammer, >> | if necessary. - Brian >> >> From oscar.vives at gmail.com Fri Jul 12 10:46:21 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Fri, 12 Jul 2013 12:46:21 +0200 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> Message-ID: Whos doing the spyiing, anyway?, sounds like a colaboration betwen Microsoft and the NSA. Sounds to me like Microsoft, and the NSA,are doing the spyiing. If some judge declare this actions illegal, a crime, Microsoft will be co-perpetrators. Even if no judge declare this a crime, what about the customer position? a) Microsoft lied to you. b) Microsoft conspired with others to break your privacy. c) They did more than the law forced them, to break your privacy. d) You are the product that Microsoft sells to the NSA. Somebody, somewhere on the USA governement, trought that after the 9/11, normal laws not-apply, including the constitution. New laws where made to give free reign, and people like Microsoft happyly jumped to make some money out of it. This is wrong. -- -- ?in del ?ensaje. From asullivan at dyn.com Fri Jul 12 11:20:49 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 12 Jul 2013 07:20:49 -0400 Subject: On topic of domains In-Reply-To: References: <28B031FD-6F5A-4813-8EE4-8D29F77DE4A8@puck.nether.net> <20130711224552.7630137352F2@drugs.dv.isc.org> <51df3a0f.a118ec0a.4f84.ffff8e99SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Thu, Jul 11, 2013 at 9:23 PM, Jimmy Hess wrote: > > Domain names can be presented with a trailing dot. A fully > qualified domain always contains at least one explicit dot. > But not always at the end, which is why there's a problem. RFC1123, in my opinion, contains a remark that ought to indicate to people that the trailing dot convention isn't even universal for determining whether a name is really fully-qualified. (See section 6.1.4.3. That RFC is also, of course, how we got 3com.net as a legal name, for prior to 1123 "3com" wasn't a valid label anywhere.) Best, A From freimer at freimer.org Fri Jul 12 14:59:05 2013 From: freimer at freimer.org (Fred Reimer) Date: Fri, 12 Jul 2013 14:59:05 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <-7573758388908123780@unknownmsgid> Message-ID: The US federal government may have funded some initial research into the Internet, but they certainly didn't "[give] it to us in the first place." I know it was probably not the intention, but the phrasing of that statement implies that we are using a government provided communications infrastructure, and as a result we should expect the government to intercept, store, and analyze any information sent over "their" network. Other than that, I completely agree with your statement; it should be a shock to no one that the US federal government is attempting to intercept, store, and analyze as much information from as many sources as possible. As other stated, the somewhat shocking news is that companies have been blatantly lying to the public as to their involvement in this activity. If they are barred from discussing it publicly by applicable laws, which may be unconstitutional and which they refuse the fight in court, then at a minimum they could have said something to the effect of "no comment." Again, this is only somewhat shocking, because I believe everyone expected they were lying, but to see them try and cover up now is both somewhat comical and disappointing. Fred Reimer On 7/11/13 9:27 PM, "Rodrick Brown" wrote: >::::: off topic rant ::::: > >Just assume no data you store and or traverses any public cloud >service is private or secure this is just silly. > >I can't believe people are so naive to believe messages sent over the >public Internet isn't intercepted stored and analyzed by the same >government bodies who gave it to us in the first place. > >I've always heard rumors as a kid that the NSA had systems long in >place that could record all voice calls based on certain key phrases >ever since the Nixon era so please tell me why are most people shocked >with all the spying by governments? > >Sent from my iPhone > >On Jul 11, 2013, at 2:39 PM, Warren Bailey > wrote: > >> Anyone else planning on bailing from office365? >> >> >> >>http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-use >>r-data >> >> >> >> Sent from my Mobile Device. > From Valdis.Kletnieks at vt.edu Fri Jul 12 15:00:08 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 12 Jul 2013 11:00:08 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: Your message of "Fri, 12 Jul 2013 09:26:32 -0000." References: , <-7573758388908123780@unknownmsgid> Message-ID: <47822.1373641208@turing-police.cc.vt.edu> On Fri, 12 Jul 2013 09:26:32 -0000, Warren Bailey said: > The NSA needs to be spying on OTHER people, we are apparently innocent until > proven guilty.. Ymmv Be careful what you wish for - bad things happen when there's an organizational push to find somebody who's guilty of something, when there's not enough actual somebodys to be found... http://www.alternet.org/civil-liberties/fbis-terror-scam I have to agree - if the FBI has to supply both the explosive device and the idea for the target, there probably wasn't much actual threat there. But they need to show some "results" to justify their $3B anti-terrorism budget... I'll shut up now... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ahebert at pubnix.net Fri Jul 12 15:44:56 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 12 Jul 2013 11:44:56 -0400 Subject: Friday Hosing In-Reply-To: <518D00CD.5070906@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> Message-ID: <51E02478.30409@pubnix.net> Is it me or the bigger a corporation gets the more vindictive (a b-word intended) they are to customers leaving them? ------ One of my *new* customer was caught by the local "monopole" into moving their domain/site/emails/phone/oxygen supply/etc to them. But when the usual grace period stopped and they started receiving invoices that would make a loan shark go: "are you insane?!?", they decided to move. After a somewhat pleasant call to the "monopole" informing them that they are planning to divorce them in 30 days, and that it was clearly stated that since they are paying for those additional 30 days that their services wont be cut off... 15 minutes later. Boom. No domain, no site, no emails... After a rather stern call, they get their domain up, no site... After another rather stern call, they get their site up, no emails... After another rather stern call, they get... no emails. "Oh its 17:01, our support is closed for day. Is there anything else I can help you with?" On top of it that "monopole" has for their procedure to let the 5 days "AUTO-ACK" expire when they are asked to transfer a domain away from them. ( They are a reseller of tucows, and PS: it is not Tucows fault. That 5 days 'AUTO-ACK" process is there because of corporation acting like that "monopole" ) Good thing I was able to get back into their account earlier this morning and recreate their emails... Now lets hope they don't do this again until my customer get his domain back in its hands. ----- 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 EWieling at nyigc.com Fri Jul 12 15:56:01 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 12 Jul 2013 11:56:01 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> Message-ID: <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> Suspecting your spouse of cheating is much different than coming home and finding them in bed with someone. -----Original Message----- From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Thursday, July 11, 2013 9:40 PM To: Rodrick Brown Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages I 2nd Rodrick's statement of "so please tell me why are most people shocked with all the spying by governments?". All this leak does is confirm what most people already suspected or assumed. -Grant On Thu, Jul 11, 2013 at 6:27 PM, Rodrick Brown wrote: > ::::: off topic rant ::::: > > Just assume no data you store and or traverses any public cloud > service is private or secure this is just silly. > > I can't believe people are so naive to believe messages sent over the > public Internet isn't intercepted stored and analyzed by the same > government bodies who gave it to us in the first place. > > I've always heard rumors as a kid that the NSA had systems long in > place that could record all voice calls based on certain key phrases > ever since the Nixon era so please tell me why are most people shocked > with all the spying by governments? > > Sent from my iPhone > > On Jul 11, 2013, at 2:39 PM, Warren Bailey > wrote: > > > Anyone else planning on bailing from office365? > > > > > > > http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration- > user-data > > > > > > > > Sent from my Mobile Device. > > From JFaraone at paulo.com Fri Jul 12 16:04:56 2013 From: JFaraone at paulo.com (Jason Faraone) Date: Fri, 12 Jul 2013 16:04:56 +0000 Subject: Friday Hosing In-Reply-To: <51E02478.30409@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> Message-ID: The biggest grievance I have is in regards to carriers with automatic contract renewals. Combined with the fact that these carriers either refused to allow month to month billing or will allow it at double / triple current rates, coordinating disconnection of older services while turning up new services with a different carrier in the same time frame can be a real challenge. Adding insult to injury is the fact that one does not simply resolve carrier billing issues - I've had multiple incidents which took almost a year to resolve. I personally think that the automatic renewal of a three year term should be criminal. The same goes for price increases while I'm under a contract rate - Apparently as long as there is a provision in the small print (which is able to be changed at will, due to the small print referencing a document on the carrier's website), be ready to pay more whenever the carrier dictates, regardless of what your contract says. Typing this was somewhat therapeutic. -----Original Message----- From: Alain Hebert [mailto:ahebert at pubnix.net] Sent: Friday, July 12, 2013 10:45 AM To: nanog at nanog.org Subject: Friday Hosing Is it me or the bigger a corporation gets the more vindictive (a b-word intended) they are to customers leaving them? ------ One of my *new* customer was caught by the local "monopole" into moving their domain/site/emails/phone/oxygen supply/etc to them. But when the usual grace period stopped and they started receiving invoices that would make a loan shark go: "are you insane?!?", they decided to move. After a somewhat pleasant call to the "monopole" informing them that they are planning to divorce them in 30 days, and that it was clearly stated that since they are paying for those additional 30 days that their services wont be cut off... 15 minutes later. Boom. No domain, no site, no emails... After a rather stern call, they get their domain up, no site... After another rather stern call, they get their site up, no emails... After another rather stern call, they get... no emails. "Oh its 17:01, our support is closed for day. Is there anything else I can help you with?" On top of it that "monopole" has for their procedure to let the 5 days "AUTO-ACK" expire when they are asked to transfer a domain away from them. ( They are a reseller of tucows, and PS: it is not Tucows fault. That 5 days 'AUTO-ACK" process is there because of corporation acting like that "monopole" ) Good thing I was able to get back into their account earlier this morning and recreate their emails... Now lets hope they don't do this again until my customer get his domain back in its hands. ----- 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 jra at baylink.com Fri Jul 12 16:38:59 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 12 Jul 2013 12:38:59 -0400 (EDT) Subject: Friday Hosing In-Reply-To: <51E02478.30409@pubnix.net> Message-ID: <24457595.1286.1373647139787.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Alain Hebert" > Is it me or the bigger a corporation gets the more vindictive (a > b-word intended) they are to customers leaving them? [ long saga elided ] And now you know why it's standard operating procedure: *Never* tell the losing service provider they're losing *until you've actually done the cutover*. If that costs you some money, well, at least you didn't go off the air. Responsibility for you not going off the air rests, finally, with you. Your clients don't care if you later win the lawsuit. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From shortdudey123 at gmail.com Fri Jul 12 17:04:25 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 12 Jul 2013 10:04:25 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> Message-ID: <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Touch? Sent from my iPhone On Jul 12, 2013, at 8:56 AM, Eric Wieling wrote: > Suspecting your spouse of cheating is much different than coming home and finding them in bed with someone. > > -----Original Message----- > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > Sent: Thursday, July 11, 2013 9:40 PM > To: Rodrick Brown > Cc: nanog at nanog.org > Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages > > I 2nd Rodrick's statement of "so please tell me why are most people shocked with all the spying by governments?". All this leak does is confirm what most people already suspected or assumed. > > -Grant > > On Thu, Jul 11, 2013 at 6:27 PM, Rodrick Brown wrote: > >> ::::: off topic rant ::::: >> >> Just assume no data you store and or traverses any public cloud >> service is private or secure this is just silly. >> >> I can't believe people are so naive to believe messages sent over the >> public Internet isn't intercepted stored and analyzed by the same >> government bodies who gave it to us in the first place. >> >> I've always heard rumors as a kid that the NSA had systems long in >> place that could record all voice calls based on certain key phrases >> ever since the Nixon era so please tell me why are most people shocked >> with all the spying by governments? >> >> Sent from my iPhone >> >> On Jul 11, 2013, at 2:39 PM, Warren Bailey >> wrote: >> >>> Anyone else planning on bailing from office365? >>> >>> >>> >> http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration- >> user-data >>> >>> >>> >>> Sent from my Mobile Device. >> >> From nanog at namor.ca Fri Jul 12 17:25:33 2013 From: nanog at namor.ca (nanog at namor.ca) Date: Fri, 12 Jul 2013 12:25:33 -0500 (CDT) Subject: Friday Hosing In-Reply-To: <51E02478.30409@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> Message-ID: On Fri, 12 Jul 2013, Alain Hebert wrote: > Is it me or the bigger a corporation gets the more vindictive (a b-word > intended) they are to customers leaving them? "Never attribute to malice that which is adequately explained by stupidity." Hopefully this isn't one of mine, but I've seen this happen in our billing/sales, regardless. From patrick at ianai.net Fri Jul 12 17:39:52 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 12 Jul 2013 13:39:52 -0400 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> Message-ID: <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> Composed on a virtual keyboard, please forgive typos. On Jul 12, 2013, at 13:25, nanog at namor.ca wrote: > On Fri, 12 Jul 2013, Alain Hebert wrote: > >> Is it me or the bigger a corporation gets the more vindictive (a b-word >> intended) they are to customers leaving them? > > "Never attribute to malice that which is adequately explained by stupidity." I prefer Heinlein's version: Never attribute to malice that which can be adequately explained by stupidity, but don't rule out malice. And, of course the corollary that any sufficiently advanced stupidity is indistinguishable from malice. Put another way, whether it was stupid or evil, the results are the same. Turning off a customer in good standing is actionable in court, and should be avoided by legitimate businesses at nearly all costs. Not correcting the error (should it happen) when notified goes from "oops" to evil, whether intentional or not. And yes, I've probably worked for a corporation that has done this at least once over the years. (I did work for a telco for a while. :-) Doesn't mean I can't think it was evil of "us" and work to stop it from ever happening again. -- TTFN, patrick From Bryan at bryanfields.net Fri Jul 12 17:44:30 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 12 Jul 2013 13:44:30 -0400 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> Message-ID: <51E0407E.9050207@bryanfields.net> On 7/12/13 1:39 PM, Patrick W. Gilmore wrote: > Put another way, whether it was stupid or evil, the results are the same. Turning off a customer in good standing is actionable in court, and should be avoided by legitimate businesses at nearly all costs. You can void a contract at any time so long as you're willing to accept the result. I've seen people have their service cut off and a carrier keep their equipment. Sure they will get it back, but is it worth spending 100k fighting them in court for three years? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From patrick at ianai.net Fri Jul 12 17:54:05 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 12 Jul 2013 13:54:05 -0400 Subject: Friday Hosing In-Reply-To: <51E0407E.9050207@bryanfields.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> Message-ID: <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> On Jul 12, 2013, at 13:44 , Bryan Fields wrote: > On 7/12/13 1:39 PM, Patrick W. Gilmore wrote: >> Put another way, whether it was stupid or evil, the results are the same. Turning off a customer in good standing is actionable in court, and should be avoided by legitimate businesses at nearly all costs. > You can void a contract at any time so long as you're willing to accept the > result. Hence the "actionable in court" phrase. > I've seen people have their service cut off and a carrier keep their > equipment. Sure they will get it back, but is it worth spending 100k fighting > them in court for three years? Every business makes tough decisions. For instance, judging the risk/reward ratio of getting, for instance, loss of use fees, legal fees, etc., out of an opponent in a court case. Either way, I'm interested in hearing when a company does these bad things so I can add that into the decision when considering that company. (To be clear, one person saying "they cut me off without warning" does not automatically mean I would never do business with a company. There's always another side. But I still like to collect the info when possible.) In this case, the OP didn't mention which company it was, other than "monopole". -- TTFN, patrick From blueneon at gmail.com Fri Jul 12 18:01:29 2013 From: blueneon at gmail.com (Tom Morris) Date: Fri, 12 Jul 2013 14:01:29 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: We use Office 365 here at work, but I'd definitely be interested in looking into alternate solutions --- at the very least I am going to be sure to inform our staff that there is to be no expectation of privacy when using your Office365 account. Gross. On Fri, Jul 12, 2013 at 1:04 PM, Grant Ridder wrote: > Touch? > > Sent from my iPhone > > On Jul 12, 2013, at 8:56 AM, Eric Wieling wrote: > > > Suspecting your spouse of cheating is much different than coming home > and finding them in bed with someone. > > > > -----Original Message----- > > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > > Sent: Thursday, July 11, 2013 9:40 PM > > To: Rodrick Brown > > Cc: nanog at nanog.org > > Subject: Re: Office 365..? how Microsoft handed the NSA access to > encrypted messages > > > > I 2nd Rodrick's statement of "so please tell me why are most people > shocked with all the spying by governments?". All this leak does is > confirm what most people already suspected or assumed. > > > > -Grant > > > > On Thu, Jul 11, 2013 at 6:27 PM, Rodrick Brown >wrote: > > > >> ::::: off topic rant ::::: > >> > >> Just assume no data you store and or traverses any public cloud > >> service is private or secure this is just silly. > >> > >> I can't believe people are so naive to believe messages sent over the > >> public Internet isn't intercepted stored and analyzed by the same > >> government bodies who gave it to us in the first place. > >> > >> I've always heard rumors as a kid that the NSA had systems long in > >> place that could record all voice calls based on certain key phrases > >> ever since the Nixon era so please tell me why are most people shocked > >> with all the spying by governments? > >> > >> Sent from my iPhone > >> > >> On Jul 11, 2013, at 2:39 PM, Warren Bailey > >> wrote: > >> > >>> Anyone else planning on bailing from office365? > >>> > >>> > >>> > >> http://m.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration- > >> user-data > >>> > >>> > >>> > >>> Sent from my Mobile Device. > >> > >> > > -- -- Tom Morris, KG4CYX Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz! Engineer, WRGP Radiate FM, Florida International University 786-228-7087 151.820 Megacycles From jfmezei_nanog at vaxination.ca Fri Jul 12 18:17:24 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 12 Jul 2013 14:17:24 -0400 Subject: Friday Hosing In-Reply-To: <51E02478.30409@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> Message-ID: <51E04834.50508@vaxination.ca> On 13-07-12 11:44, Alain Hebert wrote: > After a somewhat pleasant call to the "monopole" informing them that > they are planning to divorce them in 30 days, and that it was clearly > stated that since they are paying for those additional 30 days that > their services wont be cut off... 1- You call to make cancellation on date X. Speak to person 1. 2- Wait 20 minutes 3- Call again, speak to person 2, confirm your services will be cancelled on date X and that you have already paid for services until then. (or that an invoice has already been produced or will be produced.) I am not one to defend the big bad incumbents. But consider you are calling on the day before new billing cycle begins. The agent may have flagged your account to to close at end of current billing cycle thinking it would be about a month from now. But it happens to be only a few hours from now. You should also note that big bad incumbents have bad reputation of requiring one extra month payment before they allow you to leave them. So the agent may have been nice in waiving that requirement and allowed you to leave earlier, saving you a month's worth of billing. (and not realising the troubles it will cause a business when service is cut before the date specified by customer) From cscora at apnic.net Fri Jul 12 18:33:32 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Jul 2013 04:33:32 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201307121833.r6CIXW8a007798@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 13 Jul, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 458665 Prefixes after maximum aggregation: 186702 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 227996 Total ASes present in the Internet Routing Table: 44488 Prefixes per ASN: 10.31 Origin-only ASes present in the Internet Routing Table: 34829 Origin ASes announcing only one prefix: 16175 Transit ASes present in the Internet Routing Table: 5881 Transit-only ASes present in the Internet Routing Table: 149 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 2692 Unregistered ASNs in the Routing Table: 1140 Number of 32-bit ASNs allocated by the RIRs: 4870 Number of 32-bit ASNs visible in the Routing Table: 3778 Prefixes from 32-bit ASNs in the Routing Table: 11268 Special use prefixes present in the Routing Table: 27 Prefixes being announced from unallocated address space: 293 Number of addresses announced to Internet: 2628759084 Equivalent to 156 /8s, 175 /16s and 174 /24s Percentage of available address space announced: 71.0 Percentage of allocated address space announced: 71.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.7 Total number of prefixes smaller than registry allocations: 160376 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110093 Total APNIC prefixes after maximum aggregation: 33771 APNIC Deaggregation factor: 3.26 Prefixes being announced from the APNIC address blocks: 112014 Unique aggregates announced from the APNIC address blocks: 46055 APNIC Region origin ASes present in the Internet Routing Table: 4849 APNIC Prefixes per ASN: 23.10 APNIC Region origin ASes announcing only one prefix: 1214 APNIC Region transit ASes present in the Internet Routing Table: 826 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 601 Number of APNIC addresses announced to Internet: 725913568 Equivalent to 43 /8s, 68 /16s and 143 /24s Percentage of available APNIC address space announced: 84.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159152 Total ARIN prefixes after maximum aggregation: 80574 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 159683 Unique aggregates announced from the ARIN address blocks: 73949 ARIN Region origin ASes present in the Internet Routing Table: 15772 ARIN Prefixes per ASN: 10.12 ARIN Region origin ASes announcing only one prefix: 5995 ARIN Region transit ASes present in the Internet Routing Table: 1641 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1066464064 Equivalent to 63 /8s, 144 /16s and 243 /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: 118497 Total RIPE prefixes after maximum aggregation: 60385 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 121981 Unique aggregates announced from the RIPE address blocks: 78813 RIPE Region origin ASes present in the Internet Routing Table: 17289 RIPE Prefixes per ASN: 7.06 RIPE Region origin ASes announcing only one prefix: 8199 RIPE Region transit ASes present in the Internet Routing Table: 2831 Average RIPE Region AS path length visible: 5.2 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2376 Number of RIPE addresses announced to Internet: 656325988 Equivalent to 39 /8s, 30 /16s and 189 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 48671 Total LACNIC prefixes after maximum aggregation: 9411 LACNIC Deaggregation factor: 5.17 Prefixes being announced from the LACNIC address blocks: 53175 Unique aggregates announced from the LACNIC address blocks: 24939 LACNIC Region origin ASes present in the Internet Routing Table: 1977 LACNIC Prefixes per ASN: 26.90 LACNIC Region origin ASes announcing only one prefix: 579 LACNIC Region transit ASes present in the Internet Routing Table: 362 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 776 Number of LACNIC addresses announced to Internet: 133326248 Equivalent to 7 /8s, 242 /16s and 101 /24s Percentage of available LACNIC address space announced: 79.5 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: 10896 Total AfriNIC prefixes after maximum aggregation: 2521 AfriNIC Deaggregation factor: 4.32 Prefixes being announced from the AfriNIC address blocks: 11519 Unique aggregates announced from the AfriNIC address blocks: 3974 AfriNIC Region origin ASes present in the Internet Routing Table: 647 AfriNIC Prefixes per ASN: 17.80 AfriNIC Region origin ASes announcing only one prefix: 188 AfriNIC Region transit ASes present in the Internet Routing Table: 132 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46329600 Equivalent to 2 /8s, 194 /16s and 239 /24s Percentage of available AfriNIC address space announced: 46.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 2930 11560 919 Korea Telecom (KIX) 17974 2580 855 92 PT TELEKOMUNIKASI INDONESIA 7545 2024 320 108 TPG Internet Pty Ltd 4755 1755 391 193 TATA Communications formerly 9829 1531 1220 44 BSNL National Internet Backbo 9583 1463 118 564 Sify Limited 4808 1172 2151 340 CNCGROUP IP network: China169 7552 1159 1080 13 Vietel Corporation 9498 1159 309 71 BHARTI Airtel Ltd. 24560 1085 394 164 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 2988 3691 69 bellsouth.net, inc. 18566 2066 382 184 Covad Communications 1785 1999 678 126 PaeTec Communications, Inc. 22773 1992 2927 123 Cox Communications, Inc. 20115 1663 1617 616 Charter Communications 4323 1613 1134 403 Time Warner Telecom 701 1531 11127 798 UUNET Technologies, Inc. 30036 1351 304 657 Mediacom Communications Corp 7018 1298 11034 820 AT&T WorldNet Services 11492 1224 218 360 Cable One 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 1607 544 16 Corbina telecom 34984 1294 244 222 BILISIM TELEKOM 2118 1271 97 13 EUnet/RELCOM Autonomous Syste 20940 907 313 720 Akamai Technologies European 13188 837 98 81 Educational Network 31148 801 40 25 FreeNet ISP 6830 786 2376 441 UPC Distribution Services 8551 782 370 45 Bezeq International 12479 679 789 57 Uni2 Autonomous System 34744 648 160 85 SC GVM SISTEM 2003 SRL 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 2902 1586 111 NET Servicos de Comunicao S.A 10620 2685 421 202 TVCABLE BOGOTA 7303 1732 1155 221 Telecom Argentina Stet-France 8151 1269 2747 384 UniNet S.A. de C.V. 18881 1119 844 20 Global Village Telecom 27947 829 94 91 Telconet S.A 6503 819 434 63 AVANTEL, S.A. 3816 718 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 619 88 65 Servicios Alestra S.A de C.V 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 1172 80 4 MOBITEL 24863 883 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 453 956 9 TEDATA 24835 345 80 8 RAYA Telecom - Egypt 3741 259 922 218 The Internet Solution 15706 220 32 6 Sudatel Internet Exchange Aut 29571 219 17 12 Ci Telecom Autonomous system 36992 205 527 22 Etisalat MISR 12258 194 28 67 Vodacom Internet Company 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 6389 2988 3691 69 bellsouth.net, inc. 4766 2930 11560 919 Korea Telecom (KIX) 28573 2902 1586 111 NET Servicos de Comunicao S.A 10620 2685 421 202 TVCABLE BOGOTA 17974 2580 855 92 PT TELEKOMUNIKASI INDONESIA 18566 2066 382 184 Covad Communications 7545 2024 320 108 TPG Internet Pty Ltd 1785 1999 678 126 PaeTec Communications, Inc. 22773 1992 2927 123 Cox Communications, Inc. 4755 1755 391 193 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2902 2791 NET Servicos de Comunicao S.A 17974 2580 2488 PT TELEKOMUNIKASI INDONESIA 10620 2685 2483 TVCABLE BOGOTA 4766 2930 2011 Korea Telecom (KIX) 7545 2024 1916 TPG Internet Pty Ltd 18566 2066 1882 Covad Communications 1785 1999 1873 PaeTec Communications, Inc. 22773 1992 1869 Cox Communications, Inc. 8402 1607 1591 Corbina telecom 4755 1755 1562 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59628 UNALLOCATED 5.200.128.0/17 48159 Telecommunication In 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.42.0/24 60619 >>UNKNOWN<< 128.0.43.0/24 60619 >>UNKNOWN<< 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.56.0/24 60996 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.200.128.0/17 59628 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 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:11 /10:30 /11:92 /12:250 /13:482 /14:901 /15:1602 /16:12723 /17:6656 /18:11056 /19:22498 /20:32123 /21:34527 /22:48387 /23:42402 /24:241094 /25:1275 /26:1531 /27:863 /28:41 /29:68 /30:19 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2017 2066 Covad Communications 6389 1716 2988 bellsouth.net, inc. 8402 1305 1607 Corbina telecom 22773 1295 1992 Cox Communications, Inc. 30036 1218 1351 Mediacom Communications Corp 11492 1185 1224 Cable One 36998 1140 1172 MOBITEL 1785 1068 1999 PaeTec Communications, Inc. 6983 1018 1147 ITC^Deltacom 10620 1000 2685 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:839 2:735 3:3 4:19 5:806 6:16 8:563 12:1912 13:3 14:857 15:11 16:3 17:10 20:17 23:305 24:1779 27:1485 31:1318 32:45 33:2 34:5 36:59 37:1865 38:879 39:2 40:171 41:2755 42:229 44:8 46:1956 47:2 49:659 50:756 52:12 54:35 55:5 57:26 58:1157 59:583 60:328 61:1415 62:1126 63:2013 64:4337 65:2160 66:4179 67:2020 68:1075 69:3296 70:796 71:491 72:1941 74:2468 75:323 76:308 77:1144 78:1003 79:614 80:1272 81:1018 82:634 83:582 84:595 85:1192 86:459 87:1020 88:544 89:1788 90:149 91:5526 92:618 93:1778 94:1934 95:1693 96:524 97:342 98:1024 99:42 100:30 101:586 103:2927 105:472 106:139 107:208 108:513 109:1866 110:921 111:1063 112:552 113:815 114:693 115:993 116:967 117:801 118:1116 119:1319 120:384 121:739 122:1802 123:1221 124:1375 125:1392 128:638 129:223 130:309 131:670 132:360 133:155 134:269 135:68 136:256 137:243 138:340 139:191 140:201 141:326 142:543 143:392 144:503 145:98 146:525 147:398 148:669 149:352 150:148 151:520 152:415 153:189 154:28 155:416 156:265 157:398 158:279 159:721 160:344 161:450 162:480 163:225 164:581 165:501 166:254 167:596 168:1028 169:129 170:1061 171:181 172:23 173:1592 174:545 175:484 176:1131 177:2138 178:1871 179:62 180:1463 181:492 182:1263 183:421 184:670 185:635 186:2313 187:1328 188:2106 189:1254 190:6630 192:6852 193:5860 194:4633 195:3467 196:1350 197:898 198:4507 199:5349 200:6003 201:2171 202:8829 203:8882 204:4503 205:2566 206:2833 207:2846 208:4012 209:3598 210:2902 211:1519 212:2181 213:1998 214:911 215:99 216:5251 217:1614 218:620 219:321 220:1277 221:559 222:321 223:446 End of report From bzs at world.std.com Fri Jul 12 18:51:04 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 12 Jul 2013 14:51:04 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <20130711190233.CBC3EDFD@m0005311.ppops.net> References: <20130711190233.CBC3EDFD@m0005311.ppops.net> Message-ID: <20960.20504.514385.565329@world.std.com> What I find particularly troubling is this image of the govt paying for these surveillances. The price seemed to be from around $325 for an install plus $10 to $750 install and $500/mo. Now, let's not drop right into the easy and trite "don't they deserve to be reimbursed" right off. Sure, they/we do. But was this reimbursement, or profitable? The troubling image that goes like this: ISP VP #1: Any revenue ideas? ISP VP #2: I hear XYZ is being paid pretty good money for surveillances. ISP VP #1: How much? #2: Word is Verizon is getting $775/install and $500/mo. #1: How many of these are they handling? #2: I don't know, maybe millions of them? #1: Millions? You're talking half a bilion a month? #2: Well, that's VZ. #1: Still...what's the COGS? #2: Not much, sunk cost mostly, some netadmin labor, might need a few extra hands to form a team if it scales up, billing, sales, some PR and contract management. #1: Wow, how do we get a piece of this? #2: Let me make a few calls and get back to you... Accurate? Plausible? Nonsense? http://hosted.ap.org/dynamic/stories/U/US_PRICE_OF_SURVEILLANCE?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT&CTIME=2013-07-10-06-07-53 or http://tinyurl.com/kj2pelb -- -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 symack at gmail.com Fri Jul 12 19:41:53 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 12 Jul 2013 15:41:53 -0400 Subject: Google bot contact In-Reply-To: References: Message-ID: If lucky maybe bot google contact shortdudey123 at gmail.com On 7/11/13, Grant Ridder wrote: > Can someone that works with the Google Bot contact me off list? I am > seeing some really weird access activity for a site I manage. > > -Grant > From streiner at cluebyfour.org Fri Jul 12 19:54:12 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 12 Jul 2013 15:54:12 -0400 (EDT) Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: On Fri, 12 Jul 2013, Tom Morris wrote: > We use Office 365 here at work, but I'd definitely be interested in looking > into alternate solutions --- at the very least I am going to be sure to > inform our staff that there is to be no expectation of privacy when using > your Office365 account. Gross. There should probably never be that expectation with a cloud-based office platform. GPG, TrueCrypt, and SSH are your friends. jms From symack at gmail.com Fri Jul 12 20:04:17 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 12 Jul 2013 16:04:17 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: We are currently working on something right now where all connections are doing over an encrypted vpn. We are bringing SIP, email, search, and cloud to the tunnel. You can contact me off list if you would like to know more. Nick Khamis From baldwinmathew at gmail.com Fri Jul 12 20:25:28 2013 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Fri, 12 Jul 2013 13:25:28 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: While that would secure the connections from snooping if you're mailboxes are on Office 365 and those mailbox stores do not exits on an encrypted LUN then a service can easily read the Exchange database; anyone with server access can read mail across all mailboxes. In fact, Microsoft supports this type of setup with impersonation, e.g. a global user that can query any mailbox it has permissions to within Exchange. This is how some EWS integrated applications work. It wouldn't be that far fetched for the NSA to incorporate the same type of query to monitor the mailboxes -- even subscribing to change notifications so it only queries and collects when a new mail item has arrived. Additionally, Office 365 can simply create a journal rule and have all inbound / outbound mail journal to a location that makes it easier for snoops to look through the messages, e.g. an external SMTP endpoint, all without the end customers' knowledge. If anyone has any questions on Exchange they, too, can contact me off list. Just my 2-cents. -matt On Fri, Jul 12, 2013 at 1:04 PM, Nick Khamis wrote: > We are currently working on something right now where all connections > are doing over an encrypted vpn. We are bringing SIP, email, search, > and cloud to the tunnel. > > You can contact me off list if you would like to know more. > > Nick Khamis > > From baldwinmathew at gmail.com Fri Jul 12 20:26:20 2013 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Fri, 12 Jul 2013 13:26:20 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: I should also note that even if the stores are on an encrypted LUN you are still exposed to impersonation and journaling. -matt On Fri, Jul 12, 2013 at 1:25 PM, Matt Baldwin wrote: > While that would secure the connections from snooping if you're mailboxes > are on Office 365 and those mailbox stores do not exits on an encrypted LUN > then a service can easily read the Exchange database; anyone with server > access can read mail across all mailboxes. In fact, Microsoft supports this > type of setup with impersonation, e.g. a global user that can query any > mailbox it has permissions to within Exchange. This is how some EWS > integrated applications work. It wouldn't be that far fetched for the NSA > to incorporate the same type of query to monitor the mailboxes -- even > subscribing to change notifications so it only queries and collects when a > new mail item has arrived. Additionally, Office 365 can simply create a > journal rule and have all inbound / outbound mail journal to a location > that makes it easier for snoops to look through the messages, e.g. an > external SMTP endpoint, all without the end customers' knowledge. > > If anyone has any questions on Exchange they, too, can contact me off > list. > > Just my 2-cents. > > -matt > > > On Fri, Jul 12, 2013 at 1:04 PM, Nick Khamis wrote: > >> We are currently working on something right now where all connections >> are doing over an encrypted vpn. We are bringing SIP, email, search, >> and cloud to the tunnel. >> >> You can contact me off list if you would like to know more. >> >> Nick Khamis >> >> > From symack at gmail.com Fri Jul 12 21:04:57 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 12 Jul 2013 17:04:57 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: >> I should also note that even if the stores are on an encrypted LUN you are still exposed to >> impersonation and journaling. >> -matt I would hate to assume. Please do elaborate. N. From bep at whack.org Fri Jul 12 21:23:43 2013 From: bep at whack.org (Bruce Pinsky) Date: Fri, 12 Jul 2013 14:23:43 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> Message-ID: <51E073DF.7010606@whack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Baldwin wrote: > While that would secure the connections from snooping if you're mailboxes > are on Office 365 and those mailbox stores do not exits on an encrypted LUN > then a service can easily read the Exchange database; anyone with server > access can read mail across all mailboxes. In fact, Microsoft supports this > type of setup with impersonation, e.g. a global user that can query any > mailbox it has permissions to within Exchange. This is how some EWS > integrated applications work. It wouldn't be that far fetched for the NSA > to incorporate the same type of query to monitor the mailboxes -- even > subscribing to change notifications so it only queries and collects when a > new mail item has arrived. Additionally, Office 365 can simply create a > journal rule and have all inbound / outbound mail journal to a location > that makes it easier for snoops to look through the messages, e.g. an > external SMTP endpoint, all without the end customers' knowledge. > > If anyone has any questions on Exchange they, too, can contact me off list. > > Just my 2-cents. Any what's to say that email addresses at Office 365 aren't just mailing lists where you get a copy and so does $FEDAGENCY. That's how my kids' email addresses work at home :-) - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHgc98ACgkQE1XcgMgrtyYZhgCg3CO8DJfFDXJWj8W6JuasjeOf VeQAnRmhMfhyp5M7S81fxagW96ZGWoCH =LDSL -----END PGP SIGNATURE----- From cidr-report at potaroo.net Fri Jul 12 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Jul 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201307122200.r6CM00nf020648@wattle.apnic.net> This report has been generated at Fri Jul 12 21:13:26 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-07-13 468162 266087 06-07-13 468570 266280 07-07-13 468698 266408 08-07-13 468973 265903 09-07-13 468615 266313 10-07-13 469517 266526 11-07-13 469403 266798 12-07-13 469693 267334 AS Summary 44626 Number of ASes in routing system 18418 Number of ASes announcing only one prefix 4230 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117325792 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'). --- 12Jul13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 470029 267461 202568 43.1% All ASes AS6389 2988 73 2915 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2926 486 2440 83.4% NET Servi?os de Comunica??o S.A. AS7029 4230 2117 2113 50.0% WINDSTREAM - Windstream Communications Inc AS17974 2579 536 2043 79.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2931 934 1997 68.1% KIXS-AS-KR Korea Telecom AS10620 2685 836 1849 68.9% Telmex Colombia S.A. AS22773 1992 169 1823 91.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2066 468 1598 77.3% COVAD - Covad Communications Co. AS4323 2979 1529 1450 48.7% TWTC - tw telecom holdings, inc. AS7303 1732 454 1278 73.8% Telecom Argentina S.A. AS7545 2031 756 1275 62.8% TPG-INTERNET-AP TPG Telecom Limited AS2118 1271 87 1184 93.2% RELCOM-AS OOO "NPO Relcom" AS4755 1752 587 1165 66.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18881 1120 43 1077 96.2% Global Village Telecom AS7552 1190 211 979 82.3% VIETEL-AS-AP Vietel Corporation AS33363 2086 1236 850 40.7% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS1785 1999 1154 845 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1001 182 819 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1172 398 774 66.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1534 804 730 47.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS36998 1172 464 708 60.4% SDN-MOBITEL AS13977 841 139 702 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 735 55 680 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22561 1194 515 679 56.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS6983 1147 480 667 58.2% ITCDELTA - ITC^Deltacom AS24560 1085 418 667 61.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1272 615 657 51.7% Uninet S.A. de C.V. AS4788 764 137 627 82.1% TMNET-AS-AP TM Net, Internet Service Provider AS17676 743 118 625 84.1% GIGAINFRA Softbank BB Corp. AS9808 806 222 584 72.5% CMNET-GD Guangdong Mobile Communication Co.Ltd. Total 52023 16223 35800 68.8% Top 30 total Possible Bogus Routes 5.200.128.0/17 AS59628 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.187.208.0/24 AS174 COGENT Cogent/PSI 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.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.185.0.0/20 AS36219 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 67.207.48.0/20 AS11676 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.120.216.0/21 AS53311 77.75.216.0/21 AS43716 80.68.144.0/20 AS33982 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 173.45.192.0/19 AS6461 MFNX MFN - Metromedia Fiber Network 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 186.249.176.0/20 AS26253 VAS FREITAS SERVICOS DE INTERNET LTDA 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 194.79.48.0/22 AS39117 194.169.237.0/24 AS12968 CDP Netia SA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.124.150.0/24 AS7748 204.124.151.0/24 AS7748 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.123.17.0/24 AS27363 SWISSRE-US-AS Swiss Re America Holding Corporation 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.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.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 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.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 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 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.115.160.0/24 AS11676 216.115.161.0/24 AS11676 216.115.162.0/24 AS11676 216.115.163.0/24 AS11676 216.115.164.0/24 AS11676 216.115.165.0/24 AS11676 216.115.166.0/24 AS11676 216.115.168.0/24 AS11676 216.115.171.0/24 AS11676 216.115.173.0/24 AS11676 216.115.174.0/24 AS11676 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, 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 Jul 12 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Jul 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201307122200.r6CM01Xg020660@wattle.apnic.net> BGP Update Report Interval: 04-Jul-13 -to- 11-Jul-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18403 40070 2.3% 78.1 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 2 - AS8402 34876 2.0% 36.3 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 33260 1.9% 35.4 -- BSNL-NIB National Internet Backbone 4 - AS10620 28669 1.6% 14.4 -- Telmex Colombia S.A. 5 - AS27738 24647 1.4% 42.8 -- Ecuadortelecom S.A. 6 - AS35819 23186 1.3% 52.6 -- MOBILY-AS Etihad Etisalat Company (Mobily) 7 - AS9416 19152 1.1% 9576.0 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 8 - AS13208 18574 1.1% 9287.0 -- NEWTELSOLUTIONS-AS Newtel Ltd 9 - AS10428 18127 1.0% 6042.3 -- CWV-NETWORKS - The College of West Virginia 10 - AS7552 17202 1.0% 14.8 -- VIETEL-AS-AP Vietel Corporation 11 - AS4538 17136 1.0% 30.9 -- ERX-CERNET-BKB China Education and Research Network Center 12 - AS34315 17124 1.0% 4281.0 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 13 - AS4775 16190 0.9% 299.8 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS23394 15137 0.9% 5045.7 -- PSPINC-BDC - Pacific Software Publishing, Inc. 15 - AS28573 11289 0.7% 9.7 -- NET Servi?os de Comunica??o S.A. 16 - AS7303 11112 0.6% 14.8 -- Telecom Argentina S.A. 17 - AS36998 10060 0.6% 16.2 -- SDN-MOBITEL 18 - AS34969 10008 0.6% 1251.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 19 - AS17974 9329 0.5% 9.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS48612 9118 0.5% 1823.6 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9416 19152 1.1% 9576.0 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 2 - AS13208 18574 1.1% 9287.0 -- NEWTELSOLUTIONS-AS Newtel Ltd 3 - AS14733 7316 0.4% 7316.0 -- AS14733 - Barclays Capital Inc. 4 - AS10428 18127 1.0% 6042.3 -- CWV-NETWORKS - The College of West Virginia 5 - AS9854 5613 0.3% 5613.0 -- KTO-AS-KR KTO 6 - AS23394 15137 0.9% 5045.7 -- PSPINC-BDC - Pacific Software Publishing, Inc. 7 - AS19406 4626 0.3% 4626.0 -- TWRS-MA - Towerstream I, Inc. 8 - AS42334 4573 0.3% 4573.0 -- BBP-AS Broadband Plus s.a.l. 9 - AS31461 4342 0.2% 4342.0 -- MORAVIA-IT-AS Moravia IT, a.s. 10 - AS34315 17124 1.0% 4281.0 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 11 - AS16608 7402 0.4% 3701.0 -- KENTEC - Kentec Communications, Inc. 12 - AS6174 7266 0.4% 3633.0 -- SPRINTLINK8 - Sprint 13 - AS38996 7118 0.4% 2372.7 -- MTSNET-SYKTYVKAR-AS MTS OJSC 14 - AS36976 2268 0.1% 2268.0 -- SONANGOL 15 - AS37367 2046 0.1% 2046.0 -- CALLKEY 16 - AS19111 1861 0.1% 1861.0 -- NATURES-BOUN - NBTY, Inc. 17 - AS48612 9118 0.5% 1823.6 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 18 - AS1880 5470 0.3% 1823.3 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 19 - AS56552 4518 0.3% 1506.0 -- TEHRANAIR Tehran Airlines 20 - AS37373 1486 0.1% 1486.0 -- AUC-ASN TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.118.232.0/21 9579 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 2 - 203.118.224.0/21 9573 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 3 - 213.133.192.0/24 9287 0.5% AS13208 -- NEWTELSOLUTIONS-AS Newtel Ltd 4 - 213.133.193.0/24 9287 0.5% AS13208 -- NEWTELSOLUTIONS-AS Newtel Ltd 5 - 92.246.207.0/24 9098 0.5% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 6 - 192.58.232.0/24 8634 0.5% AS6629 -- NOAA-AS - NOAA 7 - 120.28.62.0/24 8072 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 192.107.15.0/24 7316 0.4% AS14733 -- AS14733 - Barclays Capital Inc. 10 - 205.166.165.0/24 6045 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 11 - 12.43.218.0/24 6041 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 12 - 199.248.240.0/24 6041 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 13 - 211.214.206.0/24 5613 0.3% AS9854 -- KTO-AS-KR KTO 14 - 204.29.132.0/23 5467 0.3% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 15 - 216.230.240.0/21 5067 0.3% AS23394 -- PSPINC-BDC - Pacific Software Publishing, Inc. 16 - 216.230.248.0/21 5067 0.3% AS23394 -- PSPINC-BDC - Pacific Software Publishing, Inc. 17 - 199.21.220.0/22 5003 0.3% AS23394 -- PSPINC-BDC - Pacific Software Publishing, Inc. 18 - 194.63.9.0/24 4637 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 19 - 69.38.178.0/24 4626 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 20 - 94.101.130.0/24 4577 0.2% AS43395 -- AFROOZ AFROOZ Etela Resan Company Ltd AS56552 -- TEHRANAIR Tehran Airlines 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 ahebert at pubnix.net Fri Jul 12 23:00:25 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 12 Jul 2013 19:00:25 -0400 Subject: Friday Hosing In-Reply-To: <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> Message-ID: <51E08A89.70208@pubnix.net> On 07/12/13 13:54, Patrick W. Gilmore wrote: > On Jul 12, 2013, at 13:44 , Bryan Fields wrote: >> On 7/12/13 1:39 PM, Patrick W. Gilmore wrote: >>> Put another way, whether it was stupid or evil, the results are the same. Turning off a customer in good standing is actionable in court, and should be avoided by legitimate businesses at nearly all costs. >> You can void a contract at any time so long as you're willing to accept the >> result. > Hence the "actionable in court" phrase. > > >> I've seen people have their service cut off and a carrier keep their >> equipment. Sure they will get it back, but is it worth spending 100k fighting >> them in court for three years? > Every business makes tough decisions. For instance, judging the risk/reward ratio of getting, for instance, loss of use fees, legal fees, etc., out of an opponent in a court case. > > Either way, I'm interested in hearing when a company does these bad things so I can add that into the decision when considering that company. (To be clear, one person saying "they cut me off without warning" does not automatically mean I would never do business with a company. There's always another side. But I still like to collect the info when possible.) > > In this case, the OP didn't mention which company it was, other than "monopole". Well "monopole" (or in good english "monopoly") ... I left their name out on purpose. There is no point into shaming them. I was more interested how prevalent it was in other markets. As this being in Canada... They can easily bury any legal action in suits for centuries =D ----- 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 symack at gmail.com Fri Jul 12 23:18:35 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 12 Jul 2013 19:18:35 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <51E073DF.7010606@whack.org> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <51E073DF.7010606@whack.org> Message-ID: On Fri, Jul 12, 2013 at 5:23 PM, Bruce Pinsky wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matt Baldwin wrote: > > While that would secure the connections from snooping if you're mailboxes > > are on Office 365 and those mailbox stores do not exits on an encrypted > LUN > > then a service can easily read the Exchange database; anyone with server > > access can read mail across all mailboxes. In fact, Microsoft supports > this > > type of setup with impersonation, e.g. a global user that can query any > > mailbox it has permissions to within Exchange. This is how some EWS > > integrated applications work. It wouldn't be that far fetched for the NSA > > to incorporate the same type of query to monitor the mailboxes -- even > > subscribing to change notifications so it only queries and collects when > a > > new mail item has arrived. Additionally, Office 365 can simply create a > > journal rule and have all inbound / outbound mail journal to a location > > that makes it easier for snoops to look through the messages, e.g. an > > external SMTP endpoint, all without the end customers' knowledge. > > > > If anyone has any questions on Exchange they, too, can contact me off > list. > > > > Just my 2-cents. > > Any what's to say that email addresses at Office 365 aren't just mailing > lists where you get a copy and so does $FEDAGENCY. That's how my kids' > email addresses work at home :-) > > > - -- > ========= > bep > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHgc98ACgkQE1XcgMgrtyYZhgCg3CO8DJfFDXJWj8W6JuasjeOf > VeQAnRmhMfhyp5M7S81fxagW96ZGWoCH > =LDSL > -----END PGP SIGNATURE----- > You spy on your kids? I thought not being able to put a lock on my door was bad... N. From symack at gmail.com Fri Jul 12 23:22:21 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 12 Jul 2013 19:22:21 -0400 Subject: Friday Hosing In-Reply-To: <51E08A89.70208@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> Message-ID: Set up your own email server, host your own web pages, maintain your own cloud, breath your own oxygen FTW. N. From wbailey at satelliteintelligencegroup.com Sat Jul 13 00:12:37 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 13 Jul 2013 00:12:37 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> , Message-ID: <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> That doesn't sound like it would be effective in this instance? Sent from my Mobile Device. -------- Original message -------- From: Nick Khamis Date: 07/12/2013 1:06 PM (GMT-08:00) To: "Justin M. Streiner" Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages We are currently working on something right now where all connections are doing over an encrypted vpn. We are bringing SIP, email, search, and cloud to the tunnel. You can contact me off list if you would like to know more. Nick Khamis From shortdudey123 at gmail.com Sat Jul 13 00:32:39 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 12 Jul 2013 17:32:39 -0700 Subject: Google bot contact In-Reply-To: References: Message-ID: I received a very helpful and very prompt off list response, thanks! On Fri, Jul 12, 2013 at 12:41 PM, Nick Khamis wrote: > If lucky maybe bot google contact shortdudey123 at gmail.com > > On 7/11/13, Grant Ridder wrote: > > Can someone that works with the Google Bot contact me off list? I am > > seeing some really weird access activity for a site I manage. > > > > -Grant > > > From ryangard at gmail.com Sat Jul 13 03:50:19 2013 From: ryangard at gmail.com (ryangard at gmail.com) Date: Sat, 13 Jul 2013 03:50:19 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> , <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> Message-ID: <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> It wouldn't be. When the endpoint in question is compromised, there isn't any amount of tunneling or obscurity between point a and point b that will resolve it. Only thing you can do is change to a solution that you have more control over. Sent on the TELUS Mobility network with BlackBerry -----Original Message----- From: Warren Bailey Date: Sat, 13 Jul 2013 00:12:37 To: Nick Khamis; Justin M. Streiner Reply-To: Warren Bailey Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages That doesn't sound like it would be effective in this instance? Sent from my Mobile Device. -------- Original message -------- From: Nick Khamis Date: 07/12/2013 1:06 PM (GMT-08:00) To: "Justin M. Streiner" Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages We are currently working on something right now where all connections are doing over an encrypted vpn. We are bringing SIP, email, search, and cloud to the tunnel. You can contact me off list if you would like to know more. Nick Khamis From Valdis.Kletnieks at vt.edu Sat Jul 13 07:08:24 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 13 Jul 2013 03:08:24 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: Your message of "Sat, 13 Jul 2013 03:50:19 -0000." <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> , <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> Message-ID: <97536.1373699304@turing-police.cc.vt.edu> On Sat, 13 Jul 2013 03:50:19 -0000, ryangard at gmail.com said: > Only thing you can do is change to a solution that you have more control over. > Sent on the TELUS Mobility network with BlackBerry Best. Juxtaposition. Ever. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Sat Jul 13 08:57:45 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 13 Jul 2013 08:57:45 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> , <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com>, <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> Message-ID: The entire idea of prism is hitting tier 1 providers and mass communications providers. If they haven't rooted your exchange gear, they don't need to - your upstream providers entire stream is being copied. I can't think of many providers that couldn't be intercepted. When new transportation mediums arrive, who cares.. You already have a copy from their provider or peer. Sent from my Mobile Device. -------- Original message -------- From: ryangard at gmail.com Date: 07/12/2013 8:52 PM (GMT-08:00) To: Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages It wouldn't be. When the endpoint in question is compromised, there isn't any amount of tunneling or obscurity between point a and point b that will resolve it. Only thing you can do is change to a solution that you have more control over. Sent on the TELUS Mobility network with BlackBerry -----Original Message----- From: Warren Bailey Date: Sat, 13 Jul 2013 00:12:37 To: Nick Khamis; Justin M. Streiner Reply-To: Warren Bailey Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages That doesn't sound like it would be effective in this instance? Sent from my Mobile Device. -------- Original message -------- From: Nick Khamis Date: 07/12/2013 1:06 PM (GMT-08:00) To: "Justin M. Streiner" Cc: nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages We are currently working on something right now where all connections are doing over an encrypted vpn. We are bringing SIP, email, search, and cloud to the tunnel. You can contact me off list if you would like to know more. Nick Khamis From mysidia at gmail.com Sat Jul 13 09:09:28 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 13 Jul 2013 04:09:28 -0500 Subject: Friday Hosing In-Reply-To: <51E04834.50508@vaxination.ca> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <51E04834.50508@vaxination.ca> Message-ID: On 7/12/13, Jean-Francois Mezei wrote: > On 13-07-12 11:44, Alain Hebert wrote: > 1- You call to make cancellation on date X. Speak to person 1. > 2- Wait 20 minutes In a theoretical ideal world, that would probably work fine, but a request for "Shut off service effective the 15th" is just asking for trouble; with many large providers, making a request like that is very likely to be misinterpreted or result in unintended early shutoff. Some providers, even if they understand the request, may choose not to entertain a request more complicated than "Cancel immediately"; they may agree to cancel at date X, then things get terminated immediately, and their terms of service probably contains a rule that the provider may end service at their discretion, without notice with the payment for the rest of the same subscription term following date X still being due. Their account terms also probably specify required binding arbitration, and liability limited to hosting fees, and the subscription cost -- a few dollars to be recovered for a few days extra downtime is not likely to exceed the filing fees that would be required for any sort of court actions. If the domain contains critical resources, you have new hosting setup, before you even think about cancelling old hosting. You make sure the DNS servers point to reliable name service provider(s) who will continue to provide DNS hosting, and you make sure the domain registration is under your full control with full access to all settings, and no provider listed as Admin contact.. Best practice would be Only after you secured all those things and updated A records to point to new hosting provider, should the original provider be contacted with a request to "cancel" the web hosting or particular service cancelled. This is a case of: pay significantly more (multiple providers a short time) in order to greatly reduce risk ---- whereas, asking a provider to cancel at date X, and avoiding overlap --- significantly reduces cost while greatly increasing risk of a 24-48 hour outage. > 3- Call again, speak to person 2, confirm your services will be > cancelled on date X and that you have already paid for services until > then. (or that an invoice has already been produced or will be produced.) -- -JH From symack at gmail.com Sat Jul 13 13:36:09 2013 From: symack at gmail.com (Nick Khamis) Date: Sat, 13 Jul 2013 09:36:09 -0400 Subject: Secure Tunneling. Only with more Control!!! Message-ID: Not having to hijack http://seclists.org/nanog/2013/Jul/251, and without further ado, On 7/12/13, ryangard at gmail.com wrote: > It wouldn't be. When the endpoint in question is compromised, there isn't > any amount of tunneling or obscurity between point a and point b that will > resolve it. Only thing you can do is change to a solution that you have more > control over. > Sent on the TELUS Mobility network with BlackBerry This just got very interesting. Given that we do not own any Microsoft products here, and still able to function like any other corporation, I am more interested in a "solution that you have more control over" secured connections. We currently are using OpenVPN and PKI, coupled with a company policy of key updates every 3 months this will only get incrementally more complex as the number of clients increase. Not to mention one only needs a 3 minutes.... Question: What other options do we have to maintain a secure connection between client and server that gives us more control over traditional OpenVPN+PKI. It would be nice to be able to deploy private keys automatically to the different clients however, seems like a disaster waiting to happen. I would really appreciate some of your takes on this matter, what types of technology, policies are being employed out there for secure connections. Kind Regards, Nick. From frnkblk at iname.com Sat Jul 13 14:22:06 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 13 Jul 2013 09:22:06 -0500 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <51E04834.50508@vaxination.ca> Message-ID: <001601ce7fd4$5aafad60$100f0820$@iname.com> I work for a telco and have seen customers double up on circuits. Why do you think even the largest carriers don't send in a disconnect order for a customer circuit until the replacement circuit is in place and working? Because they've learned the hard way, too. Frank -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Saturday, July 13, 2013 4:09 AM To: Jean-Francois Mezei Cc: nanog at nanog.org Subject: Re: Friday Hosing On 7/12/13, Jean-Francois Mezei wrote: > On 13-07-12 11:44, Alain Hebert wrote: > 1- You call to make cancellation on date X. Speak to person 1. > 2- Wait 20 minutes In a theoretical ideal world, that would probably work fine, but a request for "Shut off service effective the 15th" is just asking for trouble; with many large providers, making a request like that is very likely to be misinterpreted or result in unintended early shutoff. Some providers, even if they understand the request, may choose not to entertain a request more complicated than "Cancel immediately"; they may agree to cancel at date X, then things get terminated immediately, and their terms of service probably contains a rule that the provider may end service at their discretion, without notice with the payment for the rest of the same subscription term following date X still being due. Their account terms also probably specify required binding arbitration, and liability limited to hosting fees, and the subscription cost -- a few dollars to be recovered for a few days extra downtime is not likely to exceed the filing fees that would be required for any sort of court actions. If the domain contains critical resources, you have new hosting setup, before you even think about cancelling old hosting. You make sure the DNS servers point to reliable name service provider(s) who will continue to provide DNS hosting, and you make sure the domain registration is under your full control with full access to all settings, and no provider listed as Admin contact.. Best practice would be Only after you secured all those things and updated A records to point to new hosting provider, should the original provider be contacted with a request to "cancel" the web hosting or particular service cancelled. This is a case of: pay significantly more (multiple providers a short time) in order to greatly reduce risk ---- whereas, asking a provider to cancel at date X, and avoiding overlap --- significantly reduces cost while greatly increasing risk of a 24-48 hour outage. > 3- Call again, speak to person 2, confirm your services will be > cancelled on date X and that you have already paid for services until > then. (or that an invoice has already been produced or will be produced.) -- -JH From fernando at gont.com.ar Sat Jul 13 18:32:34 2013 From: fernando at gont.com.ar (Fernando Gont) Date: Sat, 13 Jul 2013 20:32:34 +0200 Subject: ipv6hackers Meeting in Berlin (July 30, 2013) Message-ID: <51E19D42.9020309@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI Folks, We finally put everything in place to announce the very first IPv6 Hackers meeting. All the relevant info is available at:: - ---- cut here ---- IPv6 Hackers Meeting - Berlin 2013 ** What ** - From a couple of years now, we have had a mailing-list devoted to IPv6 hacking (i.e., testing, tools, low-level stuff, etc.), home of the "ipv6hackers" group. The mailing-list ("charter", subscription options, etc.) is available at: . We're planning to have our first in-person meeting, which will feature a number of presentations (which MUST be accompanied with code and/or measurements/testing). ** When ** July 30 (Tuesday), 2013. From 16:00 to 19:00. ** Where ** Salzufer 14, 10587 Berlin, Germany. EANTC AG (European Advanced Networking Test Center) Headquarters. If you'll be arriving from the IETF 87 venue (Intercontinental Berlin), it's about a 30-minute walk. Maps available here: ** How to participate ** The meeting is open for participation, at no cost. If you have any interesting stuff to present, please send the following information to *before* July 23, 2013: * Proposed presentation title * Abstract * Speaker name Note: All presentations must be practical in nature. They must feature tools, testing, and/or measurements. - ---- cut here ---- - -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 - -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR4Z09AAoJEJbuqe/Qdv/xWhAH/ik4G3eHmLLOXj30xcq3AXwW 62YMvUWcpsPGGrZxvi05Id5ZJGYanitt5bCXIiqVKsgtn56wCXspxpvmTOyWBwqX nlTkravMaCgrYFXvQUTri8UXoRSITdIlrnKdjf5JqG8jiCEBwgpuAqFzryXCElk2 YX5Ygq0fXpcvRI6WNY965eGK9sU2cTtYb9BUTiE9O/eNIv8/EX/2EyQIVVUxWVFt QXcWTYnJXdb9Lleeb3hT/95XjS7zShUpHGzHXt+tRorpDHd3v0+Ygkqreu9BQpTp i1ukUTbSkrj7TGDSVqyKDU+BPoGKIQPHz+CCMpW3M0Z7uIawSjIv3PdepV6Ryy0= =08PE -----END PGP SIGNATURE----- From eaptech at gmail.com Sat Jul 13 19:15:07 2013 From: eaptech at gmail.com (Eric Adler) Date: Sat, 13 Jul 2013 15:15:07 -0400 Subject: Friday Hosing In-Reply-To: <51E02478.30409@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> Message-ID: Just finished migration from a provider that I was no longer happy with to a new provider. Fully expecting them to turn me off the moment I said 'cancel', I prepared everything in advance, moved all the pointers over a few days prior to my planned day to tell them to 'shutoff', retrieved a final backup, then used their web billing interface to tell them I wanted to cancel service. Much to my surprise, they actually had a selection for "what date do you want to cancel service on". I set it to be the next day. I had no issues, but I do attribute much of this to "I migrated services beginning 6 months prior" (when I decided I was not going to renew... it was a 2 year contract). Note: Neither provider is local. As mentioned by others, it is your responsibility to maintain continuity of service when you move between providers. The best way I know to ensure this is to maintain control. Make sure your new system is up and configured before discontinuing your old system. - Eric From woody at pch.net Sat Jul 13 20:44:04 2013 From: woody at pch.net (Bill Woodcock) Date: Sat, 13 Jul 2013 13:44:04 -0700 Subject: One of our own in the Guardian. Message-ID: http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-nsa -Bill From mysidia at gmail.com Sat Jul 13 21:33:00 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 13 Jul 2013 16:33:00 -0500 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> Message-ID: On 7/13/13, Eric Adler wrote: Yes. Maintain control. If you want to avoid the cost of doubling, discuss the risk for the new provider, and ask if they can waive their fee for the period until the old service is cancelled, before agreeing to complete the sale. > As mentioned by others, it is your responsibility to maintain continuity of > service when you move between providers. The best way I know to ensure > this is to maintain control. Make sure your new system is up and > configured before discontinuing your old system. > > - Eric -- -JH From nanog at jima.us Sun Jul 14 02:15:57 2013 From: nanog at jima.us (Jima) Date: Sat, 13 Jul 2013 20:15:57 -0600 Subject: One of our own in the Guardian. In-Reply-To: References: Message-ID: <51E209DD.5020702@jima.us> On 2013-07-13 14:44, Bill Woodcock wrote: > http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-nsa I can happily state that XMission is my home ISP, with UTOPIA (city-involved fiber optic provider) as the local loop. (Really, who has 100/100 at home?) I do hope the latest patches $network_vendor has sent Pete allows him to get IPv6 to me, though. :-P Jima From joe at nethead.com Sun Jul 14 04:20:20 2013 From: joe at nethead.com (Joe Hamelin) Date: Sat, 13 Jul 2013 21:20:20 -0700 Subject: One of our own in the Guardian. In-Reply-To: <51E209DD.5020702@jima.us> References: <51E209DD.5020702@jima.us> Message-ID: Jima said: Really, who has 100/100 at home? Oddly, those living in Grand Coulee, WA. I went there once to setup corporate connectivity for a regional tire store. They ordered the minimal drop, 50/50Mbs. One of the tire changers there told me that he had 100/100 at home for $50/month. This was a town without T-Mobile service. I had to haul out the butt set and clip on to the business POTS lines to turn up the VPN. Most of rural Central Washington has very good fiber connectivity. Forward looking Public Utility Districts FTW! -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From shortdudey123 at gmail.com Sun Jul 14 04:32:33 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sat, 13 Jul 2013 21:32:33 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> Message-ID: Someone I know in Washington state has 100/100 at home and made the comment to me a year ago that it was one of the slower speeds offered. I am not sure who his ISP is however. -Grant On Sat, Jul 13, 2013 at 9:20 PM, Joe Hamelin wrote: > Jima said: Really, who has 100/100 at home? > > Oddly, those living in Grand Coulee, WA. > > I went there once to setup corporate connectivity for a regional tire > store. They ordered the minimal drop, 50/50Mbs. One of the tire changers > there told me that he had 100/100 at home for $50/month. > > This was a town without T-Mobile service. I had to haul out the butt set > and clip on to the business POTS lines to turn up the VPN. > > Most of rural Central Washington has very good fiber connectivity. Forward > looking Public Utility Districts FTW! > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From alex at corp.nac.net Sun Jul 14 04:44:21 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Sun, 14 Jul 2013 00:44:21 -0400 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> Yet, here, where I live, only 47 road miles from New York City, I have a cable company who sells me metered (yes, METERED) DOCSIS, for nearly $100/month, 35/3. The limitation is like 100 GB/month or something (the equivalent of the amount of Netflix or AppleTV my kids watch in a weekend) No alternatives, no FiOS, no nothing. Well, I can get 3/.768 DSL if I please. Someone, please help me. Please. > > Jima said: Really, who has 100/100 at home? > > Oddly, those living in Grand Coulee, WA. > > I went there once to setup corporate connectivity for a regional tire store. > They ordered the minimal drop, 50/50Mbs. One of the tire changers there > told me that he had 100/100 at home for $50/month. > > This was a town without T-Mobile service. I had to haul out the butt set and > clip on to the business POTS lines to turn up the VPN. > > Most of rural Central Washington has very good fiber connectivity. Forward > looking Public Utility Districts FTW! > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From joe at nethead.com Sun Jul 14 04:44:18 2013 From: joe at nethead.com (Joe Hamelin) Date: Sat, 13 Jul 2013 21:44:18 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> Message-ID: http://www.nwi.net/ I'm thinking. Rides the county's fiber network. I remember delivering them T1s from Seattle back in the day ('96ish). I sure wish I could get some of that love. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Sat, Jul 13, 2013 at 9:32 PM, Grant Ridder wrote: > Someone I know in Washington state has 100/100 at home and made the > comment to me a year ago that it was one of the slower speeds offered. I > am not sure who his ISP is however. > > -Grant > > > On Sat, Jul 13, 2013 at 9:20 PM, Joe Hamelin wrote: > >> Jima said: Really, who has 100/100 at home? >> >> Oddly, those living in Grand Coulee, WA. >> >> I went there once to setup corporate connectivity for a regional tire >> store. They ordered the minimal drop, 50/50Mbs. One of the tire changers >> there told me that he had 100/100 at home for $50/month. >> >> This was a town without T-Mobile service. I had to haul out the butt set >> and clip on to the business POTS lines to turn up the VPN. >> >> Most of rural Central Washington has very good fiber connectivity. Forward >> looking Public Utility Districts FTW! >> >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> > > From mark at viviotech.net Sun Jul 14 04:46:46 2013 From: mark at viviotech.net (Mark Keymer) Date: Sat, 13 Jul 2013 21:46:46 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> Message-ID: <51E22D36.1020707@viviotech.net> He might have been talking about Condo Internet if he is in the Seattle area. They deliver 1Gig connections to your Condo/Apartment, if your in one of the buildings they service. Also I wanted to mention that I have only seen,heard and experienced good things from Xmission. It is nice to see how they have been handling these issues. Sincerely, Mark On 7/13/2013 9:32 PM, Grant Ridder wrote: > Someone I know in Washington state has 100/100 at home and made the comment > to me a year ago that it was one of the slower speeds offered. I am not > sure who his ISP is however. > > -Grant > > On Sat, Jul 13, 2013 at 9:20 PM, Joe Hamelin wrote: > >> Jima said: Really, who has 100/100 at home? >> >> Oddly, those living in Grand Coulee, WA. >> >> I went there once to setup corporate connectivity for a regional tire >> store. They ordered the minimal drop, 50/50Mbs. One of the tire changers >> there told me that he had 100/100 at home for $50/month. >> >> This was a town without T-Mobile service. I had to haul out the butt set >> and clip on to the business POTS lines to turn up the VPN. >> >> Most of rural Central Washington has very good fiber connectivity. Forward >> looking Public Utility Districts FTW! >> >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> From shortdudey123 at gmail.com Sun Jul 14 04:49:07 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sat, 13 Jul 2013 21:49:07 -0700 Subject: One of our own in the Guardian. In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> Message-ID: In Mountain View (the middle of Silicon Valley) the only choice i have is overpriced Comcast w/ a 300 gig limit. I used to chew threw 300 gig in a week when i was in school. -Grant On Sat, Jul 13, 2013 at 9:44 PM, Alex Rubenstein wrote: > Yet, here, where I live, only 47 road miles from New York City, I have a > cable company who sells me metered (yes, METERED) DOCSIS, for nearly > $100/month, 35/3. The limitation is like 100 GB/month or something (the > equivalent of the amount of Netflix or AppleTV my kids watch in a weekend) > No alternatives, no FiOS, no nothing. Well, I can get 3/.768 DSL if I > please. > > Someone, please help me. > > Please. > > > > > > > > Jima said: Really, who has 100/100 at home? > > > > Oddly, those living in Grand Coulee, WA. > > > > I went there once to setup corporate connectivity for a regional tire > store. > > They ordered the minimal drop, 50/50Mbs. One of the tire changers there > > told me that he had 100/100 at home for $50/month. > > > > This was a town without T-Mobile service. I had to haul out the butt set > and > > clip on to the business POTS lines to turn up the VPN. > > > > Most of rural Central Washington has very good fiber connectivity. > Forward > > looking Public Utility Districts FTW! > > > > -- > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > From mis at seiden.com Sun Jul 14 04:50:19 2013 From: mis at seiden.com (Mark Seiden) Date: Sun, 14 Jul 2013 06:50:19 +0200 Subject: One of our own in the Guardian. In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> Message-ID: and here i am in the icann-selected hotel for the icann conference, and they gave us a total of 500MB of metered usage. for our entire stay, not per day. (should be better on the conference net). maybe i should just check out and check in every day. On Jul 14, 2013, at 6:44 AM, Alex Rubenstein wrote: > Yet, here, where I live, only 47 road miles from New York City, I have a cable company who sells me metered (yes, METERED) DOCSIS, for nearly $100/month, 35/3. The limitation is like 100 GB/month or something (the equivalent of the amount of Netflix or AppleTV my kids watch in a weekend) No alternatives, no FiOS, no nothing. Well, I can get 3/.768 DSL if I please. > > Someone, please help me. > > Please. > > > > >> >> Jima said: Really, who has 100/100 at home? >> >> Oddly, those living in Grand Coulee, WA. >> >> I went there once to setup corporate connectivity for a regional tire store. >> They ordered the minimal drop, 50/50Mbs. One of the tire changers there >> told me that he had 100/100 at home for $50/month. >> >> This was a town without T-Mobile service. I had to haul out the butt set and >> clip on to the business POTS lines to turn up the VPN. >> >> Most of rural Central Washington has very good fiber connectivity. Forward >> looking Public Utility Districts FTW! >> >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From mike.lyon at gmail.com Sun Jul 14 05:07:57 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 13 Jul 2013 22:07:57 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> Message-ID: <-3253865967077034596@unknownmsgid> There are a few wireless providers that serve the Mountain View area.. -Mike Founder Ridge Wireless www.ridgewireless.net Sent from my iPhone On Jul 13, 2013, at 21:56, Grant Ridder wrote: > In Mountain View (the middle of Silicon Valley) the only choice i have is > overpriced Comcast w/ a 300 gig limit. I used to chew threw 300 gig in a > week when i was in school. > > -Grant > > On Sat, Jul 13, 2013 at 9:44 PM, Alex Rubenstein wrote: > >> Yet, here, where I live, only 47 road miles from New York City, I have a >> cable company who sells me metered (yes, METERED) DOCSIS, for nearly >> $100/month, 35/3. The limitation is like 100 GB/month or something (the >> equivalent of the amount of Netflix or AppleTV my kids watch in a weekend) >> No alternatives, no FiOS, no nothing. Well, I can get 3/.768 DSL if I >> please. >> >> Someone, please help me. >> >> Please. >> >> >> >> >>> >>> Jima said: Really, who has 100/100 at home? >>> >>> Oddly, those living in Grand Coulee, WA. >>> >>> I went there once to setup corporate connectivity for a regional tire >> store. >>> They ordered the minimal drop, 50/50Mbs. One of the tire changers there >>> told me that he had 100/100 at home for $50/month. >>> >>> This was a town without T-Mobile service. I had to haul out the butt set >> and >>> clip on to the business POTS lines to turn up the VPN. >>> >>> Most of rural Central Washington has very good fiber connectivity. >> Forward >>> looking Public Utility Districts FTW! >>> >>> -- >>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> >> From joe at nethead.com Sun Jul 14 05:46:07 2013 From: joe at nethead.com (Joe Hamelin) Date: Sat, 13 Jul 2013 22:46:07 -0700 Subject: One of our own in the Guardian. In-Reply-To: <51E22D36.1020707@viviotech.net> References: <51E209DD.5020702@jima.us> <51E22D36.1020707@viviotech.net> Message-ID: On Sat, Jul 13, 2013 at 9:46 PM, Mark Keymer wrote: > He might have been talking about Condo Internet if he is in the Seattle > area. They deliver 1Gig connections to your Condo/Apartment, if your in > one of the buildings they service. > I know the guy that does Condo. He was a very good friend of a very good friend of NANOG. Joe Wood (RIP) from Google, Flying Croc, and Wolfe. They were just starting a CLEC in the Puget Sound area when Joe died. Damn, I miss that bastard. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From eugen at imacandi.net Sun Jul 14 07:42:50 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 14 Jul 2013 10:42:50 +0300 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> Message-ID: Maybe people will now start turning on their encryption functions on any device capable of doing it :) On Sat, Jul 13, 2013 at 11:57 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > The entire idea of prism is hitting tier 1 providers and mass > communications providers. If they haven't rooted your exchange gear, they > don't need to - your upstream providers entire stream is being copied. I > can't think of many providers that couldn't be intercepted. When new > transportation mediums arrive, who cares.. You already have a copy from > their provider or peer. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: ryangard at gmail.com > Date: 07/12/2013 8:52 PM (GMT-08:00) > To: > Cc: nanog at nanog.org > Subject: Re: Office 365..? how Microsoft handed the NSA access to > encrypted messages > > > It wouldn't be. When the endpoint in question is compromised, there isn't > any amount of tunneling or obscurity between point a and point b that will > resolve it. Only thing you can do is change to a solution that you have > more control over. > Sent on the TELUS Mobility network with BlackBerry > > -----Original Message----- > From: Warren Bailey > Date: Sat, 13 Jul 2013 00:12:37 > To: Nick Khamis; Justin M. Streiner< > streiner at cluebyfour.org> > Reply-To: Warren Bailey > Cc: nanog at nanog.org > Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted > messages > > That doesn't sound like it would be effective in this instance? > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Nick Khamis > Date: 07/12/2013 1:06 PM (GMT-08:00) > To: "Justin M. Streiner" > Cc: nanog at nanog.org > Subject: Re: Office 365..? how Microsoft handed the NSA access to > encrypted messages > > > We are currently working on something right now where all connections > are doing over an encrypted vpn. We are bringing SIP, email, search, > and cloud to the tunnel. > > You can contact me off list if you would like to know more. > > Nick Khamis > > From ag4ve.us at gmail.com Sun Jul 14 07:51:12 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 14 Jul 2013 03:51:12 -0400 Subject: One of our own in the Guardian. In-Reply-To: <-3253865967077034596@unknownmsgid> References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> <-3253865967077034596@unknownmsgid> Message-ID: Well, I think Google has the right idea with providing Internet by floating balloons. And the way that cell phone tech has been improving, we might all have 10G in... 10 years or so? If Google is providing it, it'll be monitored by our government but hey, we'll have enough bandwidth to hang ourselves with :) I really wish more places would just start Internet co-ops. On Jul 14, 2013 1:10 AM, "Mike Lyon" wrote: > There are a few wireless providers that serve the Mountain View area.. > > -Mike > > Founder > Ridge Wireless > www.ridgewireless.net > > Sent from my iPhone > > On Jul 13, 2013, at 21:56, Grant Ridder wrote: > > > In Mountain View (the middle of Silicon Valley) the only choice i have is > > overpriced Comcast w/ a 300 gig limit. I used to chew threw 300 gig in a > > week when i was in school. > > > > -Grant > > > > On Sat, Jul 13, 2013 at 9:44 PM, Alex Rubenstein > wrote: > > > >> Yet, here, where I live, only 47 road miles from New York City, I have a > >> cable company who sells me metered (yes, METERED) DOCSIS, for nearly > >> $100/month, 35/3. The limitation is like 100 GB/month or something (the > >> equivalent of the amount of Netflix or AppleTV my kids watch in a > weekend) > >> No alternatives, no FiOS, no nothing. Well, I can get 3/.768 DSL if I > >> please. > >> > >> Someone, please help me. > >> > >> Please. > >> > >> > >> > >> > >>> > >>> Jima said: Really, who has 100/100 at home? > >>> > >>> Oddly, those living in Grand Coulee, WA. > >>> > >>> I went there once to setup corporate connectivity for a regional tire > >> store. > >>> They ordered the minimal drop, 50/50Mbs. One of the tire changers there > >>> told me that he had 100/100 at home for $50/month. > >>> > >>> This was a town without T-Mobile service. I had to haul out the butt > set > >> and > >>> clip on to the business POTS lines to turn up the VPN. > >>> > >>> Most of rural Central Washington has very good fiber connectivity. > >> Forward > >>> looking Public Utility Districts FTW! > >>> > >>> -- > >>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > >> > >> > > From drc at virtualized.org Sun Jul 14 08:16:33 2013 From: drc at virtualized.org (David Conrad) Date: Sun, 14 Jul 2013 10:16:33 +0200 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> Message-ID: <85364B78-6892-4F47-BCA9-454932142609@virtualized.org> On Jul 14, 2013, at 6:50 AM, Mark Seiden wrote: > and here i am in the icann-selected hotel for the icann conference, and they gave us a total of 500MB of metered usage. Trust me, the 500MB limit (per day, and resettable if you go down to the front desk and request more) is the least of your worries: % ping trantor.virtualized.org .... Request timeout for icmp_seq 179 Request timeout for icmp_seq 180 Request timeout for icmp_seq 181 64 bytes from 199.48.134.42: icmp_seq=104 ttl=40 time=78594.936 ms 64 bytes from 199.48.134.42: icmp_seq=64 ttl=40 time=119037.553 ms 64 bytes from 199.48.134.42: icmp_seq=80 ttl=40 time=103268.363 ms (DUP!) 64 bytes from 199.48.134.42: icmp_seq=80 ttl=40 time=103690.981 ms (DUP!) 64 bytes from 199.48.134.42: icmp_seq=64 ttl=40 time=120196.719 ms (DUP!) 64 bytes from 199.48.134.42: icmp_seq=64 ttl=40 time=120333.246 ms (DUP!) 64 bytes from 199.48.134.42: icmp_seq=85 ttl=40 time=99395.502 ms 64 bytes from 199.48.134.42: icmp_seq=105 ttl=40 time=79406.728 ms Request timeout for icmp_seq 186 64 bytes from 199.48.134.42: icmp_seq=93 ttl=40 time=94822.040 ms Request timeout for icmp_seq 188 Request timeout for icmp_seq 189 ... Regards, -drc From ag4ve.us at gmail.com Sun Jul 14 09:12:26 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 14 Jul 2013 05:12:26 -0400 Subject: One of our own in the Guardian. In-Reply-To: <85364B78-6892-4F47-BCA9-454932142609@virtualized.org> References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> <85364B78-6892-4F47-BCA9-454932142609@virtualized.org> Message-ID: You're on a continent with the second least amount of light pollution of all of the continents on earth (iirc) and are somehow surprised about bad net access? I would question the wisdom of planning a tech conference there, but not the facility itself. On Sun, Jul 14, 2013 at 4:16 AM, David Conrad wrote: > On Jul 14, 2013, at 6:50 AM, Mark Seiden wrote: >> and here i am in the icann-selected hotel for the icann conference, and they gave us a total of 500MB of metered usage. > > Trust me, the 500MB limit (per day, and resettable if you go down to the front desk and request more) is the least of your worries: > > % ping trantor.virtualized.org > .... > Request timeout for icmp_seq 179 > Request timeout for icmp_seq 180 > Request timeout for icmp_seq 181 > 64 bytes from 199.48.134.42: icmp_seq=104 ttl=40 time=78594.936 ms > 64 bytes from 199.48.134.42: icmp_seq=64 ttl=40 time=119037.553 ms > 64 bytes from 199.48.134.42: icmp_seq=80 ttl=40 time=103268.363 ms (DUP!) > 64 bytes from 199.48.134.42: icmp_seq=80 ttl=40 time=103690.981 ms (DUP!) > 64 bytes from 199.48.134.42: icmp_seq=64 ttl=40 time=120196.719 ms (DUP!) > 64 bytes from 199.48.134.42: icmp_seq=64 ttl=40 time=120333.246 ms (DUP!) > 64 bytes from 199.48.134.42: icmp_seq=85 ttl=40 time=99395.502 ms > 64 bytes from 199.48.134.42: icmp_seq=105 ttl=40 time=79406.728 ms > Request timeout for icmp_seq 186 > 64 bytes from 199.48.134.42: icmp_seq=93 ttl=40 time=94822.040 ms > Request timeout for icmp_seq 188 > Request timeout for icmp_seq 189 > ... > > Regards, > -drc > > From woody at pch.net Sun Jul 14 09:36:47 2013 From: woody at pch.net (Bill Woodcock) Date: Sun, 14 Jul 2013 02:36:47 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> <85364B78-6892-4F47-BCA9-454932142609@virtualized.org> Message-ID: <5CE0AC1F-4678-44F9-A347-54ABD1F30ECD@pch.net> On Jul 14, 2013, at 2:12 AM, shawn wilson wrote: > You're on a continent with the second least amount of light pollution > of all of the continents on earth (iirc) and are somehow surprised > about bad net access? I would question the wisdom of planning a tech > conference there, but not the facility itself. Nope. Here's a trace to the same destination, from Cape Town: woody$ ping trantor.virtualized.org PING trantor.virtualized.org (199.48.134.42): 56 data bytes 64 bytes from 199.48.134.42: icmp_seq=0 ttl=241 time=228.552 ms 64 bytes from 199.48.134.42: icmp_seq=1 ttl=241 time=241.209 ms 64 bytes from 199.48.134.42: icmp_seq=2 ttl=241 time=243.835 ms 64 bytes from 199.48.134.42: icmp_seq=3 ttl=241 time=316.949 ms 64 bytes from 199.48.134.42: icmp_seq=4 ttl=241 time=283.197 ms 64 bytes from 199.48.134.42: icmp_seq=5 ttl=241 time=229.341 ms 64 bytes from 199.48.134.42: icmp_seq=6 ttl=241 time=242.710 ms 64 bytes from 199.48.134.42: icmp_seq=7 ttl=241 time=307.105 ms 64 bytes from 199.48.134.42: icmp_seq=8 ttl=241 time=330.387 ms 64 bytes from 199.48.134.42: icmp_seq=9 ttl=241 time=244.312 ms 64 bytes from 199.48.134.42: icmp_seq=10 ttl=241 time=231.485 ms 64 bytes from 199.48.134.42: icmp_seq=11 ttl=241 time=241.859 ms 64 bytes from 199.48.134.42: icmp_seq=12 ttl=241 time=249.606 ms 64 bytes from 199.48.134.42: icmp_seq=13 ttl=241 time=250.695 ms 64 bytes from 199.48.134.42: icmp_seq=14 ttl=241 time=253.704 ms ^C --- trantor.virtualized.org ping statistics --- 15 packets transmitted, 15 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 228.552/259.663/330.387/32.060 ms b8f6b1147369:~ woody$ -Bill From ag4ve.us at gmail.com Sun Jul 14 09:48:33 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 14 Jul 2013 05:48:33 -0400 Subject: One of our own in the Guardian. In-Reply-To: <5CE0AC1F-4678-44F9-A347-54ABD1F30ECD@pch.net> References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> <85364B78-6892-4F47-BCA9-454932142609@virtualized.org> <5CE0AC1F-4678-44F9-A347-54ABD1F30ECD@pch.net> Message-ID: On Jul 14, 2013 5:36 AM, "Bill Woodcock" wrote: > > > On Jul 14, 2013, at 2:12 AM, shawn wilson wrote: > >> You're on a continent with the second least amount of light pollution >> of all of the continents on earth (iirc) and are somehow surprised >> about bad net access? I would question the wisdom of planning a tech >> conference there, but not the facility itself. > > > Nope. > Heh nice pic :) Ok I've been wrong before. From drc at virtualized.org Sun Jul 14 10:26:20 2013 From: drc at virtualized.org (David Conrad) Date: Sun, 14 Jul 2013 12:26:20 +0200 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> <85364B78-6892-4F47-BCA9-454932142609@virtualized.org> Message-ID: <6EB57B99-9662-4CCD-8488-D2DFD70FC25E@virtualized.org> On Jul 14, 2013, at 11:12 AM, shawn wilson wrote: > You're on a continent with the second least amount of light pollution > of all of the continents on earth (iirc) and are somehow surprised > about bad net access? Africa is not homogeneous. > I would question the wisdom of planning a tech > conference there, but not the facility itself. Actually, I expect the bandwidth/latency at the conference venue itself is fine (has been so far, but the conference hasn't really started yet), even given the high-bandwidth requirements (streaming audio and video in parallel sessions and around 2000 attendees and a zillion wifi devices). ICANN has been doing this for a while in a bunch of different places (some significantly more challenging than Durban, ZA). I suspect the problem is the (offsite) hotel that Mark and I are at was not really prepared for a full house of folks interested in viewing streams, downloading documents, etc. (despite attempts to inform the hotel of the impending tsunami). I imagine folks involved in setting up NANOG-related networks might be familiar with this sort of situation... Regards, -drc From johnl at iecc.com Sun Jul 14 14:22:06 2013 From: johnl at iecc.com (John Levine) Date: 14 Jul 2013 14:22:06 -0000 Subject: hotel networks, was One of our own in the Guardian. In-Reply-To: <6EB57B99-9662-4CCD-8488-D2DFD70FC25E@virtualized.org> Message-ID: <20130714142206.37787.qmail@joyce.lan> >I suspect the problem is the (offsite) hotel that Mark and I are at was not >really prepared for a full house of folks interested in viewing streams, >downloading documents, etc. (despite attempts to inform the hotel of the >impending tsunami). I imagine folks involved in setting up NANOG-related >networks might be familiar with this sort of situation... I've talked to people who do conference arrangements, and no matter what you tell the hotel, the hotel talks to their outsourced Internet provider, who tells them it will be fine, which of course it will not be. The hotel outsourcers also tend to have poorly trained staff who think that the way to increase wifi capacity is to turn the power on all of the APs up to 11. The IETF deals with this problem by writing into the conference agreement that their netops people will take over the hotel's network for the duration of the meeting, and bring in their own adequate backhaul. Dunno what ICANN does. From kmedcalf at dessus.com Sun Jul 14 16:06:56 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 14 Jul 2013 10:06:56 -0600 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: Message-ID: <96b0f698759d424cbb6a3ff80d038d0e@mail.dessus.com> > Maybe people will now start turning on their encryption functions on > any device capable of doing it :) Those that care did that many moons ago. The rest don't care. Of course, if you do not have control of the endpoints doing the encryption (ie, the untrustworthy sucker is in the middle somewhere) then it does not matter. Those who care maintain their own endpoints. Those that do not care use gmail, office365, yahoo, and their carriers e-mail outsourced to one of the previously listed. Given that this (spying and massive interception) has been common knowledge since the inception of the Internet, and that it has particularly been known that the United States became particularly despotic and corrupt, in the last decade and a bit when it started hoovering up everything they could get their suckers on (by creating massive cable cuts all of the US so they could install their taps), those that are still sending traffic through the United States or using hosting services in the United States, without very strong encryption simple do not care. Folks who use Office 365 simply do not care in the least about privacy, confidentiality or security. If they did they would not be using Office 365. Or gmail. Or Yahoo. Or whatever they are using. Since these people do not care, and they continue to use these services, and this has been a known circumstance for decades, what makes you think that "many people" will suddenly start to be concerned and migrate to more private/secure/confidential systems that have been available all along but that they deliberately chose not to use? From rodrick.brown at gmail.com Sun Jul 14 16:16:51 2013 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Sun, 14 Jul 2013 12:16:51 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> Message-ID: <-4184666514164210262@unknownmsgid> Seems Kim was right all along... Rumors have it MegaEmail is in the works. Sent from my iPhone On Jul 14, 2013, at 3:45 AM, Eugeniu Patrascu wrote: > Maybe people will now start turning on their encryption functions on any > device capable of doing it :) > > > On Sat, Jul 13, 2013 at 11:57 AM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> The entire idea of prism is hitting tier 1 providers and mass >> communications providers. If they haven't rooted your exchange gear, they >> don't need to - your upstream providers entire stream is being copied. I >> can't think of many providers that couldn't be intercepted. When new >> transportation mediums arrive, who cares.. You already have a copy from >> their provider or peer. >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: ryangard at gmail.com >> Date: 07/12/2013 8:52 PM (GMT-08:00) >> To: >> Cc: nanog at nanog.org >> Subject: Re: Office 365..? how Microsoft handed the NSA access to >> encrypted messages >> >> >> It wouldn't be. When the endpoint in question is compromised, there isn't >> any amount of tunneling or obscurity between point a and point b that will >> resolve it. Only thing you can do is change to a solution that you have >> more control over. >> Sent on the TELUS Mobility network with BlackBerry >> >> -----Original Message----- >> From: Warren Bailey >> Date: Sat, 13 Jul 2013 00:12:37 >> To: Nick Khamis; Justin M. Streiner< >> streiner at cluebyfour.org> >> Reply-To: Warren Bailey >> Cc: nanog at nanog.org >> Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted >> messages >> >> That doesn't sound like it would be effective in this instance? >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: Nick Khamis >> Date: 07/12/2013 1:06 PM (GMT-08:00) >> To: "Justin M. Streiner" >> Cc: nanog at nanog.org >> Subject: Re: Office 365..? how Microsoft handed the NSA access to >> encrypted messages >> >> >> We are currently working on something right now where all connections >> are doing over an encrypted vpn. We are bringing SIP, email, search, >> and cloud to the tunnel. >> >> You can contact me off list if you would like to know more. >> >> Nick Khamis >> >> From wbailey at satelliteintelligencegroup.com Sun Jul 14 16:23:31 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 14 Jul 2013 16:23:31 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <-4184666514164210262@unknownmsgid> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> , <-4184666514164210262@unknownmsgid> Message-ID: <1153e3h1jvk7ymbv4v3f9b1m.1373819005906@email.android.com> Kim was never right all along. I worked for them/him in Munich in 2000 just before tuv buyout. I'm actually really surprised journalists haven't googled his back story.. The real one. Sent from my Mobile Device. -------- Original message -------- From: Rodrick Brown Date: 07/14/2013 9:16 AM (GMT-08:00) To: Eugeniu Patrascu Cc: Warren Bailey ,nanog at nanog.org Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages Seems Kim was right all along... Rumors have it MegaEmail is in the works. Sent from my iPhone On Jul 14, 2013, at 3:45 AM, Eugeniu Patrascu wrote: > Maybe people will now start turning on their encryption functions on any > device capable of doing it :) > > > On Sat, Jul 13, 2013 at 11:57 AM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> The entire idea of prism is hitting tier 1 providers and mass >> communications providers. If they haven't rooted your exchange gear, they >> don't need to - your upstream providers entire stream is being copied. I >> can't think of many providers that couldn't be intercepted. When new >> transportation mediums arrive, who cares.. You already have a copy from >> their provider or peer. >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: ryangard at gmail.com >> Date: 07/12/2013 8:52 PM (GMT-08:00) >> To: >> Cc: nanog at nanog.org >> Subject: Re: Office 365..? how Microsoft handed the NSA access to >> encrypted messages >> >> >> It wouldn't be. When the endpoint in question is compromised, there isn't >> any amount of tunneling or obscurity between point a and point b that will >> resolve it. Only thing you can do is change to a solution that you have >> more control over. >> Sent on the TELUS Mobility network with BlackBerry >> >> -----Original Message----- >> From: Warren Bailey >> Date: Sat, 13 Jul 2013 00:12:37 >> To: Nick Khamis; Justin M. Streiner< >> streiner at cluebyfour.org> >> Reply-To: Warren Bailey >> Cc: nanog at nanog.org >> Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted >> messages >> >> That doesn't sound like it would be effective in this instance? >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: Nick Khamis >> Date: 07/12/2013 1:06 PM (GMT-08:00) >> To: "Justin M. Streiner" >> Cc: nanog at nanog.org >> Subject: Re: Office 365..? how Microsoft handed the NSA access to >> encrypted messages >> >> >> We are currently working on something right now where all connections >> are doing over an encrypted vpn. We are bringing SIP, email, search, >> and cloud to the tunnel. >> >> You can contact me off list if you would like to know more. >> >> Nick Khamis >> >> From jeff-kell at utc.edu Sun Jul 14 17:11:56 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 14 Jul 2013 13:11:56 -0400 Subject: One of our own in the Guardian. In-Reply-To: <51E209DD.5020702@jima.us> References: <51E209DD.5020702@jima.us> Message-ID: <51E2DBDC.8020808@utc.edu> On 7/13/2013 10:15 PM, Jima wrote: > On 2013-07-13 14:44, Bill Woodcock wrote: >> http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-nsa >> > > I can happily state that XMission is my home ISP, with UTOPIA > (city-involved fiber optic provider) as the local loop. (Really, who > has 100/100 at home?) A whole lot of folks in Chattanooga... https://epbfi.com/enroll/packages/#/fi-speed-internet-100 100Mb symmetric is $69/mo, 250Mb is $139, 1Gbit is $299 Largely Alcatel/Lucent GPON. Business rates considerably higher :) They are one of our providers and we aren't "metered". I don't know how they're handling domestic rates / quotas. Jeff From joelja at bogus.com Sun Jul 14 17:32:33 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 14 Jul 2013 10:32:33 -0700 Subject: hotel networks, was One of our own in the Guardian. In-Reply-To: <20130714142206.37787.qmail@joyce.lan> References: <20130714142206.37787.qmail@joyce.lan> Message-ID: <51E2E0B1.3000907@bogus.com> On 7/14/13 7:22 AM, John Levine wrote: >> I suspect the problem is the (offsite) hotel that Mark and I are at was not >> really prepared for a full house of folks interested in viewing streams, >> downloading documents, etc. (despite attempts to inform the hotel of the >> impending tsunami). I imagine folks involved in setting up NANOG-related >> networks might be familiar with this sort of situation... > I've talked to people who do conference arrangements, and no matter > what you tell the hotel, the hotel talks to their outsourced Internet > provider, who tells them it will be fine, which of course it will not > be. The hotel outsourcers also tend to have poorly trained staff who > think that the way to increase wifi capacity is to turn the power on > all of the APs up to 11. Simply put they were'nt designed and built to be operated with 100% concurrency. Short of some kind of exceptional contractual arrangement you shouldn't expect them to be different when you arrive then when the facility was contracted. > The IETF deals with this problem by writing into the conference > agreement that their netops people will take over the hotel's network > for the duration of the meeting, and bring in their own adequate > backhaul. Dunno what ICANN does. Building a network for a week is expensive. it's gotten a lot simpler and cheaper but it's still relatively extrodinary. Taking over existing infrastructure operating it and putting it back is a new challenge everytime. > From scott at doc.net.au Sun Jul 14 17:48:55 2013 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Jul 2013 10:48:55 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460EEC9@EXCHMBX.hq.nac.net> Message-ID: Don't know about you, but when I log into my Comcast account I see : *Note:enforcement of the 250GB data consumption threshold is currently suspended * Even then, the 250GB only ever applied for the "slower" accounts. Scott On Sat, Jul 13, 2013 at 9:49 PM, Grant Ridder wrote: > In Mountain View (the middle of Silicon Valley) the only choice i have is > overpriced Comcast w/ a 300 gig limit. I used to chew threw 300 gig in a > week when i was in school. > > -Grant > > On Sat, Jul 13, 2013 at 9:44 PM, Alex Rubenstein > wrote: > > > Yet, here, where I live, only 47 road miles from New York City, I have a > > cable company who sells me metered (yes, METERED) DOCSIS, for nearly > > $100/month, 35/3. The limitation is like 100 GB/month or something (the > > equivalent of the amount of Netflix or AppleTV my kids watch in a > weekend) > > No alternatives, no FiOS, no nothing. Well, I can get 3/.768 DSL if I > > please. > > > > Someone, please help me. > > > > Please. > > > > > > > > > > > > > > Jima said: Really, who has 100/100 at home? > > > > > > Oddly, those living in Grand Coulee, WA. > > > > > > I went there once to setup corporate connectivity for a regional tire > > store. > > > They ordered the minimal drop, 50/50Mbs. One of the tire changers there > > > told me that he had 100/100 at home for $50/month. > > > > > > This was a town without T-Mobile service. I had to haul out the butt > set > > and > > > clip on to the business POTS lines to turn up the VPN. > > > > > > Most of rural Central Washington has very good fiber connectivity. > > Forward > > > looking Public Utility Districts FTW! > > > > > > -- > > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > > From mureninc at gmail.com Sun Jul 14 17:57:13 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 14 Jul 2013 10:57:13 -0700 Subject: One of our own in the Guardian. In-Reply-To: <51E2DBDC.8020808@utc.edu> References: <51E209DD.5020702@jima.us> <51E2DBDC.8020808@utc.edu> Message-ID: On 14 July 2013 10:11, Jeff Kell wrote: > On 7/13/2013 10:15 PM, Jima wrote: >> On 2013-07-13 14:44, Bill Woodcock wrote: >>> http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-nsa >>> >> >> I can happily state that XMission is my home ISP, with UTOPIA >> (city-involved fiber optic provider) as the local loop. (Really, who >> has 100/100 at home?) > > A whole lot of folks in Chattanooga... > https://epbfi.com/enroll/packages/#/fi-speed-internet-100 > > 100Mb symmetric is $69/mo, 250Mb is $139, 1Gbit is $299 > > Largely Alcatel/Lucent GPON. Business rates considerably higher :) > They are one of our providers and we aren't "metered". I don't know how > they're handling domestic rates / quotas. There are a number of 100/100 under $100/mo providers in the US, but most of them are concentrated in various rural areas. I've tried maintaining an up-to-date list of providers with reasonable offers at http://bmap.su/, but lately haven't had the time to keep on updating it. C. From randy at psg.com Sun Jul 14 19:36:35 2013 From: randy at psg.com (Randy Bush) Date: Sun, 14 Jul 2013 09:36:35 -1000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <-4184666514164210262@unknownmsgid> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> Message-ID: my guess is that microsoft was probably more honest than gobble, appeal, etc. so ms looks as if they gave more to the nsa traitors when, in fact, they were all likely in the same rotten boat. randy From wbailey at satelliteintelligencegroup.com Sun Jul 14 19:37:22 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 14 Jul 2013 19:37:22 +0000 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <51E2DBDC.8020808@utc.edu>, Message-ID: I would imagine this cheap rural fiber showed up after the RUS stimulus? A former employer (GCI, in Anchorage Alaska) received quite a bit of money in the form of a grant/loan for a rural fiber network (I think they may have received the largest of all grants). Would be interesting to know how much of this was as a result of dot gov funding. Sent from my Mobile Device. -------- Original message -------- From: "Constantine A. Murenin" Date: 07/14/2013 10:59 AM (GMT-08:00) To: Jeff Kell Cc: nanog at nanog.org Subject: Re: One of our own in the Guardian. On 14 July 2013 10:11, Jeff Kell wrote: > On 7/13/2013 10:15 PM, Jima wrote: >> On 2013-07-13 14:44, Bill Woodcock wrote: >>> http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-nsa >>> >> >> I can happily state that XMission is my home ISP, with UTOPIA >> (city-involved fiber optic provider) as the local loop. (Really, who >> has 100/100 at home?) > > A whole lot of folks in Chattanooga... > https://epbfi.com/enroll/packages/#/fi-speed-internet-100 > > 100Mb symmetric is $69/mo, 250Mb is $139, 1Gbit is $299 > > Largely Alcatel/Lucent GPON. Business rates considerably higher :) > They are one of our providers and we aren't "metered". I don't know how > they're handling domestic rates / quotas. There are a number of 100/100 under $100/mo providers in the US, but most of them are concentrated in various rural areas. I've tried maintaining an up-to-date list of providers with reasonable offers at http://bmap.su/, but lately haven't had the time to keep on updating it. C. From jeff-kell at utc.edu Sun Jul 14 19:49:17 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 14 Jul 2013 15:49:17 -0400 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <51E2DBDC.8020808@utc.edu>, Message-ID: <51E300BD.90204@utc.edu> On 7/14/2013 3:37 PM, Warren Bailey wrote: > I would imagine this cheap rural fiber showed up after the RUS > stimulus? A former employer (GCI, in Anchorage Alaska) received quite > a bit of money in the form of a grant/loan for a rural fiber network > (I think they may have received the largest of all grants). Would be > interesting to know how much of this was as a result of dot gov funding. It's decidedly not yet "rural" but starting to expand beyond simple urban. It is our Electric provider utility, and much of the build out was tied to "Smart Grid" power meter integration. I'm not familiar with the politics, but there were some battles over funding and justification. They are competing with (at least) Comcast/XFinity, AT&T/Uverse, and Charter in the local market. Their initial buildout pre-dated "stimulus funding". We were involved in an earlier effort for "Metro Ethernet" but that didn't work out so well. The more recent GPON is the ongoing success story. Jeff From rgolodner at infratection.com Sun Jul 14 20:37:27 2013 From: rgolodner at infratection.com (Richard Golodner) Date: Sun, 14 Jul 2013 15:37:27 -0500 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> Message-ID: <1373834247.2182.4.camel@Andromeda> On Sun, 2013-07-14 at 09:36 -1000, Randy Bush wrote: > in > fact, they were all likely in the same rotten boat. Why I love open source. Look at my mail, track my web site visits. None of this should come as any surprise, especially to the members of this list. Now for the guy down the street that is working on his 69 Camaro at two in the morning it may have come as a shock. Richard From aaron at wholesaleinternet.net Sun Jul 14 20:45:26 2013 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Sun, 14 Jul 2013 15:45:26 -0500 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <1373834247.2182.4.camel@Andromeda> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> Message-ID: <51E30DE6.5010402@wholesaleinternet.net> On 7/14/2013 3:37 PM, Richard Golodner wrote: > On Sun, 2013-07-14 at 09:36 -1000, Randy Bush wrote: >> in >> fact, they were all likely in the same rotten boat. > > Why I love open source. Look at my mail, track my web site visits. None > of this should come as any surprise, especially to the members of this > list. Now for the guy down the street that is working on his 69 Camaro > at two in the morning it may have come as a shock. > Richard > > We (ISPs) are all compelled to provide information from time to time under a court order. The PRISM program is voluntary. These companies gave the NSA access to their systems voluntarily. To me there is a big difference. I would be interested to know what they got out of it. From patrick at ianai.net Sun Jul 14 22:22:50 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Jul 2013 18:22:50 -0400 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> Message-ID: <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> On Jul 12, 2013, at 19:22 , Nick Khamis wrote: > Set up your own email server, host your own web pages, maintain your own > cloud, breath your own oxygen FTW. That's simply not realistic for many companies and essentially all people (to a first approximation). -- TTFN, patrick From ryangard at gmail.com Sun Jul 14 23:19:49 2013 From: ryangard at gmail.com (ryangard at gmail.com) Date: Sun, 14 Jul 2013 23:19:49 +0000 Subject: Friday Hosing Message-ID: <839679335-1373843984-cardhu_decombobulator_blackberry.rim.net-67204915-@b3.c8.bise6.blackberry> To add to that, I think the interesting point was brought up earlier anyways -- this doesn't stop midstream intercepts from catching traffic in transmission. You can have a secure endpoint, but if the email has to traverse, it's open to being sniffed. ------Original Message------ From: Patrick W. Gilmore To: NANOG list Subject: Re: Friday Hosing Sent: Jul 14, 2013 6:22 PM On Jul 12, 2013, at 19:22 , Nick Khamis wrote: > Set up your own email server, host your own web pages, maintain your own > cloud, breath your own oxygen FTW. That's simply not realistic for many companies and essentially all people (to a first approximation). -- TTFN, patrick Sent on the TELUS Mobility network with BlackBerry From tony at swalter.com Mon Jul 15 00:09:32 2013 From: tony at swalter.com (Tony Patti) Date: Sun, 14 Jul 2013 20:09:32 -0400 Subject: Friday Hosing In-Reply-To: <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> Message-ID: <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> I think it is (could be) (should be) realistic for many/most businesses. TWELVE years ago (press release March 20 2001), Comcast deployed Linux-based Sun Cobalt Qube appliances as CPE with their business-class Internet service, these provided firewall security, web caching, optional content filtering, an e-mail server, a web server, file and print servers. http://www.prnewswire.com/news-releases/comcast-business-communications-hits -a-home-run-with-detroits-comerica-park-71752402.html You could argue that (a) it was not "your own" server, even though it was CPE, or (b) Comcast did not continue to offer these appliances (i.e. that Sun cancelled the product line), but my point is that it was provided within the economics of the Internet Services being purchased, i.e. not cost-prohibitive. Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Sunday, July 14, 2013 6:23 PM To: NANOG list Subject: Re: Friday Hosing On Jul 12, 2013, at 19:22 , Nick Khamis wrote: > Set up your own email server, host your own web pages, maintain your > own cloud, breath your own oxygen FTW. That's simply not realistic for many companies and essentially all people (to a first approximation). -- TTFN, patrick From deleskie at gmail.com Mon Jul 15 00:43:43 2013 From: deleskie at gmail.com (jim deleskie) Date: Sun, 14 Jul 2013 21:43:43 -0300 Subject: Friday Hosing In-Reply-To: <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> Message-ID: I could support any of these services myself, and have guys that work me that can as well, but none of these are my core business, and my investors REALLY prefer me focusing on my core business, I suspect most of us have shareholders, investors, owners that feel the same way. I struggled with idea of not running my own boxes for services, but in the end decided that the trade of various gov't reading my boring office mail was the right choice for my business. -jim On Sun, Jul 14, 2013 at 9:09 PM, Tony Patti wrote: > I think it is (could be) (should be) realistic for many/most businesses. > > TWELVE years ago (press release March 20 2001), Comcast deployed > Linux-based > Sun Cobalt Qube appliances as CPE with their business-class Internet > service, > these provided firewall security, web caching, optional content filtering, > an e-mail server, a web server, file and print servers. > > > http://www.prnewswire.com/news-releases/comcast-business-communications-hits > -a-home-run-with-detroits-comerica-park-71752402.html > > You could argue that > (a) it was not "your own" server, even though it was CPE, or > (b) Comcast did not continue to offer these appliances (i.e. that Sun > cancelled the product line), > but my point is that it was provided within the economics of the Internet > Services being purchased, i.e. not cost-prohibitive. > > Tony Patti > CIO > S. Walter Packaging Corp. > > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Sunday, July 14, 2013 6:23 PM > To: NANOG list > Subject: Re: Friday Hosing > > On Jul 12, 2013, at 19:22 , Nick Khamis wrote: > > > Set up your own email server, host your own web pages, maintain your > > own cloud, breath your own oxygen FTW. > > That's simply not realistic for many companies and essentially all people > (to a first approximation). > > -- > TTFN, > patrick > > > > From tony at swalter.com Mon Jul 15 01:00:13 2013 From: tony at swalter.com (Tony Patti) Date: Sun, 14 Jul 2013 21:00:13 -0400 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> Message-ID: <0ffd01ce80f6$a97acab0$fc706010$@swalter.com> Jim, thanks, certainly understand business priorities. But Patrick's statement was that a business having its own server was "simply not realistic", which I took to be along the dimensions of economically unrealistic or technically unrealistic. In a world of kids growing up with Raspberry Pi's (i.e. their own server to login as root), learning HTML in High School (if not earlier), is it only lack of interest which keeps businesses from having their own server? Is it "realistic" for companies to have an appliance which can provide email and web? Tony Patti CIO S. Walter Packaging Corp. From: jim deleskie [mailto:deleskie at gmail.com] Sent: Sunday, July 14, 2013 8:44 PM To: Tony Patti Cc: NANOG list Subject: Re: Friday Hosing I could support any of these services myself, and have guys that work me that can as well, but none of these are my core business, and my investors REALLY prefer me focusing on my core business, I suspect most of us have shareholders, investors, owners that feel the same way. I struggled with idea of not running my own boxes for services, but in the end decided that the trade of various gov't reading my boring office mail was the right choice for my business. -jim On Sun, Jul 14, 2013 at 9:09 PM, Tony Patti wrote: I think it is (could be) (should be) realistic for many/most businesses. TWELVE years ago (press release March 20 2001), Comcast deployed Linux-based Sun Cobalt Qube appliances as CPE with their business-class Internet service, these provided firewall security, web caching, optional content filtering, an e-mail server, a web server, file and print servers. http://www.prnewswire.com/news-releases/comcast-business-communications-hits -a-home-run-with-detroits-comerica-park-71752402.html You could argue that (a) it was not "your own" server, even though it was CPE, or (b) Comcast did not continue to offer these appliances (i.e. that Sun cancelled the product line), but my point is that it was provided within the economics of the Internet Services being purchased, i.e. not cost-prohibitive. Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Sunday, July 14, 2013 6:23 PM To: NANOG list Subject: Re: Friday Hosing On Jul 12, 2013, at 19:22 , Nick Khamis wrote: > Set up your own email server, host your own web pages, maintain your > own cloud, breath your own oxygen FTW. That's simply not realistic for many companies and essentially all people (to a first approximation). -- TTFN, patrick From nanog at jima.us Mon Jul 15 01:08:16 2013 From: nanog at jima.us (Jima) Date: Sun, 14 Jul 2013 19:08:16 -0600 Subject: One of our own in the Guardian. In-Reply-To: <51E209DD.5020702@jima.us> References: <51E209DD.5020702@jima.us> Message-ID: <51E34B80.4000907@jima.us> On 2013-07-13 20:15, Jima wrote: > I can happily state that XMission is my home ISP, with UTOPIA > (city-involved fiber optic provider) as the local loop. (Really, who > has 100/100 at home?) Thanks to everyone who responded -- my list of places I'm willing to live is rounding out. ;-) XMission does offer 1000/1000, as well; I seem to recall the price is something like $300/mo. For us, the problem was more finding remote sites that can push data rates anywhere near one's own limit (as it's enough of a problem at 100mbit), making the price bump not quite worth it. The unfortunate fallout from having such great service is that I live in fear of having to move outside of a UTOPIA service area, and back to the duopoly providers (Comcast & CenturyLink for the most part here). One might suggest getting XMission over DSL, but CenturyLink has been locking out third-party providers as they've rolled out ADSL2. Jima From jvanoppen at spectrumnet.us Mon Jul 15 01:52:07 2013 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 15 Jul 2013 01:52:07 +0000 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <51E22D36.1020707@viviotech.net>, Message-ID: Yep, that would be us. :) Lots of 100/100 and 1g/1g home Ethernet connections around the Seattle area. :) Joe was a great guy, we miss him still, one of the nicest guys I knew. John van Oppen Spectrum Networks Direct: 206-973-8302 Main: 206-973-8300 ________________________________________ From: Joe Hamelin [joe at nethead.com] Sent: Saturday, July 13, 2013 10:46 PM To: Mark Keymer Cc: NANOG list Subject: Re: One of our own in the Guardian. On Sat, Jul 13, 2013 at 9:46 PM, Mark Keymer wrote: > He might have been talking about Condo Internet if he is in the Seattle > area. They deliver 1Gig connections to your Condo/Apartment, if your in > one of the buildings they service. > I know the guy that does Condo. He was a very good friend of a very good friend of NANOG. Joe Wood (RIP) from Google, Flying Croc, and Wolfe. They were just starting a CLEC in the Puget Sound area when Joe died. Damn, I miss that bastard. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From streiner at cluebyfour.org Mon Jul 15 03:40:29 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 14 Jul 2013 23:40:29 -0400 (EDT) Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <51E30DE6.5010402@wholesaleinternet.net> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> Message-ID: On Sun, 14 Jul 2013, Aaron Wendel wrote: > We (ISPs) are all compelled to provide information from time to time under a > court order. The PRISM program is voluntary. These companies gave the NSA > access to their systems voluntarily. To me there is a big difference. I > would be interested to know what they got out of it. It sounds like many of them were 'compelled' to 'volunteer'. Probably not much, because they really don't have to offer much. I could see Uncle Sam strong-arming carriers who are beholden to the [local/state/ federal] government in some fashion for their ability to operate their businesses (wireless spectrum auctions, state utility commission approvals for XYZ, getting on the approved bidder list for government contracts, etc). I'm also pretty sure the CxOs and legal counsels who reviewed and signed off on whatever agreements the NSA put in front of them won't be talking about the fine print any time soon. jms From joly at punkcast.com Mon Jul 15 03:56:43 2013 From: joly at punkcast.com (Joly MacFie) Date: Sun, 14 Jul 2013 23:56:43 -0400 Subject: One of our own in the Guardian. In-Reply-To: <51E300BD.90204@utc.edu> References: <51E209DD.5020702@jima.us> <51E2DBDC.8020808@utc.edu> <51E300BD.90204@utc.edu> Message-ID: On Sun, Jul 14, 2013 at 3:49 PM, Jeff Kell wrote: > It is our Electric provider utility, and much of the build out > was tied to "Smart Grid" power meter integration. I'm not familiar with > the politics, but there were some battles over funding and > justification. > Power Utility issues vis-a-vis fiber were discussed by James Salter at this years F2c http://www.youtube.com/watch?v=04b-IzSRh0M&list=PLuVpWA96MxueWSaBIonLaoJBb6KHM6qGj&index=8 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From jeff-kell at utc.edu Mon Jul 15 05:49:57 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 15 Jul 2013 01:49:57 -0400 Subject: One of our own in the Guardian. In-Reply-To: <51E34B80.4000907@jima.us> References: <51E209DD.5020702@jima.us> <51E34B80.4000907@jima.us> Message-ID: <51E38D85.6060702@utc.edu> On 7/14/2013 9:08 PM, Jima wrote: > XMission does offer 1000/1000, as well; I seem to recall the price is > something like $300/mo. For us, the problem was more finding remote > sites that can push data rates anywhere near one's own limit (as it's > enough of a problem at 100mbit), making the price bump not quite worth it. Very true. We have two gigs, but a commercial speedtest comes up seriously short (typically 100+ Mbps) while a locally hosted speedtest will show 800-900+. Not sure how much is "their" upstream versus simple physics... you'd have to be the only test subject to a gig-connected server to do much better. We have had some "contrived" examples over I2 that pushed 500Mbps symmetric, but they ran that demo over our I2 pipe because their commodity link couldn't deliver the necessary rate/latency. Jeff From jvanoppen at spectrumnet.us Mon Jul 15 08:16:24 2013 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 15 Jul 2013 08:16:24 +0000 Subject: One of our own in the Guardian. In-Reply-To: <51E38D85.6060702@utc.edu> References: <51E209DD.5020702@jima.us> <51E34B80.4000907@jima.us> <51E38D85.6060702@utc.edu> Message-ID: To be honest, that is the problem with most smaller ISPs, their uplinks are not all 10G... The only way to have users who reliably get high speed tests is to make sure one does not have 1G upstream links but obviously for a smaller provider that would not be an option. I think this is why our retail service routinely is in the top few on the public speed test sites in the US... The (obvious) secret is having more than 1G of headroom on every link to the world and using a lot of 10G internally. From my testing on my home link to our network and a bunch of customer links, public speed tests of above 800 mbit/sec on gigE are pretty achievable assuming the testing server is in the same metro and well provisioned (IE not on a tiny ISP). John -----Original Message----- From: Jeff Kell [mailto:jeff-kell at utc.edu] Sent: Sunday, July 14, 2013 10:50 PM To: Jima Cc: nanog at nanog.org Subject: Re: One of our own in the Guardian. On 7/14/2013 9:08 PM, Jima wrote: > XMission does offer 1000/1000, as well; I seem to recall the price is > something like $300/mo. For us, the problem was more finding remote > sites that can push data rates anywhere near one's own limit (as it's > enough of a problem at 100mbit), making the price bump not quite worth it. Very true. We have two gigs, but a commercial speedtest comes up seriously short (typically 100+ Mbps) while a locally hosted speedtest will show 800-900+. Not sure how much is "their" upstream versus simple physics... you'd have to be the only test subject to a gig-connected server to do much better. We have had some "contrived" examples over I2 that pushed 500Mbps symmetric, but they ran that demo over our I2 pipe because their commodity link couldn't deliver the necessary rate/latency. Jeff From nickguy at noanet.net Mon Jul 15 02:14:32 2013 From: nickguy at noanet.net (Nick Guy) Date: Mon, 15 Jul 2013 02:14:32 +0000 Subject: One of our own in the Guardian. In-Reply-To: Message-ID: X2 on Joe. ---Nick On 7/14/13 6:52 PM, "John van Oppen" wrote: >Yep, that would be us. :) Lots of 100/100 and 1g/1g home Ethernet >connections around the Seattle area. :) > >Joe was a great guy, we miss him still, one of the nicest guys I knew. > >John van Oppen >Spectrum Networks >Direct: 206-973-8302 >Main: 206-973-8300 > >________________________________________ >From: Joe Hamelin [joe at nethead.com] >Sent: Saturday, July 13, 2013 10:46 PM >To: Mark Keymer >Cc: NANOG list >Subject: Re: One of our own in the Guardian. > >On Sat, Jul 13, 2013 at 9:46 PM, Mark Keymer wrote: > >> He might have been talking about Condo Internet if he is in the Seattle >> area. They deliver 1Gig connections to your Condo/Apartment, if your in >> one of the buildings they service. >> > >I know the guy that does Condo. He was a very good friend of a very good >friend of NANOG. Joe Wood (RIP) from Google, Flying Croc, and Wolfe. They >were just starting a CLEC in the Puget Sound area when Joe died. > >Damn, I miss that bastard. > >-- >Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > From cfp at ruxcon.org.au Mon Jul 15 03:54:30 2013 From: cfp at ruxcon.org.au (cfp at ruxcon.org.au) Date: Mon, 15 Jul 2013 13:54:30 +1000 (EST) Subject: Ruxcon 2013 Final Call For Papers Message-ID: <20130715035430.03ED92EE45@ruxcon.com.au> Ruxcon 2013 Final Call For Papers Melbourne, Australia, October 26th-27th CQ Function Centre http://www.ruxcon.org.au/call-for-papers/ The Ruxcon team is pleased to announce the final call for papers for Ruxcon. This year the conference will take place over the weekend of the 26th and 27th of October at the CQ Function Centre, Melbourne, Australia. The deadline for submissions is the 31st of August. .[x]. About Ruxcon .[x]. Ruxcon is ia premier technical computer security conference in the Australia. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations. The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security. For more information, please visit the http://www.ruxcon.org.au .[x]. Important Dates .[x]. August 31 - Call For Presentations Close October 26-27 - Ruxcon Conference .[x]. Topic Scope .[x]. o Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) .[x]. Submission Guidelines .[x]. In order for us to process your submission we require the following information: 1. Presentation title 2. Detailed summary of your presentation material 3. Name/Nickname 4. Mobile phone number 5. Brief personal biography 6. Description of any demonstrations involved in the presentation 7. Information on where the presentation material has or will be presented before Ruxcon * As a general guideline, Ruxcon presentations are between 45 and 60 minutes, including question time. If you have any enquiries about submissions, or would like to make a submission, please send an email to presentations at ruxcon.org.au The deadline for submissions is the 31st of August. .[x]. Contact .[x]. o Email: presentations at ruxcon.org.au o Twitter: @ruxcon From sylvie at newnog.org Mon Jul 15 11:16:17 2013 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Mon, 15 Jul 2013 07:16:17 -0400 Subject: [NANOG-announce] Announcing the October 2013 NANOG Elections Message-ID: Hello NANOGers! This message is to encourage you, as a participant of this community, to become NANOG members and to consider standing for a leadership position at our upcoming October elections. The call for Board members nominations will be from August 9 to September 20 and for committee members from September 12 to October 8. We wanted to provide you now with the election process preview. It?s posted at http://www.nanog.org/governance/elections/2013 and we?ll make announcements at every step. Why should you become a NANOG member? One Member = One Voter = One Eligible Candidate Candidate and Voter eligibility are opened to every ?member in good standing?. You may never have attended a conference but as an active reader and poster on our mailing lists, you contribute to the knowledge of this community. Becoming a NANOG member gives you the right to stand for a position and to vote in October. You can join at http://www.nanog.org/membership/join. What is expected of Committee Candidates? How many vacant positions? In New Orleans, we reminded the community of the documented set of roles, responsibilities and expectations placed on each position. We trust you will find the following useful. Candidates will be appointed Committee members by the newly elected Board next October. * 3 vacancies: Communications Committee Member - Refer to CC Responsibilities * 3 vacancies: Development Committee Member - Refer to DC Responsibilities * 8 vacancies: Program Committee Member - Refer to PC Responsibilities What is expected of a Board Candidate? How many vacant positions? Read the Board Member Responsibilities and NANOG by-laws for a complete understanding of the expectations placed on Board Members. Board Member Responsibilities NANOG By-laws To ensure continuity on the Board, three seats out of six become open each year due to the expiration of 2-year terms. The Board members whose terms are expiring in October are: * Steve Gibbard * Sylvie LaPerriere * Duane Wessels Sylvie and Duane have served two 2-year terms and cannot be considered for re-election until October 2014 (one year leave). Steve is completing his first two year term and he can stand for re-election. How do you Nominate? You can self-nominate. You care about NANOG?s governance and want to take a turn at volunteering your time and expertise to help make it better. 1. Make sure you are a NANOG member in good standing 2. Submit your Declaration of Candidacy to elections at nanog.org. You can nominate others. 1. Send their contact information to elections at nanog.org 2. If they accept the nomination, they will be asked to become a NANOG member in good standing 3. They will have to submit their Declaration of Candidacy to elections at nanog.org. As NANOG continues to evolve, our Board and our Committees will continue to play an increasingly important role in our success. We thank you in advance for becoming NANOG members and taking an active part in our governance. Best regards, Sylvie, on behalf of the NANOG Board of Directors -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From Valdis.Kletnieks at vt.edu Mon Jul 15 14:11:20 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 15 Jul 2013 10:11:20 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: Your message of "Sun, 14 Jul 2013 15:45:26 -0500." <51E30DE6.5010402@wholesaleinternet.net> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> Message-ID: <11286.1373897480@turing-police.cc.vt.edu> On Sun, 14 Jul 2013 15:45:26 -0500, Aaron Wendel said: > We (ISPs) are all compelled to provide information from time to time > under a court order. The PRISM program is voluntary. Ask the ex-CEO of Qwest how "voluntary" that sort of stuff is. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From morrowc.lists at gmail.com Mon Jul 15 14:32:59 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Jul 2013 10:32:59 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <11286.1373897480@turing-police.cc.vt.edu> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> Message-ID: On Mon, Jul 15, 2013 at 10:11 AM, wrote: > On Sun, 14 Jul 2013 15:45:26 -0500, Aaron Wendel said: > >> We (ISPs) are all compelled to provide information from time to time >> under a court order. The PRISM program is voluntary. > > Ask the ex-CEO of Qwest how "voluntary" that sort of stuff is. it REALLY depends on what 'prisim' is... seen in one light, the program is 'just' isp/asp people who agree to permit FISA requests to be satisfied via: "scp files from fisa.isp.net with key fingerprint 0xasdasdasd" of course, the other way to read it (as the news would like us to believe) is as: "plug nsa ethernet into eth1 of all servers and routers, kthxbi!" more details would certainly make this whole conversation less alamist and more rational. -chris From Rbergma at gcpud.org Mon Jul 15 15:29:24 2013 From: Rbergma at gcpud.org (Robert Bergman) Date: Mon, 15 Jul 2013 08:29:24 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> Message-ID: <8FF168ED9A755F47A9F3399FFECFF077021B12EA91@Dollarbird.gcpud.org> Nice to see our network talked about on here :0) -----Original Message----- From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Saturday, July 13, 2013 9:33 PM To: Joe Hamelin Cc: NANOG list Subject: Re: One of our own in the Guardian. Someone I know in Washington state has 100/100 at home and made the comment to me a year ago that it was one of the slower speeds offered. I am not sure who his ISP is however. -Grant On Sat, Jul 13, 2013 at 9:20 PM, Joe Hamelin wrote: > Jima said: Really, who has 100/100 at home? > > Oddly, those living in Grand Coulee, WA. > > I went there once to setup corporate connectivity for a regional tire > store. They ordered the minimal drop, 50/50Mbs. One of the tire > changers there told me that he had 100/100 at home for $50/month. > > This was a town without T-Mobile service. I had to haul out the butt > set and clip on to the business POTS lines to turn up the VPN. > > Most of rural Central Washington has very good fiber connectivity. > Forward looking Public Utility Districts FTW! > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From Rbergma at gcpud.org Mon Jul 15 15:33:57 2013 From: Rbergma at gcpud.org (Robert Bergman) Date: Mon, 15 Jul 2013 08:33:57 -0700 Subject: One of our own in the Guardian. In-Reply-To: References: <51E209DD.5020702@jima.us> <51E2DBDC.8020808@utc.edu>, Message-ID: <8FF168ED9A755F47A9F3399FFECFF077021B12EA96@Dollarbird.gcpud.org> I'm happy to say we did not use federal or state money to build the fiber or the network in Grant County. There is some of that floating around us though. -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Sunday, July 14, 2013 12:37 PM To: Constantine A. Murenin; Jeff Kell Cc: nanog at nanog.org Subject: Re: One of our own in the Guardian. I would imagine this cheap rural fiber showed up after the RUS stimulus? A former employer (GCI, in Anchorage Alaska) received quite a bit of money in the form of a grant/loan for a rural fiber network (I think they may have received the largest of all grants). Would be interesting to know how much of this was as a result of dot gov funding. Sent from my Mobile Device. -------- Original message -------- From: "Constantine A. Murenin" Date: 07/14/2013 10:59 AM (GMT-08:00) To: Jeff Kell Cc: nanog at nanog.org Subject: Re: One of our own in the Guardian. On 14 July 2013 10:11, Jeff Kell wrote: > On 7/13/2013 10:15 PM, Jima wrote: >> On 2013-07-13 14:44, Bill Woodcock wrote: >>> http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-p >>> rivacy-nsa >>> >> >> I can happily state that XMission is my home ISP, with UTOPIA >> (city-involved fiber optic provider) as the local loop. (Really, who >> has 100/100 at home?) > > A whole lot of folks in Chattanooga... > https://epbfi.com/enroll/packages/#/fi-speed-internet-100 > > 100Mb symmetric is $69/mo, 250Mb is $139, 1Gbit is $299 > > Largely Alcatel/Lucent GPON. Business rates considerably higher :) > They are one of our providers and we aren't "metered". I don't know > how they're handling domestic rates / quotas. There are a number of 100/100 under $100/mo providers in the US, but most of them are concentrated in various rural areas. I've tried maintaining an up-to-date list of providers with reasonable offers at http://bmap.su/, but lately haven't had the time to keep on updating it. C. From nickguy at noanet.net Mon Jul 15 15:53:01 2013 From: nickguy at noanet.net (Nick Guy) Date: Mon, 15 Jul 2013 15:53:01 +0000 Subject: One of our own in the Guardian. In-Reply-To: <8FF168ED9A755F47A9F3399FFECFF077021B12EA96@Dollarbird.gcpud.org> References: <51E209DD.5020702@jima.us> <51E2DBDC.8020808@utc.edu>, <8FF168ED9A755F47A9F3399FFECFF077021B12EA96@Dollarbird.gcpud.org> Message-ID: <37048bc8358c49378f791c438c107b9f@CO1PR07MB127.namprd07.prod.outlook.com> Many of the Washington state PUDs very early in the day took on the charge of delivering "broadband" to places that the telco's did not see ROI for. It did and still does make sense to deliver fiber along with power to the home but that is the kind of long term thinking that can be costly up front for future improved quality of life. Nice to see some acknowledgement on the list of that vision. +-----------------------------------------------------------------------------------------+ Nick Guy | Network Architecture | NoaNet | nickguy at noanet.net| +-----------------------------------------------------------------------------------------+ -----Original Message----- From: Robert Bergman [mailto:Rbergma at gcpud.org] Sent: Monday, July 15, 2013 8:34 AM To: Warren Bailey; Constantine A. Murenin; Jeff Kell Cc: nanog at nanog.org Subject: RE: One of our own in the Guardian. I'm happy to say we did not use federal or state money to build the fiber or the network in Grant County. There is some of that floating around us though. -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Sunday, July 14, 2013 12:37 PM To: Constantine A. Murenin; Jeff Kell Cc: nanog at nanog.org Subject: Re: One of our own in the Guardian. I would imagine this cheap rural fiber showed up after the RUS stimulus? A former employer (GCI, in Anchorage Alaska) received quite a bit of money in the form of a grant/loan for a rural fiber network (I think they may have received the largest of all grants). Would be interesting to know how much of this was as a result of dot gov funding. Sent from my Mobile Device. -------- Original message -------- From: "Constantine A. Murenin" Date: 07/14/2013 10:59 AM (GMT-08:00) To: Jeff Kell Cc: nanog at nanog.org Subject: Re: One of our own in the Guardian. On 14 July 2013 10:11, Jeff Kell wrote: > On 7/13/2013 10:15 PM, Jima wrote: >> On 2013-07-13 14:44, Bill Woodcock wrote: >>> http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-p >>> rivacy-nsa >>> >> >> I can happily state that XMission is my home ISP, with UTOPIA >> (city-involved fiber optic provider) as the local loop. (Really, who >> has 100/100 at home?) > > A whole lot of folks in Chattanooga... > https://epbfi.com/enroll/packages/#/fi-speed-internet-100 > > 100Mb symmetric is $69/mo, 250Mb is $139, 1Gbit is $299 > > Largely Alcatel/Lucent GPON. Business rates considerably higher :) > They are one of our providers and we aren't "metered". I don't know > how they're handling domestic rates / quotas. There are a number of 100/100 under $100/mo providers in the US, but most of them are concentrated in various rural areas. I've tried maintaining an up-to-date list of providers with reasonable offers at http://bmap.su/, but lately haven't had the time to keep on updating it. C. From wbailey at satelliteintelligencegroup.com Mon Jul 15 16:17:27 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 15 Jul 2013 16:17:27 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu>, Message-ID: I don't think the conversation is based around the method by which information is intercepted. I hope the conversation is aligned with its reasoning for disclosure - the American people stopping a government who is known for abusing it's power. Obviously this does not mean physically stopping them, but I imagine most people know what motivates their state and national political officials. I still wonder why Mr. Snowden hasn't dropped more damaging information, it would seem his sworn enemy has made their feelings somewhat clear. Sent from my Mobile Device. -------- Original message -------- From: Christopher Morrow Date: 07/15/2013 7:34 AM (GMT-08:00) To: Valdis Kletnieks Cc: nanog list Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages On Mon, Jul 15, 2013 at 10:11 AM, wrote: > On Sun, 14 Jul 2013 15:45:26 -0500, Aaron Wendel said: > >> We (ISPs) are all compelled to provide information from time to time >> under a court order. The PRISM program is voluntary. > > Ask the ex-CEO of Qwest how "voluntary" that sort of stuff is. it REALLY depends on what 'prisim' is... seen in one light, the program is 'just' isp/asp people who agree to permit FISA requests to be satisfied via: "scp files from fisa.isp.net with key fingerprint 0xasdasdasd" of course, the other way to read it (as the news would like us to believe) is as: "plug nsa ethernet into eth1 of all servers and routers, kthxbi!" more details would certainly make this whole conversation less alamist and more rational. -chris From Andy.Litzinger at theplatform.com Mon Jul 15 21:18:52 2013 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Mon, 15 Jul 2013 21:18:52 +0000 Subject: tools and techniques to pinpoint and respond to loss on a path Message-ID: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> Hi, Does anyone have any recommendations on how to pinpoint and react to packet loss across the internet? preferably in an automated fashion. For detection I'm currently looking at trying smoketrace to run from inside my network, but I'd love to be able to run traceroutes from my edge routers triggered during periods of loss. I have Juniper MX80s on one end- which I'm hopeful I'll be able to cobble together some combo of RPM and event scripting to kick off a traceroute. We have Cisco4900Ms on the other end and maybe the same thing is possible but I'm not so sure. I'd love to hear other suggestions and experience for detection and also for options on what I might be able to do when loss is detected on a path. In my specific situation I control equipment on both ends of the path that I care about with details below. we are a hosted service company and we currently have two data centers, DC A and DC B. DC A uses juniper MX routers, advertises our own IP space and takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we have a smaller installation and instead take redundant drops (and IP space) from a single provider, ISP B1, who then peers upstream with two providers, B2 and B3 We have a fairly consistent bi-directional stream of traffic between DC A and DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under normal network conditions traffic flows across ISP B1 to B2 and then to either ISP A1 or A2 oversimplified ascii pic showing only the normal best paths: -- ISP A1----------------------ISP B2-- DC A--| |--- ISP B1 ----- DC B -- ISP A2----------------------ISP B2-- with increasing frequency we've been experiencing packet loss along the path from DC A to DC B. Usually the periods of loss are brief, 30 seconds to a minute, but they are total blackouts. I'd like to be able to collect enough relevant data to pinpoint the trouble spot as much as possible so I can take it to the ISPs and request a solution. The blackouts are so quick that it's impossible to log in and get a trace- hence the desire to automate it. I can provide more details off list if helpful- I'm trying not to vilify anyone- especially without copious amounts of data points. As a side question, what should my expectation be regarding packet loss when sending packets from point A to point B across multiple providers across the internet? Is 30 seconds to a minute of blackout between two destinations every couple of weeks par for the course? My directly connected ISPs offer me an SLA, but what should I reasonably expect from them when one of their upstream peers (or a peer of their peers) has issues? If this turns out to be BGP reconvergence or similar do I have any options? many thanks, -andy From jared at puck.nether.net Mon Jul 15 21:30:42 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 15 Jul 2013 17:30:42 -0400 Subject: tools and techniques to pinpoint and respond to loss on a path In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> Message-ID: <723447E1-AF89-49FA-BBD0-0616920F8C27@puck.nether.net> On Jul 15, 2013, at 5:18 PM, Andy Litzinger wrote: > I'd like to be able to collect enough relevant data to pinpoint the trouble spot as much as possible so I can take it to the ISPs and request a solution. The blackouts are so quick that it's impossible to log in and get a trace- hence the desire to automate it. > > I can provide more details off list if helpful- I'm trying not to vilify anyone- especially without copious amounts of data points. > > As a side question, what should my expectation be regarding packet loss when sending packets from point A to point B across multiple providers across the internet? Is 30 seconds to a minute of blackout between two destinations every couple of weeks par for the course? My directly connected ISPs offer me an SLA, but what should I reasonably expect from them when one of their upstream peers (or a peer of their peers) has issues? If this turns out to be BGP reconvergence or similar do I have any options? I think there are a number of tools available to detect if something is happening: 1) iperf (test network/bw usage) 2) owamp (one way ping) - you can use this to detect when reordering or other events happen.. this will collect nearly continuious data. requires good ntp references, or accepting you may see skewed data. 3) some other udp/low latency responder. i've built something of my own that does this, i can provide a pointer if you are interested. i have graphs of my connection at home to someplace remote that crosses 3 carriers. you can see the queuing delay increment throughout the day until peak times and taper off at night. no loss, but the increase is quite visible. 4) some vendor SLA/SAA product. Cisco and others have SAA responders that work on their devices you can configure to collect data. That being said, losing network for 30 seconds once every 2 weeks I would expect is fairly common. Someone will be doing network upgrades/work or there will be hardware/transmission error, etc. 30 seconds sounds a lot like bgp convergence, and in older platforms, eg: 6500/sup720 expect about 8k prefixes/second max to be downloaded into the tcam/fib. with 400k+ prefixes, it takes awhile to pump the tables into the forwarding side. - Jared From ikiris at gmail.com Mon Jul 15 21:38:47 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 15 Jul 2013 16:38:47 -0500 Subject: tools and techniques to pinpoint and respond to loss on a path In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> Message-ID: Personally I would never expect simple routed connectivity across the public internet to be such a high level of reliability, without at least diverse path tunnels running route protocols internally. While any provider will attempt to fix peer / upstream issues as they can, any SLA you would have is between two points on their private network, not from point A to point Z that they have no control over across multiple peers and the public internet itself. The much more common design is using a single provider for each thread between sites. Then at least you have an end-to-end SLA in effect, as well as a single entity that is responsible for the entire link in question. This sounds like you're trying to achieve private link IGP / FRR level site to site failover/convergence across the public internet. Perhaps you should rethink your goals here or your design? -Blake On Mon, Jul 15, 2013 at 4:18 PM, Andy Litzinger < Andy.Litzinger at theplatform.com> wrote: > Hi, > > Does anyone have any recommendations on how to pinpoint and react to > packet loss across the internet? preferably in an automated fashion. For > detection I'm currently looking at trying smoketrace to run from inside my > network, but I'd love to be able to run traceroutes from my edge routers > triggered during periods of loss. I have Juniper MX80s on one end- which > I'm hopeful I'll be able to cobble together some combo of RPM and event > scripting to kick off a traceroute. We have Cisco4900Ms on the other end > and maybe the same thing is possible but I'm not so sure. > > I'd love to hear other suggestions and experience for detection and also > for options on what I might be able to do when loss is detected on a path. > > In my specific situation I control equipment on both ends of the path that > I care about with details below. > > we are a hosted service company and we currently have two data centers, DC > A and DC B. DC A uses juniper MX routers, advertises our own IP space and > takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we have a > smaller installation and instead take redundant drops (and IP space) from a > single provider, ISP B1, who then peers upstream with two providers, B2 and > B3 > > We have a fairly consistent bi-directional stream of traffic between DC A > and DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under > normal network conditions traffic flows across ISP B1 to B2 and then to > either ISP A1 or A2 > > oversimplified ascii pic showing only the normal best paths: > > -- ISP A1----------------------ISP B2-- > DC A--| > |--- ISP B1 ----- DC B > -- ISP A2----------------------ISP B2-- > > > with increasing frequency we've been experiencing packet loss along the > path from DC A to DC B. Usually the periods of loss are brief, 30 seconds > to a minute, but they are total blackouts. > > I'd like to be able to collect enough relevant data to pinpoint the > trouble spot as much as possible so I can take it to the ISPs and request a > solution. The blackouts are so quick that it's impossible to log in and > get a trace- hence the desire to automate it. > > I can provide more details off list if helpful- I'm trying not to vilify > anyone- especially without copious amounts of data points. > > As a side question, what should my expectation be regarding packet loss > when sending packets from point A to point B across multiple providers > across the internet? Is 30 seconds to a minute of blackout between two > destinations every couple of weeks par for the course? My directly > connected ISPs offer me an SLA, but what should I reasonably expect from > them when one of their upstream peers (or a peer of their peers) has > issues? If this turns out to be BGP reconvergence or similar do I have any > options? > > many thanks, > -andy > > From eugen at imacandi.net Tue Jul 16 05:42:53 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 16 Jul 2013 08:42:53 +0300 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> Message-ID: Dropping everything at once may dilute the debate as I am sure your government and every other government that may be proved to be involved will try to focus the discussion on small and less damaging issues until the bigger ones are forgotten. Reveal something, wait a few weeks/months, reveal something else may keep the debate open for longer time and at some point maybe enough critical mass is attained where something can be achieved. On Mon, Jul 15, 2013 at 7:17 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > I don't think the conversation is based around the method by which > information is intercepted. I hope the conversation is aligned with its > reasoning for disclosure - the American people stopping a government who is > known for abusing it's power. Obviously this does not mean physically > stopping them, but I imagine most people know what motivates their state > and national political officials. I still wonder why Mr. Snowden hasn't > dropped more damaging information, it would seem his sworn enemy has made > their feelings somewhat clear. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Christopher Morrow > Date: 07/15/2013 7:34 AM (GMT-08:00) > To: Valdis Kletnieks > Cc: nanog list > Subject: Re: Office 365..? how Microsoft handed the NSA access to > encrypted messages > > > On Mon, Jul 15, 2013 at 10:11 AM, wrote: > > On Sun, 14 Jul 2013 15:45:26 -0500, Aaron Wendel said: > > > >> We (ISPs) are all compelled to provide information from time to time > >> under a court order. The PRISM program is voluntary. > > > > Ask the ex-CEO of Qwest how "voluntary" that sort of stuff is. > > it REALLY depends on what 'prisim' is... seen in one light, the > program is 'just' isp/asp people who agree to permit FISA requests to > be satisfied via: "scp files from fisa.isp.net with key fingerprint > 0xasdasdasd" > > of course, the other way to read it (as the news would like us to > believe) is as: "plug nsa ethernet into eth1 of all servers and > routers, kthxbi!" > > more details would certainly make this whole conversation less alamist > and more rational. > -chris > > From oscar.vives at gmail.com Tue Jul 16 08:17:46 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Tue, 16 Jul 2013 10:17:46 +0200 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> Message-ID: It would be fun to make a encryptation keyboard. A keyboard that add the text you write to a buffer, and wen the buffer is full, output it to the computer encrypted. Maybe with pgp. Such machine would probably need a led with the text you are writing. That way, you coud be using Google Docs or Office 365. And the computer OS can have a keylogger and a backdoor. And you will still be somewhat safe if pgp provide you with strong enough level of encryptation. -- -- ?in del ?ensaje. From dave at temk.in Tue Jul 16 14:21:40 2013 From: dave at temk.in (David Temkin) Date: Tue, 16 Jul 2013 10:21:40 -0400 Subject: NANOG 59 - Important Schedule Notice & Call For Presentations. Please read! In-Reply-To: References: Message-ID: Reminder - submissions are due 30 days from today. The sooner the better, as it gives the Program Committee more time to help submitters refine their presentations for the NANOG audience. Regards, -Dave On Mon, Jun 17, 2013 at 3:33 PM, David Temkin wrote: > NANOG Community, > > I hope everyone enjoyed New Orleans as much as I did! It's truly one of > my favorite cities in the world. Fresh off a great meeting, we're already > starting to get ready for NANOG 59 in Phoenix. If you have a topic you'd > like to speak about, the program committee would love to consider it. > Please watch http://www.nanog.org/meetings/nanog59/callforpresentations for > more information. > > After considering feedback from members, speakers, ARIN, and sponsors we > have decided to make a small tweak to the program timing at NANOG 59. We > will continue with the Monday-Wednesday format, however we will move the > ARIN Track and Tutorials to Tuesday morning, highlighting their importance > to the program. The program will begin on Monday morning at 10:00AM > followed by our popular Newcomers Lunch. The exact schedule layout can be > found at http://www.nanog.org/meetings/nanog59/preagenda and is also > attached in JPG format to this email. > > > If you wish to submit a presentation, please keep these important dates > in mind: > > > Presentation Abstracts and Draft Slides Due: 16-Aug-2013 > Slides Due: > 30-Aug-2013 > Topic List Posted: > 06-Sep-2013 > Final Agenda Published: > 27-Sep-2013 > > Please submit your materials to http://pc.nanog.org > > Looking forward to seeing everyone in Phoenix! > > -Dave Temkin > > (Chair, NANOG Program Committee) > > From james.sink at freedomvoice.com Tue Jul 16 15:52:54 2013 From: james.sink at freedomvoice.com (James Sink) Date: Tue, 16 Jul 2013 15:52:54 +0000 Subject: tools and techniques to pinpoint and respond to loss on a path In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> Message-ID: Have you looked into Cisco's OER? -James -----Original Message----- From: Andy Litzinger [mailto:Andy.Litzinger at theplatform.com] Sent: Monday, July 15, 2013 2:19 PM To: nanog at nanog.org Subject: tools and techniques to pinpoint and respond to loss on a path Hi, Does anyone have any recommendations on how to pinpoint and react to packet loss across the internet? preferably in an automated fashion. For detection I'm currently looking at trying smoketrace to run from inside my network, but I'd love to be able to run traceroutes from my edge routers triggered during periods of loss. I have Juniper MX80s on one end- which I'm hopeful I'll be able to cobble together some combo of RPM and event scripting to kick off a traceroute. We have Cisco4900Ms on the other end and maybe the same thing is possible but I'm not so sure. I'd love to hear other suggestions and experience for detection and also for options on what I might be able to do when loss is detected on a path. In my specific situation I control equipment on both ends of the path that I care about with details below. we are a hosted service company and we currently have two data centers, DC A and DC B. DC A uses juniper MX routers, advertises our own IP space and takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we have a smaller installation and instead take redundant drops (and IP space) from a single provider, ISP B1, who then peers upstream with two providers, B2 and B3 We have a fairly consistent bi-directional stream of traffic between DC A and DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under normal network conditions traffic flows across ISP B1 to B2 and then to either ISP A1 or A2 oversimplified ascii pic showing only the normal best paths: -- ISP A1----------------------ISP B2-- DC A--| |--- ISP B1 ----- DC B -- ISP A2----------------------ISP B2-- with increasing frequency we've been experiencing packet loss along the path from DC A to DC B. Usually the periods of loss are brief, 30 seconds to a minute, but they are total blackouts. I'd like to be able to collect enough relevant data to pinpoint the trouble spot as much as possible so I can take it to the ISPs and request a solution. The blackouts are so quick that it's impossible to log in and get a trace- hence the desire to automate it. I can provide more details off list if helpful- I'm trying not to vilify anyone- especially without copious amounts of data points. As a side question, what should my expectation be regarding packet loss when sending packets from point A to point B across multiple providers across the internet? Is 30 seconds to a minute of blackout between two destinations every couple of weeks par for the course? My directly connected ISPs offer me an SLA, but what should I reasonably expect from them when one of their upstream peers (or a peer of their peers) has issues? If this turns out to be BGP reconvergence or similar do I have any options? many thanks, -andy From wbailey at satelliteintelligencegroup.com Tue Jul 16 16:28:33 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 16 Jul 2013 16:28:33 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> , Message-ID: <4lvavouqi7eoy33mysm8vqxe.1373992098882@email.android.com> Or you could send emails that people cannot reply to, that would stop them dead in their tracks.. ;) Sent from my Mobile Device. -------- Original message -------- From: Date: 07/16/2013 1:20 AM (GMT-08:00) To: Cc: nanog list Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages It would be fun to make a encryptation keyboard. A keyboard that add the text you write to a buffer, and wen the buffer is full, output it to the computer encrypted. Maybe with pgp. Such machine would probably need a led with the text you are writing. That way, you coud be using Google Docs or Office 365. And the computer OS can have a keylogger and a backdoor. And you will still be somewhat safe if pgp provide you with strong enough level of encryptation. -- -- ?in del ?ensaje. From damian at google.com Tue Jul 16 16:34:53 2013 From: damian at google.com (Damian Menscher) Date: Tue, 16 Jul 2013 09:34:53 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> Message-ID: j304p0:)XrL`E7etWo?=?Ww'&h#w8D2M;TCx50AId0jEbRL\oO9KVc.r8aj00k!5K6lpF;*< gNSd9>S0{79Vl3Gk-KD`#eCc]/]'d5GJ::E_jKOYSrCp]%^)\y{[Sc10*SX-T~mUS1l+jA&1F*&Pll>U?\UoF](qj~H31r==?|ul*v.o1zo3P!;A^*r"}}JXo,6fkw[W!{z[}3,_vavM#pi6&ND&.60O&Q,WX>8k**50\}` 44z:ROxc&Tn1}TjR?TaB^$ '~Bds2~+LVfz/,,y|*f8^slMA])gbPlo?bWlo3yED`y&%!6_j**KZlY>-ME2%eV*L8:#Pl"\E$Toz0u`]3 oWD^W\X\,^c_n'b\au_zQufQ6Gl u"~_GH|^uuDx.H=LF at M2eT~5Y>> wrote: > It would be fun to make a encryptation keyboard. A keyboard that add > the text you write to a buffer, and wen the buffer is full, output it > to the computer encrypted. Maybe with pgp. Such machine would > probably need a led with the text you are writing. > > That way, you coud be using Google Docs or Office 365. And the > computer OS can have a keylogger and a backdoor. And you will still > be somewhat safe if pgp provide you with strong enough level of > encryptation. > > -- > -- > ?in del ?ensaje. > > From malayter at gmail.com Tue Jul 16 16:40:50 2013 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 16 Jul 2013 11:40:50 -0500 Subject: Secure Tunneling. Only with more Control!!! In-Reply-To: References: Message-ID: On Sat, Jul 13, 2013 at 8:36 AM, Nick Khamis wrote: > This just got very interesting. Given that we do not own any Microsoft > products here, and still able to function like any other corporation, > I am more interested in a "solution that you have more control over" > secured connections. We currently are using OpenVPN and PKI, coupled > with a company policy of key updates every 3 months this will only get > incrementally more complex as the number of clients increase. Not to > mention one only needs a 3 minutes.... > > Question: What other options do we have to maintain a secure > connection between client and server that gives us more control over > traditional OpenVPN+PKI. It would be nice to be able to deploy private > keys automatically to the different clients however, seems like a > disaster waiting to happen. > > I would really appreciate some of your takes on this matter, what > types of technology, policies are being employed out there for secure > connections. Your current solutions sounds entirely reasonable... except your clients still surf the web, don't they? That is the biggest attack vector: browser and other client program exploits are rampant on *all platforms*. Witness the multitudes of image library bugs on Linux, which basically have allowed remote execution via webpage with a crafted image since the early 1990s. Every browser and OS combo, yes even Firefox on Linux, gets popped in each year's P0wn2Own contest. If you can execute code on the client, you can usually find one of the hundreds of local privilege escalation bugs stil there. Then you can compromise any private keys and certs on it, as well as any user credentials stored or entered on the machine. This makes it easy to pivot into the core of the target's network without being noticed, and is in fact how many penetration tests and "APT" or "watering hole" hacks succeed. They attack clients and pivot into the target network. So the solution would be: don't let your clients ever touch anything outside your private walled garden. Which is exactly what high-security installations in the defense and government sectors do: they are air-gapped from the Internet. Tough to get a lot of work done that way, and function as a business. -- RPM From morrowc.lists at gmail.com Tue Jul 16 16:48:03 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Jul 2013 12:48:03 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> Message-ID: On Tue, Jul 16, 2013 at 1:42 AM, Eugeniu Patrascu wrote: > Dropping everything at once may dilute the debate as I am sure your > government and every other government that may be proved to be involved will it seems likely that every gov't with sense is doing this sort of thing... there's no reason for them NOT to, and many many countries intentionally setup their telecoms infrastructure in a way that supports this behaviour. -chris (yes, over broad collection and analysis and leaving it to the analyst(s) to decide what is 'overbroad' - "my girlfriend/wife/horse WAS talking to a foreign person...honest!" isn't cool, I'm not debating that point) From wbailey at satelliteintelligencegroup.com Tue Jul 16 17:15:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 16 Jul 2013 17:15:54 +0000 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> , Message-ID: I still believe the initial disclosure should have included a matter of great international importance.. If it were me, I would have dropped info along with the fact that facebook is going to a pay model. There would have been riots in the streets. ;) Sent from my Mobile Device. -------- Original message -------- From: Christopher Morrow Date: 07/16/2013 9:48 AM (GMT-08:00) To: Eugeniu Patrascu Cc: Warren Bailey ,Valdis Kletnieks ,nanog list Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted messages On Tue, Jul 16, 2013 at 1:42 AM, Eugeniu Patrascu wrote: > Dropping everything at once may dilute the debate as I am sure your > government and every other government that may be proved to be involved will it seems likely that every gov't with sense is doing this sort of thing... there's no reason for them NOT to, and many many countries intentionally setup their telecoms infrastructure in a way that supports this behaviour. -chris (yes, over broad collection and analysis and leaving it to the analyst(s) to decide what is 'overbroad' - "my girlfriend/wife/horse WAS talking to a foreign person...honest!" isn't cool, I'm not debating that point) From Andy.Litzinger at theplatform.com Tue Jul 16 18:12:32 2013 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Tue, 16 Jul 2013 18:12:32 +0000 Subject: tools and techniques to pinpoint and respond to loss on a path In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D03682184@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> <9F4D4FC766780045A8E7ECEA533A1A8D03682184@CORPTPMAIL03.corp.theplatform.com> Message-ID: <9F4D4FC766780045A8E7ECEA533A1A8D03682212@CORPTPMAIL03.corp.theplatform.com> > From: Blake Dunlap [mailto:ikiris at gmail.com] > While any provider will attempt to fix peer / upstream issues as they can, any > SLA you would have is between two points on their private network, not > from point A to point Z that they have no control over across multiple peers > and the public internet itself. makes sense- thanks for confirming > The much more common design is using a single > provider for each thread between sites. Then at least you have an end-to- > end SLA in effect, as well as a single entity that is responsible for the entire > link in question. > > This sounds like you're trying to achieve private link IGP / FRR level site to site > failover/convergence across the public internet. Perhaps you should rethink > your goals here or your design? Kind of- I can actually tolerate the blips, but I want to be able to measure and track them in such a way that I know where the loss is occurring. If a particular path is reconverging more often than should be reasonably expected I want to be able to prove it within reason. We also have a customer who happens to host at DC B with the same connectivity. Every time there is one of these blips their alerting fires off a thousand messages and they open a ticket with us. I'd like to be able to show them some good data on the path during the blip so we back a discussion along the lines of "live with it, or pay to privately connect to us". -andy > -Blake > > On Mon, Jul 15, 2013 at 4:18 PM, Andy Litzinger > wrote: > Hi, > > Does anyone have any recommendations on how to pinpoint and react to > packet loss across the internet? ?preferably in an automated fashion. ?For > detection I'm currently looking at trying smoketrace to run from inside my > network, but I'd love to be able to run traceroutes from my edge routers > triggered during periods of loss. ?I have Juniper MX80s on one end- which I'm > hopeful I'll be able to cobble together some combo of RPM and event > scripting to kick off a traceroute. ?We have Cisco4900Ms on the other end and > maybe the same thing is possible but I'm not so sure. > > I'd love to hear other suggestions and experience for detection and also for > options on what I might be able to do when loss is detected on a path. > > In my specific situation I control equipment on both ends of the path that I > care about with details below. > > we are a hosted service company and we currently have two data centers, > DC A and DC B. ?DC A uses juniper MX routers, advertises our own IP space > and takes full BGP feeds from two providers, ISPs A1 and A2. ?At DC B we > have a smaller installation and instead take redundant drops (and IP space) > from a single provider, ISP B1, who then peers upstream with two providers, > B2 and B3 > > We have a fairly consistent bi-directional stream of traffic between DC A and > DC B. ?Both of ISP A1 and A2 have good peering with ISP B2 so under normal > network conditions traffic flows across ISP B1 to B2 and then to either ISP A1 > or A2 > > oversimplified ascii pic showing only the normal best paths: > > ? ? ? ? ? ? ? -- ISP A1----------------------ISP B2-- DC A-- > | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |--- ?ISP B1 ----- DC B > ? ? ? ? ? ? ?-- ISP A2----------------------ISP B2-- > > > with increasing frequency we've been experiencing packet loss along the > path from DC A to DC B. ?Usually the periods of loss are brief, ?30 seconds to a > minute, but they are total blackouts. > > ? I'd like to be able to collect enough relevant data to pinpoint the trouble > spot as much as possible so I can take it to the ISPs and request a > solution. ?The blackouts are so quick that it's impossible to log in and get a > trace- hence the desire to automate it. > > I can provide more details off list if helpful- I'm trying not to vilify anyone- > especially without copious amounts of data points. > > As a side question, what should my expectation be regarding packet loss > when sending packets from point A to point B across multiple providers > across the internet? ?Is 30 seconds to a minute of blackout between two > destinations every couple of weeks par for the course? ?My directly > connected ISPs offer me an SLA, but what should I reasonably expect from > them when one of their upstream peers (or a peer of their peers) has > issues? ?If this turns out to be BGP reconvergence or similar do I have any > options? > > many thanks, > -andy From jcurran at arin.net Tue Jul 16 19:02:57 2013 From: jcurran at arin.net (John Curran) Date: Tue, 16 Jul 2013 19:02:57 +0000 Subject: The 4th Global IPv6 Deployment Monitoring Survey is underway! References: <51D16F60.9000200@arin.net> Message-ID: NANOGers - If you have a moment, it would be helpful if you could complete the 4th annual Global IPv6 Deployment Monitoring Survey. Completion only takes a few minutes, and the data from the survey is useful in tracking progress and hurdles in IPv6 deployment. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] The 4th Global IPv6 Deployment Monitoring Survey is Open Now Date: July 1, 2013 8:00:32 AM EDT To: > Dear Community, As in previous years, the Number Resource Organization (NRO) invites you to participate in the 4th consecutive Global IPv6 Deployment Monitoring Survey on the current and future use of IPv6. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of our community to participate: https://www.surveymonkey.com/s/GlobalIPv6survey2013 The purpose of the survey is to better understand where the Internet community is going, and what can be done to ensure it is ready for the widespread adoption of IPv6. We hope this survey will establish a comprehensive view of current IPv6 penetration and future deployment plans for IPv6. This year's survey is similar to those conducted in previous years (2010, 2011 and 2012), and will enable a comparison of progress. What is clear is that community participation does contribute to a better understanding of how IPv6 is being used. In 2012, 91% of the over 1,500 respondents indicated that they were interested in participating again in the 2013 survey. This survey has a maximum of 30 questions and will take about 20 minutes to complete. For those without IPv6 allocations or assignments, or have not yet deployed IPv6, the questions will be fewer in number. The survey will be open for a month and will close on 31 July 2013. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed widely, with the support of your Regional Internet Registry (RIR). We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to info at gnksconsult.com. Regards, Susan Hamlin Director, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From shortdudey123 at gmail.com Tue Jul 16 19:44:15 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 16 Jul 2013 12:44:15 -0700 Subject: Hilton proxy issue Message-ID: Hi, Anyone from Hilton Hotels NOC or related on here? We are seeing their internet proxy doing weird things to http requests to servers at $DAYJOB. -Grant From Valdis.Kletnieks at vt.edu Tue Jul 16 19:47:58 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 16 Jul 2013 15:47:58 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: Your message of "Tue, 16 Jul 2013 10:17:46 +0200." References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> <11286.1373897480@turing-police.cc.vt.edu> Message-ID: <14165.1374004078@turing-police.cc.vt.edu> On Tue, 16 Jul 2013 10:17:46 +0200, "<<\"tei''>>>" said: > It would be fun to make a encryptation keyboard. A keyboard that add > the text you write to a buffer, and wen the buffer is full, output it > to the computer encrypted. Maybe with pgp. Such machine would > probably need a led with the text you are writing. > > That way, you coud be using Google Docs or Office 365. And the > computer OS can have a keylogger and a backdoor. And you will still > be somewhat safe if pgp provide you with strong enough level of > encryptation. Congrats. You just re-invented the TPM chip. (And how do you actually guarante that your keyboard doesn't have a keylogger or a backdoor? Such things *have* been installed inside keyboards before...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jared at puck.nether.net Tue Jul 16 20:11:29 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 16 Jul 2013 16:11:29 -0400 Subject: Hilton proxy issue In-Reply-To: References: Message-ID: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> On Jul 16, 2013, at 3:44 PM, Grant Ridder wrote: > Hi, > > Anyone from Hilton Hotels NOC or related on here? We are seeing their > internet proxy doing weird things to http requests to servers at $DAYJOB. Many of the hilton properties have migrated to Wayport/"attwifi". Are you seeing the requests from AT&T/Wayport or from their corporate? (btw, if you're here and with wayport/attwifi, i would be interested in chatting briefly with you). - Jared From shortdudey123 at gmail.com Tue Jul 16 20:17:56 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 16 Jul 2013 13:17:56 -0700 Subject: Hilton proxy issue In-Reply-To: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> References: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> Message-ID: The requests are coming from 167.187.100.202 which is in a /16 assigned to Hilton. As far as i know, the waypoint service has its own netblocks. -Grant On Tue, Jul 16, 2013 at 1:11 PM, Jared Mauch wrote: > > On Jul 16, 2013, at 3:44 PM, Grant Ridder wrote: > > > Hi, > > > > Anyone from Hilton Hotels NOC or related on here? We are seeing their > > internet proxy doing weird things to http requests to servers at $DAYJOB. > > > Many of the hilton properties have migrated to Wayport/"attwifi". Are you > seeing the requests from AT&T/Wayport or from their corporate? > > (btw, if you're here and with wayport/attwifi, i would be interested in > chatting briefly with you). > > - Jared From hannigan at gmail.com Tue Jul 16 22:25:09 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 16 Jul 2013 18:25:09 -0400 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <20960.20504.514385.565329@world.std.com> References: <20130711190233.CBC3EDFD@m0005311.ppops.net> <20960.20504.514385.565329@world.std.com> Message-ID: On Fri, Jul 12, 2013 at 2:51 PM, Barry Shein > wrote: > > What I find particularly troubling is this image of the govt paying > for these surveillances. The price seemed to be from around $325 for > an install plus $10 to $750 install and $500/mo. > > Now, let's not drop right into the easy and trite "don't they deserve > to be reimbursed" right off. Sure, they/we do. > > But was this reimbursement, or profitable? > IMHO surveillance is not a profit center. Most don't get enough requests for critical mass and the efficiency to allow for that. The costs referenced in the article are not entirely unreasonable either if you think about the process from service to execution, end/end. The fact that there are associated fees at all is a positive in terms of a deterrent to "some" abuses and act as one level of accountability. Expenses require justification even in the government. The actual cost for the government to operate a surveillance end to end and depending upon where in the ladder it is can be significant, to the tune of tens of thousands of dollars a week. That usually translates into what matters e.g. surveillance of parking offenders vs. terrorists. >From the capex perspective, it can be high and complex for most based on the lack of significant volume. That's where the surveillance managed services come into play, to help to cut the expense. Standard offering: http://www.verisign.com/static/001927.pdf Shaping the expense picture: http://www.neustar.biz/carrier-services/operational-solutions/how-comply-with-regulations-solutions-work#.UeU6kVNqLC0 > > The troubling image that goes like this: > > > ISP VP #1: Any revenue ideas? > [ clip ] > > Accurate? Plausible? Nonsense? I'd go with the latter. You'd need volume and that kind critical mass, at least last I knew, was limited. Here's the last askCALEA congressional report(s) I can find that contain some numbers around that: http://askcalea.fbi.gov/reports/docs/2009wiretap.pdf [ Anyone know if there is anything later or newer? This transparency is important ] I'm not quitting my online collaboration tools just yet. YMMV, and Best, -M< [ clip ] From alumbis at gmail.com Wed Jul 17 00:22:51 2013 From: alumbis at gmail.com (Pete Lumbis) Date: Tue, 16 Jul 2013 20:22:51 -0400 Subject: tools and techniques to pinpoint and respond to loss on a path In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> Message-ID: IP SLA + EEM on the 4900. You can have the 4900 run pings/latency tests and then run commands and pipe them to flash when the issue happens. -Pete On Mon, Jul 15, 2013 at 5:18 PM, Andy Litzinger < Andy.Litzinger at theplatform.com> wrote: > Hi, > > Does anyone have any recommendations on how to pinpoint and react to > packet loss across the internet? preferably in an automated fashion. For > detection I'm currently looking at trying smoketrace to run from inside my > network, but I'd love to be able to run traceroutes from my edge routers > triggered during periods of loss. I have Juniper MX80s on one end- which > I'm hopeful I'll be able to cobble together some combo of RPM and event > scripting to kick off a traceroute. We have Cisco4900Ms on the other end > and maybe the same thing is possible but I'm not so sure. > > I'd love to hear other suggestions and experience for detection and also > for options on what I might be able to do when loss is detected on a path. > > In my specific situation I control equipment on both ends of the path that > I care about with details below. > > we are a hosted service company and we currently have two data centers, DC > A and DC B. DC A uses juniper MX routers, advertises our own IP space and > takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we have a > smaller installation and instead take redundant drops (and IP space) from a > single provider, ISP B1, who then peers upstream with two providers, B2 and > B3 > > We have a fairly consistent bi-directional stream of traffic between DC A > and DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under > normal network conditions traffic flows across ISP B1 to B2 and then to > either ISP A1 or A2 > > oversimplified ascii pic showing only the normal best paths: > > -- ISP A1----------------------ISP B2-- > DC A--| > |--- ISP B1 ----- DC B > -- ISP A2----------------------ISP B2-- > > > with increasing frequency we've been experiencing packet loss along the > path from DC A to DC B. Usually the periods of loss are brief, 30 seconds > to a minute, but they are total blackouts. > > I'd like to be able to collect enough relevant data to pinpoint the > trouble spot as much as possible so I can take it to the ISPs and request a > solution. The blackouts are so quick that it's impossible to log in and > get a trace- hence the desire to automate it. > > I can provide more details off list if helpful- I'm trying not to vilify > anyone- especially without copious amounts of data points. > > As a side question, what should my expectation be regarding packet loss > when sending packets from point A to point B across multiple providers > across the internet? Is 30 seconds to a minute of blackout between two > destinations every couple of weeks par for the course? My directly > connected ISPs offer me an SLA, but what should I reasonably expect from > them when one of their upstream peers (or a peer of their peers) has > issues? If this turns out to be BGP reconvergence or similar do I have any > options? > > many thanks, > -andy > > From nanog at deman.com Wed Jul 17 02:28:12 2013 From: nanog at deman.com (Michael DeMan) Date: Tue, 16 Jul 2013 19:28:12 -0700 Subject: tools and techniques to pinpoint and respond to loss on a path In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0367BBC8@CORPTPMAIL03.corp.theplatform.com> Message-ID: What I have done in the past, and this presumes you have a /29 or bigger on the peering session to your upstreams is to check with the direct upstream provider at each and get approval to put a linux box diagnostics server on the peering side of each BGP upstream connection you have - default-routed out to their BGP router(s). Typically not a problem with the upstream as long as they know this is for diagnostics purposes and will be taken down later. Also helps the upstreams know you are seriously looking at the reliability they are giving and their competitors are giving you. On that diagnostics box, run some quick & dirty tools to try and start isolating if the problem is related to one upstream link or another, or a combination of them. Have each one monitoring all the distant peer connections, and possibly even each-other local peers for connectivity if you are uber-detailed. The problem could be anywhere in between, but if you notice it is one link that has the issues and the other one does not, and/or a combo of src/dst, then you are in better shape to help your upstreams diagnose as well. A couple tools like smokeping and running traceroute and ping on a scripted basis are not perfect, but easy to setup. Log it all out so when it impacts production systems you can go back and look at those logs and see if there are any clues. nettop is also another handy tool to dump stuff out with and also in the nearly impossible case you happen to be on the console when the problem occurs is very handy. From there, let that run for a while - hours, days, weeks depending on the frequency of the problem and typically you will find that the 'hiccup' happens either via one peering partner or all of them - and/or from one end or the other. More than likely something will fall out from the data as to where the problem is, and often it is not with your direct peers, but their peers or somebody else further down the chain. This kind of stuff is notoriously difficult to troubleshoot and I generally agree with the opinions that for better or worse - global IP connectivity is still just a 'best effort basis' with out spending immense amounts of money. I remember a few years ago having blips and near one-hour outages from NW Washington State over to Europe and the problem was that global crossing was doing a bunch of maintenance and it was not going well for them. They were 'man in the middle' for the routing from two different peers and just knowing the problem was a big help and with some creative BGP announcements we were able to minimize the impact. - mike On Jul 15, 2013, at 2:18 PM, Andy Litzinger wrote: > Hi, > > Does anyone have any recommendations on how to pinpoint and react to packet loss across the internet? preferably in an automated fashion. For detection I'm currently looking at trying smoketrace to run from inside my network, but I'd love to be able to run traceroutes from my edge routers triggered during periods of loss. I have Juniper MX80s on one end- which I'm hopeful I'll be able to cobble together some combo of RPM and event scripting to kick off a traceroute. We have Cisco4900Ms on the other end and maybe the same thing is possible but I'm not so sure. > > I'd love to hear other suggestions and experience for detection and also for options on what I might be able to do when loss is detected on a path. > > In my specific situation I control equipment on both ends of the path that I care about with details below. > > we are a hosted service company and we currently have two data centers, DC A and DC B. DC A uses juniper MX routers, advertises our own IP space and takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we have a smaller installation and instead take redundant drops (and IP space) from a single provider, ISP B1, who then peers upstream with two providers, B2 and B3 > > We have a fairly consistent bi-directional stream of traffic between DC A and DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under normal network conditions traffic flows across ISP B1 to B2 and then to either ISP A1 or A2 > > oversimplified ascii pic showing only the normal best paths: > > -- ISP A1----------------------ISP B2-- > DC A--| |--- ISP B1 ----- DC B > -- ISP A2----------------------ISP B2-- > > > with increasing frequency we've been experiencing packet loss along the path from DC A to DC B. Usually the periods of loss are brief, 30 seconds to a minute, but they are total blackouts. > > I'd like to be able to collect enough relevant data to pinpoint the trouble spot as much as possible so I can take it to the ISPs and request a solution. The blackouts are so quick that it's impossible to log in and get a trace- hence the desire to automate it. > > I can provide more details off list if helpful- I'm trying not to vilify anyone- especially without copious amounts of data points. > > As a side question, what should my expectation be regarding packet loss when sending packets from point A to point B across multiple providers across the internet? Is 30 seconds to a minute of blackout between two destinations every couple of weeks par for the course? My directly connected ISPs offer me an SLA, but what should I reasonably expect from them when one of their upstream peers (or a peer of their peers) has issues? If this turns out to be BGP reconvergence or similar do I have any options? > > many thanks, > -andy > From rvandolson at esri.com Wed Jul 17 17:57:31 2013 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 17 Jul 2013 10:57:31 -0700 Subject: fbi.gov hostmaster contact? Message-ID: <20130717175731.GA8905@esri.com> Looking for a DNS/hostmaster contact for fbi.gov for troubleshooting a DNSSEC issue[1]. Have tried the usual hostmaster alias with no luck. Thanks, Ray [1] https://lists.isc.org/pipermail/bind-users/2013-July/091142.html From a.harrowell at gmail.com Wed Jul 17 20:59:44 2013 From: a.harrowell at gmail.com (Alex Harrowell) Date: Wed, 17 Jul 2013 21:59:44 +0100 Subject: Friday Hosing In-Reply-To: <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> Message-ID: <51E705C0.7050205@gmail.com> On 15/07/13 01:09, Tony Patti wrote: > TWELVE years ago (press release March 20 2001), Comcast deployed Linux-based > Sun Cobalt Qube appliances as CPE with their business-class Internet > service, > these provided firewall security, web caching, optional content filtering, > an e-mail server, a web server, file and print servers. This is a good idea. From jwalter at opendns.com Wed Jul 17 22:52:36 2013 From: jwalter at opendns.com (Jeff Walter) Date: Wed, 17 Jul 2013 15:52:36 -0700 Subject: Friday Hosing In-Reply-To: <51E705C0.7050205@gmail.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> Message-ID: <51E72034.5080502@opendns.com> On 7/17/13 1:59 PM, Alex Harrowell wrote: > On 15/07/13 01:09, Tony Patti wrote: >> TWELVE years ago (press release March 20 2001), Comcast deployed >> Linux-based >> Sun Cobalt Qube appliances as CPE with their business-class Internet >> service, >> these provided firewall security, web caching, optional content >> filtering, >> an e-mail server, a web server, file and print servers. > > This is a good idea At the time it may have been the "best" option, but that doesn't make it a good idea. I can't even begin to comprehend the number of support calls generated by providing CPE with those functions. -- Jeff Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From r.engehausen at gmail.com Wed Jul 17 23:36:19 2013 From: r.engehausen at gmail.com (Roy) Date: Wed, 17 Jul 2013 16:36:19 -0700 Subject: Friday Hosing In-Reply-To: <51E705C0.7050205@gmail.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> Message-ID: <51E72A73.9020407@gmail.com> On 7/17/2013 1:59 PM, Alex Harrowell wrote: > On 15/07/13 01:09, Tony Patti wrote: >> TWELVE years ago (press release March 20 2001), Comcast deployed >> Linux-based >> Sun Cobalt Qube appliances as CPE with their business-class Internet >> service, >> these provided firewall security, web caching, optional content >> filtering, >> an e-mail server, a web server, file and print servers. > > This is a good idea. > > > . > Whistle Interjet -- circa 1995 From Valdis.Kletnieks at vt.edu Wed Jul 17 23:56:45 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 17 Jul 2013 19:56:45 -0400 Subject: Friday Hosing In-Reply-To: Your message of "Wed, 17 Jul 2013 16:36:19 -0700." <51E72A73.9020407@gmail.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> Message-ID: <30513.1374105405@turing-police.cc.vt.edu> On Wed, 17 Jul 2013 16:36:19 -0700, Roy said: > On 7/17/2013 1:59 PM, Alex Harrowell wrote: > > On 15/07/13 01:09, Tony Patti wrote: > >> TWELVE years ago (press release March 20 2001), Comcast deployed Linux-based > >> Sun Cobalt Qube appliances as CPE with their business-class Internet service, > >> these provided firewall security, web caching, optional content filtering, > >> an e-mail server, a web server, file and print servers. > > > > This is a good idea. > Whistle Interjet -- circa 1995 Of course, in 1995, if you gave a customer something like that, there was still a reasonably good chance that doing so wouldn't generate a ton of support calls, because if they were a customer at all, they probably had a clue. These days, it seems giving a customer anything more user-servicable than an iPad is just asking for trouble... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From cboyd at gizmopartners.com Thu Jul 18 00:48:37 2013 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 17 Jul 2013 19:48:37 -0500 Subject: Friday Hosing In-Reply-To: <51E72A73.9020407@gmail.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> Message-ID: <1374108517.20577.4.camel@hounddog> On Wed, 2013-07-17 at 16:36 -0700, Roy wrote: > On 7/17/2013 1:59 PM, Alex Harrowell wrote: > > On 15/07/13 01:09, Tony Patti wrote: > >> TWELVE years ago (press release March 20 2001), Comcast deployed > >> Linux-based > >> Sun Cobalt Qube appliances as CPE with their business-class Internet > >> service, > >> these provided firewall security, web caching, optional content > >> filtering, > >> an e-mail server, a web server, file and print servers. > > > > This is a good idea. > > > > > > . > > > > Whistle Interjet -- circa 1995 I still have one of the T-Shirts Julian gave somewhere..... --Chris From jmamodio at gmail.com Thu Jul 18 01:11:58 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 17 Jul 2013 20:11:58 -0500 Subject: Friday Hosing In-Reply-To: <30513.1374105405@turing-police.cc.vt.edu> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> <30513.1374105405@turing-police.cc.vt.edu> Message-ID: Ohh we had some of those at JVNCNet, a real piece of crap. -Jorge On Jul 17, 2013, at 6:56 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 17 Jul 2013 16:36:19 -0700, Roy said: >> On 7/17/2013 1:59 PM, Alex Harrowell wrote: >>> On 15/07/13 01:09, Tony Patti wrote: >>>> TWELVE years ago (press release March 20 2001), Comcast deployed Linux-based >>>> Sun Cobalt Qube appliances as CPE with their business-class Internet service, >>>> these provided firewall security, web caching, optional content filtering, >>>> an e-mail server, a web server, file and print servers. >>> >>> This is a good idea. > >> Whistle Interjet -- circa 1995 > > Of course, in 1995, if you gave a customer something like that, there was > still a reasonably good chance that doing so wouldn't generate a ton > of support calls, because if they were a customer at all, they probably had > a clue. > > These days, it seems giving a customer anything more user-servicable than > an iPad is just asking for trouble... > From alex at corp.nac.net Thu Jul 18 01:23:59 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 17 Jul 2013 21:23:59 -0400 Subject: Friday Hosing In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> <30513.1374105405@turing-police.cc.vt.edu> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB827D460F4F6@EXCHMBX.hq.nac.net> > Ohh we had some of those at JVNCNet, a real piece of crap. Wow. JVNCnet. Haven't heard that name in a long, long time. From sfrost at snowman.net Thu Jul 18 01:35:07 2013 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 17 Jul 2013 21:35:07 -0400 Subject: Friday Hosing In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB827D460F4F6@EXCHMBX.hq.nac.net> References: <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> <30513.1374105405@turing-police.cc.vt.edu> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460F4F6@EXCHMBX.hq.nac.net> Message-ID: <20130718013507.GQ15510@tamriel.snowman.net> * Alex Rubenstein (alex at corp.nac.net) wrote: > > Ohh we had some of those at JVNCNet, a real piece of crap. > > Wow. JVNCnet. Haven't heard that name in a long, long time. RIP Sir Alec Guinness. Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cook at cookreport.com Thu Jul 18 02:16:24 2013 From: cook at cookreport.com (Gordon Cook) Date: Wed, 17 Jul 2013 22:16:24 -0400 Subject: Friday Hosing In-Reply-To: <20130718013507.GQ15510@tamriel.snowman.net> References: <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> <30513.1374105405@turing-police.cc.vt.edu> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460F4F6@EXCHMBX.hq.nac.net> <20130718013507.GQ15510@tamriel.snowman.net> Message-ID: > * Alex Rubenstein (alex at corp.nac.net) wrote: >>> Ohh we had some of those at JVNCNet, a real piece of crap. >> >> Wow. JVNCnet. Haven't heard that name in a long, long time. Same here. I worked there from September 1987 through the closure in june of 1990. Whatever happened to Sergio Heker? > > RIP Sir Alec Guinness. > > Stephen From a.harrowell at gmail.com Thu Jul 18 08:40:23 2013 From: a.harrowell at gmail.com (Alex Harrowell) Date: Thu, 18 Jul 2013 09:40:23 +0100 Subject: Friday Hosing In-Reply-To: <51E72034.5080502@opendns.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> <518D00CD.5070906@pubnix.net> <51E02478.30409@pubnix.net> <89FF7DD5-6FC4-42B3-99E1-7148D5AC3E6B@ianai.net> <51E0407E.9050207@bryanfields.net> <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72034.5080502@opendns.com> Message-ID: <51E7A9F7.2030904@gmail.com> On 17/07/13 23:52, Jeff Walter wrote: > On 7/17/13 1:59 PM, Alex Harrowell wrote: >> On 15/07/13 01:09, Tony Patti wrote: >>> TWELVE years ago (press release March 20 2001), Comcast deployed >>> Linux-based >>> Sun Cobalt Qube appliances as CPE with their business-class Internet >>> service, >>> these provided firewall security, web caching, optional content >>> filtering, >>> an e-mail server, a web server, file and print servers. >> This is a good idea > At the time it may have been the "best" option, but that doesn't make it > a good idea. I can't even begin to comprehend the number of support > calls generated by providing CPE with those functions. That said, I can think of a couple of European quality ISPs that hand out CPE approaching that degree of feature richness - Free.fr's Freeboxes (although that's consumer-oriented), Andrews & Arnold's Firebricks come to mind. > > -- > Jeff Walter > From jmamodio at gmail.com Thu Jul 18 11:41:05 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 18 Jul 2013 06:41:05 -0500 Subject: Friday Hosing In-Reply-To: References: <4F5BDF9C-ABE2-444F-A7B3-C5646ABB821D@ianai.net> <51E08A89.70208@pubnix.net> <8A691BFC-FF01-4B21-86E3-5150CB7DD515@ianai.net> <0fde01ce80ef$94d0e420$be72ac60$@swalter.com> <51E705C0.7050205@gmail.com> <51E72A73.9020407@gmail.com> <30513.1374105405@turing-police.cc.vt.edu> <2D0AF14BA6FB334988BC1F5D4FC38CB827D460F4F6@EXCHMBX.hq.nac.net> <20130718013507.GQ15510@tamriel.snowman.net> Message-ID: <0D791AB7-BF8D-4749-A98E-1DCE9A514110@gmail.com> JVNCNet survived and became operated by Global Enterprise Services, the company Sergio created to spin off the network out of Princeton University, GES was acquired by Verio in 1997 and Sergio moved to start another company. Last message I've got from him said he was in Panama providing consulting in network security or something like that. The Princeton office was closed by Verio as far as I remember in 2003. -Jorge On Jul 17, 2013, at 9:16 PM, Gordon Cook wrote: > > >> * Alex Rubenstein (alex at corp.nac.net) wrote: >>>> Ohh we had some of those at JVNCNet, a real piece of crap. >>> >>> Wow. JVNCnet. Haven't heard that name in a long, long time. > > Same here. I worked there from September 1987 through the closure in june of 1990. Whatever happened to Sergio Heker? From john at west-canaan.net Fri Jul 19 03:32:38 2013 From: john at west-canaan.net (John Zettlemoyer) Date: Thu, 18 Jul 2013 23:32:38 -0400 Subject: AOL Postmaster Message-ID: <003001ce8430$a2e709b0$e8b51d10$@net> Could someone from the AOL mail group (AOL Postmaster) please contact me off list. Thank you. John Zettlemoyer Sr. Director of I.T. Infrastructure WCiT - West-Canaan LLC john at wcit.net From cscora at apnic.net Fri Jul 19 18:33:35 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Jul 2013 04:33:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201307191833.r6JIXZAL007519@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 20 Jul, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 459588 Prefixes after maximum aggregation: 186889 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 228557 Total ASes present in the Internet Routing Table: 44556 Prefixes per ASN: 10.31 Origin-only ASes present in the Internet Routing Table: 34873 Origin ASes announcing only one prefix: 16201 Transit ASes present in the Internet Routing Table: 5897 Transit-only ASes present in the Internet Routing Table: 150 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 3294 Unregistered ASNs in the Routing Table: 1332 Number of 32-bit ASNs allocated by the RIRs: 4887 Number of 32-bit ASNs visible in the Routing Table: 3786 Prefixes from 32-bit ASNs in the Routing Table: 11394 Special use prefixes present in the Routing Table: 27 Prefixes being announced from unallocated address space: 264 Number of addresses announced to Internet: 2630581868 Equivalent to 156 /8s, 203 /16s and 126 /24s Percentage of available address space announced: 71.1 Percentage of allocated address space announced: 71.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.7 Total number of prefixes smaller than registry allocations: 160716 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110373 Total APNIC prefixes after maximum aggregation: 33801 APNIC Deaggregation factor: 3.27 Prefixes being announced from the APNIC address blocks: 112375 Unique aggregates announced from the APNIC address blocks: 46225 APNIC Region origin ASes present in the Internet Routing Table: 4855 APNIC Prefixes per ASN: 23.15 APNIC Region origin ASes announcing only one prefix: 1220 APNIC Region transit ASes present in the Internet Routing Table: 826 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 605 Number of APNIC addresses announced to Internet: 726149792 Equivalent to 43 /8s, 72 /16s and 42 /24s Percentage of available APNIC address space announced: 84.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159451 Total ARIN prefixes after maximum aggregation: 80739 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 160053 Unique aggregates announced from the ARIN address blocks: 74115 ARIN Region origin ASes present in the Internet Routing Table: 15795 ARIN Prefixes per ASN: 10.13 ARIN Region origin ASes announcing only one prefix: 6003 ARIN Region transit ASes present in the Internet Routing Table: 1653 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1067944512 Equivalent to 63 /8s, 167 /16s and 138 /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: 118451 Total RIPE prefixes after maximum aggregation: 60254 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 121926 Unique aggregates announced from the RIPE address blocks: 78676 RIPE Region origin ASes present in the Internet Routing Table: 17315 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 8212 RIPE Region transit ASes present in the Internet Routing Table: 2835 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2376 Number of RIPE addresses announced to Internet: 656323556 Equivalent to 39 /8s, 30 /16s and 179 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 48852 Total LACNIC prefixes after maximum aggregation: 9509 LACNIC Deaggregation factor: 5.14 Prefixes being announced from the LACNIC address blocks: 53365 Unique aggregates announced from the LACNIC address blocks: 25309 LACNIC Region origin ASes present in the Internet Routing Table: 1985 LACNIC Prefixes per ASN: 26.88 LACNIC Region origin ASes announcing only one prefix: 580 LACNIC Region transit ASes present in the Internet Routing Table: 363 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 780 Number of LACNIC addresses announced to Internet: 133371048 Equivalent to 7 /8s, 243 /16s and 20 /24s Percentage of available LACNIC address space announced: 79.5 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: 10977 Total AfriNIC prefixes after maximum aggregation: 2546 AfriNIC Deaggregation factor: 4.31 Prefixes being announced from the AfriNIC address blocks: 11605 Unique aggregates announced from the AfriNIC address blocks: 3986 AfriNIC Region origin ASes present in the Internet Routing Table: 643 AfriNIC Prefixes per ASN: 18.05 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 134 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46422784 Equivalent to 2 /8s, 196 /16s and 91 /24s Percentage of available AfriNIC address space announced: 46.1 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 2922 11560 918 Korea Telecom (KIX) 17974 2589 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2030 320 108 TPG Internet Pty Ltd 4755 1757 391 192 TATA Communications formerly 9829 1536 1220 44 BSNL National Internet Backbo 9583 1221 92 505 Sify Limited 4808 1171 2152 336 CNCGROUP IP network: China169 9498 1161 309 71 BHARTI Airtel Ltd. 7552 1159 1080 13 Vietel Corporation 24560 1085 394 164 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 2986 3690 68 bellsouth.net, inc. 18566 2067 382 184 Covad Communications 1785 2001 678 126 PaeTec Communications, Inc. 22773 1996 2927 124 Cox Communications, Inc. 20115 1668 1622 620 Charter Communications 4323 1615 1118 404 Time Warner Telecom 701 1531 11127 797 UUNET Technologies, Inc. 30036 1345 304 660 Mediacom Communications Corp 7018 1299 11035 822 AT&T WorldNet Services 11492 1224 218 360 Cable One 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 1579 544 16 Corbina telecom 2118 1385 97 13 EUnet/RELCOM Autonomous Syste 34984 1296 244 222 BILISIM TELEKOM 31148 973 43 21 FreeNet ISP 20940 927 319 728 Akamai Technologies European 13188 837 98 81 Educational Network 6830 807 2376 442 UPC Distribution Services 8551 780 370 45 Bezeq International 12479 675 789 57 Uni2 Autonomous System 34744 637 170 73 SC GVM SISTEM 2003 SRL 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 2933 1589 109 NET Servicos de Comunicao S.A 10620 2653 419 229 TVCABLE BOGOTA 7303 1733 1155 222 Telecom Argentina Stet-France 8151 1269 2751 385 UniNet S.A. de C.V. 18881 1165 844 20 Global Village Telecom 27947 829 94 91 Telconet S.A 6503 819 434 63 AVANTEL, S.A. 3816 717 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 618 88 65 Servicios Alestra S.A de C.V 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 1253 80 4 MOBITEL 24863 883 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 438 956 9 TEDATA 24835 332 80 8 RAYA Telecom - Egypt 3741 259 922 218 The Internet Solution 29571 220 17 12 Ci Telecom Autonomous system 15706 219 32 6 Sudatel Internet Exchange Aut 36992 206 527 23 Etisalat MISR 12258 193 28 71 Vodacom Internet Company 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 6389 2986 3690 68 bellsouth.net, inc. 28573 2933 1589 109 NET Servicos de Comunicao S.A 4766 2922 11560 918 Korea Telecom (KIX) 10620 2653 419 229 TVCABLE BOGOTA 17974 2589 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2067 382 184 Covad Communications 7545 2030 320 108 TPG Internet Pty Ltd 1785 2001 678 126 PaeTec Communications, Inc. 22773 1996 2927 124 Cox Communications, Inc. 4755 1757 391 192 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2933 2824 NET Servicos de Comunicao S.A 17974 2589 2497 PT TELEKOMUNIKASI INDONESIA 10620 2653 2424 TVCABLE BOGOTA 4766 2922 2004 Korea Telecom (KIX) 7545 2030 1922 TPG Internet Pty Ltd 18566 2067 1883 Covad Communications 1785 2001 1875 PaeTec Communications, Inc. 22773 1996 1872 Cox Communications, Inc. 4755 1757 1565 TATA Communications formerly 8402 1579 1563 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 30621 UNALLOCATED 12.151.74.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2541 >>UNKNOWN<< 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.42.0/24 60619 >>UNKNOWN<< 128.0.43.0/24 60619 >>UNKNOWN<< 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.56.0/24 60996 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.200.128.0/17 59628 Telecommunications Company of 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 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:11 /10:30 /11:92 /12:251 /13:479 /14:905 /15:1604 /16:12704 /17:6645 /18:11085 /19:22460 /20:32118 /21:34588 /22:48452 /23:42430 /24:241814 /25:1289 /26:1629 /27:837 /28:43 /29:69 /30:19 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 6389 1715 2986 bellsouth.net, inc. 22773 1298 1996 Cox Communications, Inc. 8402 1274 1579 Corbina telecom 36998 1221 1253 MOBITEL 30036 1212 1345 Mediacom Communications Corp 11492 1185 1224 Cable One 1785 1070 2001 PaeTec Communications, Inc. 6983 1021 1148 ITC^Deltacom 10620 980 2653 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:819 2:727 3:3 4:19 5:832 6:16 8:572 12:1920 13:2 14:864 15:11 16:3 17:10 20:17 23:296 24:1770 27:1499 31:1314 32:45 33:2 34:5 36:59 37:1886 38:884 39:2 40:175 41:2776 42:235 44:8 46:1954 47:2 49:671 50:775 52:12 54:34 55:8 57:26 58:1162 59:582 60:328 61:1420 62:1155 63:2015 64:4348 65:2148 66:4180 67:2014 68:1088 69:3278 70:796 71:489 72:1914 74:2481 75:324 76:307 77:1140 78:957 79:609 80:1290 81:1007 82:635 83:579 84:581 85:1206 86:465 87:1020 88:546 89:1812 90:150 91:5538 92:620 93:1770 94:1939 95:1688 96:520 97:343 98:1027 99:43 100:30 101:585 103:2963 105:519 106:139 107:208 108:516 109:1865 110:927 111:1069 112:550 113:819 114:698 115:1000 116:962 117:834 118:1131 119:1307 120:390 121:737 122:1808 123:1236 124:1376 125:1387 128:636 129:224 130:309 131:671 132:360 133:155 134:268 135:68 136:257 137:242 138:340 139:193 140:202 141:328 142:548 143:380 144:513 145:98 146:529 147:403 148:665 149:352 150:148 151:551 152:414 153:189 154:28 155:405 156:266 157:388 158:278 159:742 160:346 161:449 162:478 163:226 164:581 165:504 166:253 167:599 168:1030 169:128 170:1065 171:182 172:23 173:1595 174:544 175:494 176:1119 177:2122 178:1873 179:65 180:1473 181:549 182:1263 183:425 184:673 185:656 186:2327 187:1318 188:1909 189:1316 190:6745 192:6857 193:5859 194:4696 195:3544 196:1346 197:890 198:4541 199:5363 200:6007 201:2213 202:8840 203:8891 204:4504 205:2595 206:2866 207:2853 208:4013 209:3581 210:2913 211:1519 212:2200 213:2008 214:922 215:99 216:5255 217:1615 218:616 219:312 220:1276 221:556 222:321 223:440 End of report From wbailey at satelliteintelligencegroup.com Fri Jul 19 19:10:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 19 Jul 2013 19:10:54 +0000 Subject: ARIN question Message-ID: All, Does anyone have a baseline on the "maximum" allocation a small to mid-sized ISP can receive from ARIN? I realize resources are scarce in IPv4 land, and I am a bit nervous to initiate the process myself without an understanding of what can/cannot be allocated. I'm not looking for anything insane, maybe a /23 or something in that realm. I'd appreciate any feedback/input any of you have ? on list or off. Just looking to get a better grasp on the IPv4 climate before I start telling our people to spend money. //warren From ssaner at hubris.net Fri Jul 19 19:27:26 2013 From: ssaner at hubris.net (Steven Saner) Date: Fri, 19 Jul 2013 14:27:26 -0500 Subject: ARIN question In-Reply-To: References: Message-ID: <51E9931E.6010504@hubris.net> On 07/19/2013 02:10 PM, Warren Bailey wrote: > All, > > Does anyone have a baseline on the "maximum" allocation a small to mid-sized ISP can receive from ARIN? I realize resources are scarce in IPv4 land, and I am a bit nervous to initiate the process myself without an understanding of what can/cannot be allocated. I'm not looking for anything insane, maybe a /23 or something in that realm. I'd appreciate any feedback/input any of you have ? on list or off. Just looking to get a better grasp on the IPv4 climate before I start telling our people to spend money. > > //warren > We recently received a /22 allocation and I believe we were told that was the maximum at one time. However, after some period of time you are eligible to request another. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From cidr-report at potaroo.net Fri Jul 19 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Jul 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201307192200.r6JM00K6059566@wattle.apnic.net> This report has been generated at Fri Jul 19 21:13:29 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-07-13 469693 267431 13-07-13 469912 267588 14-07-13 470143 267637 15-07-13 470021 267973 16-07-13 470793 267814 17-07-13 470729 267494 18-07-13 470980 267519 19-07-13 470686 267698 AS Summary 44700 Number of ASes in routing system 18454 Number of ASes announcing only one prefix 4234 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117328896 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'). --- 19Jul13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 470627 267605 203022 43.1% All ASes AS6389 2985 71 2914 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2924 491 2433 83.2% NET Servi?os de Comunica??o S.A. AS17974 2588 441 2147 83.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4234 2112 2122 50.1% WINDSTREAM - Windstream Communications Inc AS4766 2922 933 1989 68.1% KIXS-AS-KR Korea Telecom AS22773 1996 167 1829 91.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2653 869 1784 67.2% Telmex Colombia S.A. AS18566 2067 468 1599 77.4% COVAD - Covad Communications Co. AS4323 2981 1531 1450 48.6% TWTC - tw telecom holdings, inc. AS2118 1385 51 1334 96.3% RELCOM-AS OOO "NPO Relcom" AS7303 1733 455 1278 73.7% Telecom Argentina S.A. AS7545 2037 759 1278 62.7% TPG-INTERNET-AP TPG Telecom Limited AS4755 1755 587 1168 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18881 1165 43 1122 96.3% Global Village Telecom AS7552 1159 170 989 85.3% VIETEL-AS-AP Vietel Corporation AS1785 2001 1156 845 42.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1001 182 819 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS36998 1253 457 796 63.5% SDN-MOBITEL AS4808 1171 393 778 66.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS33363 1943 1192 751 38.7% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS701 1534 803 731 47.7% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 841 139 702 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 733 55 678 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22561 1182 512 670 56.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS6983 1148 479 669 58.3% ITCDELTA - ITC^Deltacom AS8151 1273 609 664 52.2% Uninet S.A. de C.V. AS24560 1085 432 653 60.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4788 770 137 633 82.2% TMNET-AS-AP TM Net, Internet Service Provider AS31148 973 345 628 64.5% FREENET-AS Freenet Ltd. AS17676 746 120 626 83.9% GIGAINFRA Softbank BB Corp. Total 52238 16159 36079 69.1% Top 30 total Possible Bogus Routes 5.200.128.0/17 AS59628 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.187.208.0/24 AS174 COGENT Cogent/PSI 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.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.185.0.0/20 AS36219 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 80.68.144.0/20 AS33982 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 173.45.192.0/19 AS6461 MFNX MFN - Metromedia Fiber Network 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 185.31.52.0/22 AS12453 KRAFTCOM-AS KRAFTCOM Bernhard KRAFT 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.79.48.0/22 AS39117 194.169.237.0/24 AS12968 CDP Netia SA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.6.85.0/24 AS56212 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.123.17.0/24 AS27363 SWISSRE-US-AS Swiss Re America Holding Corporation 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.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.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 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.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 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 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, 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 Jul 19 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Jul 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201307192200.r6JM01F7059586@wattle.apnic.net> BGP Update Report Interval: 11-Jul-13 -to- 18-Jul-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18403 144826 7.0% 249.7 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 2 - AS8402 51679 2.5% 49.8 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS27738 46549 2.3% 80.8 -- Ecuadortelecom S.A. 4 - AS4538 42997 2.1% 79.8 -- ERX-CERNET-BKB China Education and Research Network Center 5 - AS10620 33203 1.6% 14.3 -- Telmex Colombia S.A. 6 - AS9829 31755 1.5% 40.8 -- BSNL-NIB National Internet Backbone 7 - AS28573 22594 1.1% 9.3 -- NET Servi?os de Comunica??o S.A. 8 - AS10428 21585 1.1% 7195.0 -- CWV-NETWORKS - The College of West Virginia 9 - AS13208 18932 0.9% 9466.0 -- NEWTELSOLUTIONS-AS Newtel Ltd 10 - AS9416 18260 0.9% 9130.0 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - AS17974 16278 0.8% 7.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS28126 16115 0.8% 20.5 -- BRISANET SERVICOS DE TELECOMUNICACOES LTDA 13 - AS45528 15931 0.8% 29.8 -- TDN Tikona Digital Networks Pvt Ltd. 14 - AS4775 15765 0.8% 250.2 -- GLOBE-TELECOM-AS Globe Telecoms 15 - AS34315 14534 0.7% 3633.5 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 16 - AS34969 14080 0.7% 1760.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 17 - AS4657 12198 0.6% 31.3 -- STARHUBINTERNET-AS StarHub Internet Exchange 18 - AS8151 11640 0.6% 13.4 -- Uninet S.A. de C.V. 19 - AS30693 10224 0.5% 26.4 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 20 - AS29990 9854 0.5% 895.8 -- ASN-APPNEXUS - AppNexus, Inc TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48612 9806 0.5% 9806.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 2 - AS13208 18932 0.9% 9466.0 -- NEWTELSOLUTIONS-AS Newtel Ltd 3 - AS9416 18260 0.9% 9130.0 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - AS9854 8481 0.4% 8481.0 -- KTO-AS-KR KTO 5 - AS10428 21585 1.1% 7195.0 -- CWV-NETWORKS - The College of West Virginia 6 - AS19406 4670 0.2% 4670.0 -- TWRS-MA - Towerstream I, Inc. 7 - AS42334 4201 0.2% 4201.0 -- BBP-AS Broadband Plus s.a.l. 8 - AS31461 3690 0.2% 3690.0 -- MORAVIA-IT-AS Moravia IT, a.s. 9 - AS34315 14534 0.7% 3633.5 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 10 - AS6174 7248 0.3% 3624.0 -- SPRINTLINK8 - Sprint 11 - AS36976 2268 0.1% 2268.0 -- SONANGOL 12 - AS34969 14080 0.7% 1760.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 13 - AS37373 1484 0.1% 1484.0 -- AUC-ASN 14 - AS37367 1428 0.1% 1428.0 -- CALLKEY 15 - AS6629 8664 0.4% 1237.7 -- NOAA-AS - NOAA 16 - AS10445 5083 0.2% 1016.6 -- HTG - Huntleigh Telcom 17 - AS23295 995 0.1% 995.0 -- EA-01 - Extend America 18 - AS29990 9854 0.5% 895.8 -- ASN-APPNEXUS - AppNexus, Inc 19 - AS56678 847 0.0% 847.0 -- GYDROZO-AS LLC "Gydrozo" 20 - AS3 770 0.0% 1508.0 -- CMED-AS Cmed Technology Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.246.207.0/24 9806 0.5% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 2 - 213.133.192.0/24 9466 0.4% AS13208 -- NEWTELSOLUTIONS-AS Newtel Ltd 3 - 213.133.193.0/24 9466 0.4% AS13208 -- NEWTELSOLUTIONS-AS Newtel Ltd 4 - 203.118.224.0/21 9191 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.232.0/21 9069 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 8652 0.4% AS6629 -- NOAA-AS - NOAA 7 - 211.214.206.0/24 8481 0.4% AS9854 -- KTO-AS-KR KTO 8 - 64.208.141.0/24 8424 0.4% AS29990 -- ASN-APPNEXUS - AppNexus, Inc 10 - 120.28.62.0/24 7748 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 11 - 12.43.218.0/24 7195 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 12 - 199.248.240.0/24 7195 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 13 - 205.166.165.0/24 7195 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 14 - 65.90.49.0/24 5675 0.3% AS3356 -- LEVEL3 Level 3 Communications 15 - 192.107.15.0/24 5019 0.2% AS14733 -- AS14733 - Barclays Capital Inc. 16 - 69.38.178.0/24 4670 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 17 - 64.187.64.0/23 4383 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 18 - 62.84.76.0/24 4201 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 19 - 194.63.9.0/24 3775 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 20 - 46.227.8.0/21 3744 0.2% AS34315 -- MAXNET-AS MAXNET Maxprogres, s.r.o. 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 dougb at dougbarton.us Fri Jul 19 22:44:34 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 19 Jul 2013 15:44:34 -0700 Subject: ARIN question In-Reply-To: References: Message-ID: <51E9C152.4000209@dougbarton.us> On 07/19/2013 12:10 PM, Warren Bailey wrote: > All, > > Does anyone have a baseline on the "maximum" allocation a small to mid-sized ISP can receive from ARIN? I realize resources are scarce in IPv4 land, and I am a bit nervous to initiate the process myself without an understanding of what can/cannot be allocated. I'm not looking for anything insane, maybe a /23 or something in that realm. I'd appreciate any feedback/input any of you have ? on list or off. Just looking to get a better grasp on the IPv4 climate before I start telling our people to spend money. You really need to familiarize yourself with the docs on the ARIN site that describe the request process. Capsule summary: 1. Ask for what you think you need 2. Be prepared for pushback 3. Keep good records on utilization 4. If you fill up your initial allocation, you use your utilization records to justify a subsequent allocation And of course step 0 is to begin your IPv6 deployment plan ASAP. Yesterday would be good, a year or 2 ago would have been better. :) hth, Doug From mysidia at gmail.com Sat Jul 20 01:19:41 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 19 Jul 2013 20:19:41 -0500 Subject: ARIN question In-Reply-To: References: Message-ID: On 7/19/13, Warren Bailey wrote: > All, > Does anyone have a baseline on the "maximum" allocation a small to mid-sized > ISP can receive from ARIN? I realize resources are scarce in IPv4 land, and > I am a bit nervous to initiate the process myself without an understanding > of what can/cannot be allocated. I'm not looking for anything insane, maybe https://www.arin.net/policy/nrpm.html ^ There's not a predefined "maximum" allocation, there are maximums that apply in certain circumstances; the maximum is a 3 month supply of IP addresses that you have documented justification for, subject to the slow-start rule (I'm assuming you can't show justified need for a /8 or other allocation size which the free pool exhaustion would make impossible); if you don't already have a /22, you can't apply for a /16, for example, under the normal allocation policy. There is a minimum allocation size, and you need to meet the requirements shown in the policy. -- -JH From sh.vahabzadeh at gmail.com Sat Jul 20 19:30:34 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 21 Jul 2013 00:00:34 +0430 Subject: OSPF and Forcing a Subnet Message-ID: Dear Friends, I have an OSPF over GRE configuration sending you below in which I have problem. I want to force OSPF to advertise 172.16/16 range without checking anything. And as you see I have an static route for it in routing table but again OSPF do not advertise it, only it advertise when I put one /32 subnet on loopback interface. even I put "redistribute static subnets" command with/without route-map but again do not work. I think because of having my providers address range in my static routes, routers and ospf confused when wanna advertise routers. interface Tunnel0 > ip address 128.140.40.2 255.255.255.252 > tunnel source 10.20.76.2 > tunnel destination 10.20.75.2 > interface GigabitEthernet0/0 > description UPSTREAM - INTRANET > ip address 10.20.76.2 255.255.255.248 > interface GigabitEthernet0/1 > description CONNECTED ROUTER > ip address 10.20.76.9 255.255.255.248 > > router ospf 10 > log-adjacency-changes > area 10 range 172.16.0.0 255.255.0.0 > passive-interface default > no passive-interface Tunnel0 > network 172.16.0.0 0.0.255.255 area 10 > network 128.140.40.0 0.0.0.3 area 0 > ip route 0.0.0.0 0.0.0.0 10.20.76.1 > ip route 172.16.0.0 255.255.224.0 10.20.76.12 > ip route 10.20.76.0 255.255.255.0 10.20.76.12 > ip route 10.20.77.0 255.255.255.0 10.20.76.12 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 jlewis at lewis.org Sat Jul 20 19:52:00 2013 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 20 Jul 2013 15:52:00 -0400 (EDT) Subject: OSPF and Forcing a Subnet In-Reply-To: References: Message-ID: You don't have a route for 172.16/16 in the config below, so ospf will not advertise it. You do have a route for a subnet of 172.16/16, so either use summary-address 172.16.0.0 255.255.0.0 or nail up a static route for 172.16.0.0 255.255.0.0 to null0 and redistribute static subnets, and then ospf can redistribute that static route. On Sun, 21 Jul 2013, Shahab Vahabzadeh wrote: > Dear Friends, > I have an OSPF over GRE configuration sending you below in which I have > problem. > I want to force OSPF to advertise 172.16/16 range without checking anything. > And as you see I have an static route for it in routing table but again > OSPF do not advertise it, only it advertise when I put one /32 subnet on > loopback interface. > even I put "redistribute static subnets" command with/without route-map but > again do not work. > I think because of having my providers address range in my static routes, > routers and ospf confused when wanna advertise routers. > > > interface Tunnel0 >> ip address 128.140.40.2 255.255.255.252 >> tunnel source 10.20.76.2 >> tunnel destination 10.20.75.2 >> interface GigabitEthernet0/0 >> description UPSTREAM - INTRANET >> ip address 10.20.76.2 255.255.255.248 >> interface GigabitEthernet0/1 >> description CONNECTED ROUTER >> ip address 10.20.76.9 255.255.255.248 >> >> router ospf 10 >> log-adjacency-changes >> area 10 range 172.16.0.0 255.255.0.0 >> passive-interface default >> no passive-interface Tunnel0 >> network 172.16.0.0 0.0.255.255 area 10 >> network 128.140.40.0 0.0.0.3 area 0 >> ip route 0.0.0.0 0.0.0.0 10.20.76.1 >> ip route 172.16.0.0 255.255.224.0 10.20.76.12 >> ip route 10.20.76.0 255.255.255.0 10.20.76.12 >> ip route 10.20.77.0 255.255.255.0 10.20.76.12 > > > > 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 > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sh.vahabzadeh at gmail.com Sat Jul 20 19:55:30 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 21 Jul 2013 00:25:30 +0430 Subject: OSPF and Forcing a Subnet In-Reply-To: References: Message-ID: Dear Jon I have a mistake in my last email, there is a static route like this: ip route 172.16.0.0 255.255.0.0 10.20.76.12 but again it is redistributing On Sun, Jul 21, 2013 at 12:22 AM, Jon Lewis wrote: > You don't have a route for 172.16/16 in the config below, so ospf will not > advertise it. You do have a route for a subnet of 172.16/16, so either use > summary-address 172.16.0.0 255.255.0.0 or nail up a static route for > 172.16.0.0 255.255.0.0 to null0 and redistribute static subnets, and then > ospf can redistribute that static route. > > > On Sun, 21 Jul 2013, Shahab Vahabzadeh wrote: > > Dear Friends, >> I have an OSPF over GRE configuration sending you below in which I have >> problem. >> I want to force OSPF to advertise 172.16/16 range without checking >> anything. >> And as you see I have an static route for it in routing table but again >> OSPF do not advertise it, only it advertise when I put one /32 subnet on >> loopback interface. >> even I put "redistribute static subnets" command with/without route-map >> but >> again do not work. >> I think because of having my providers address range in my static routes, >> routers and ospf confused when wanna advertise routers. >> >> >> interface Tunnel0 >> >>> ip address 128.140.40.2 255.255.255.252 >>> tunnel source 10.20.76.2 >>> tunnel destination 10.20.75.2 >>> interface GigabitEthernet0/0 >>> description UPSTREAM - INTRANET >>> ip address 10.20.76.2 255.255.255.248 >>> interface GigabitEthernet0/1 >>> description CONNECTED ROUTER >>> ip address 10.20.76.9 255.255.255.248 >>> >>> router ospf 10 >>> log-adjacency-changes >>> area 10 range 172.16.0.0 255.255.0.0 >>> passive-interface default >>> no passive-interface Tunnel0 >>> network 172.16.0.0 0.0.255.255 area 10 >>> network 128.140.40.0 0.0.0.3 area 0 >>> ip route 0.0.0.0 0.0.0.0 10.20.76.1 >>> ip route 172.16.0.0 255.255.224.0 10.20.76.12 >>> ip route 10.20.76.0 255.255.255.0 10.20.76.12 >>> ip route 10.20.77.0 255.255.255.0 10.20.76.12 >>> >> >> >> >> 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 >> >> > ------------------------------**------------------------------**---------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/**pgpfor PGP public key_________ > -- 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 randy_94108 at yahoo.com Sat Jul 20 20:51:37 2013 From: randy_94108 at yahoo.com (Randy) Date: Sat, 20 Jul 2013 13:51:37 -0700 (PDT) Subject: OSPF and Forcing a Subnet In-Reply-To: References: Message-ID: <1374353497.24249.YahooMailNeo@web184701.mail.ne1.yahoo.com> what you are seeing is the expected behavior. you are asking the router to generate a type 3 summary for a type 1 lsa that doesn't exist for area 10 via the "area 10 range' command" (also, that is why it works when you add a /32 to loopback) 172.16/16 is an external route. If you want to generate a type 5 aggregate use summary-addr as Jon has pointed out. Else, leave static in place, redist static subnets but remove "area 10 range 172.16.0.0 255.255.0.0" from ospf config. ./Randy _______________________________ > From: Shahab Vahabzadeh >To: Jon Lewis >Cc: nanog >Sent: Saturday, July 20, 2013 12:55 PM >Subject: Re: OSPF and Forcing a Subnet > > >Dear Jon I have a mistake in my last email, there is a static route like >this: > >ip route 172.16.0.0 255.255.0.0 10.20.76.12 > >but again it is redistributing > > >On Sun, Jul 21, 2013 at 12:22 AM, Jon Lewis wrote: > >> You don't have a route for 172.16/16 in the config below, so ospf will not >> advertise it.? You do have a route for a subnet of 172.16/16, so either use >> summary-address 172.16.0.0 255.255.0.0 or nail up a static route for >> 172.16.0.0 255.255.0.0 to null0 and redistribute static subnets, and then >> ospf can redistribute that static route. >> >> >> On Sun, 21 Jul 2013, Shahab Vahabzadeh wrote: >> >>? Dear Friends, >>> I have an OSPF over GRE configuration sending you below in which I have >>> problem. >>> I want to force OSPF to advertise 172.16/16 range without checking >>> anything. >>> And as you see I have an static route for it in routing table but again >>> OSPF do not advertise it, only it advertise when I put one /32 subnet on >>> loopback interface. >>> even I put "redistribute static subnets" command with/without route-map >>> but >>> again do not work. >>> I think because of having my providers address range in my static routes, >>> routers and ospf confused when wanna advertise routers. >>> >>> >>> interface Tunnel0 >>> >>>>? ip address 128.140.40.2 255.255.255.252 >>>>? tunnel source 10.20.76.2 >>>>? tunnel destination 10.20.75.2 >>>> interface GigabitEthernet0/0 >>>>? description UPSTREAM - INTRANET >>>>? ip address 10.20.76.2 255.255.255.248 >>>> interface GigabitEthernet0/1 >>>>? description CONNECTED ROUTER >>>>? ip address 10.20.76.9 255.255.255.248 >>>> >>>> router ospf 10 >>>>? log-adjacency-changes >>>>? area 10 range 172.16.0.0 255.255.0.0 >>>>? passive-interface default >>>>? no passive-interface Tunnel0 >>>>? network 172.16.0.0 0.0.255.255 area 10 >>>>? network 128.140.40.0 0.0.0.3 area 0 >>>> ip route 0.0.0.0 0.0.0.0 10.20.76.1 >>>> ip route 172.16.0.0 255.255.224.0 10.20.76.12 >>>> ip route 10.20.76.0 255.255.255.0 10.20.76.12 >>>> ip route 10.20.77.0 255.255.255.0 10.20.76.12 >>>> >>> >>> >>> >>> 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 >>> >>> >> ------------------------------**------------------------------**---------- >>? Jon Lewis, MCP :)? ? ? ? ???|? I route >>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |? therefore you are >> _________ http://www.lewis.org/~jlewis/**pgpfor PGP public key_________ >> > > > >-- >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 karim.adel at gmail.com Sun Jul 21 03:19:10 2013 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 21 Jul 2013 05:19:10 +0200 Subject: Vendors CLI Usability vs UNIX Shell Message-ID: Hello, My vendor is giving me speeches on how they are improving their product Serviceability, Usability and Manageability. They told me they are adding a lot of new way of doing things, introducing more Unix-like utilities and over all making CLI smarter by exposing more visibility into system status and stuff like that. I rarely look at what other vendors do but i am now interested in what one might have over the other, specially things that would stand out. I wouldnt imagine Huawei doing anything advanced there so i guess its J vs C on this front. But i'd be interested in comparing them to Unix/Linux Shells too. Regards, Kim From yang.yu.list at gmail.com Sun Jul 21 04:26:20 2013 From: yang.yu.list at gmail.com (Yang Yu) Date: Sun, 21 Jul 2013 00:26:20 -0400 Subject: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 Message-ID: It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an AS3549 customer. >From GBLX looking glass, ATL1 traceroute Protocol [ip]: ip Target IP address: 10.0.0.1 Source address: Numeric display [n]: n Timeout in seconds [3]: 1 Probe count [3]: 2 Minimum Time to Live [1]: 1 Maximum Time to Live [30]: 30 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.0.0.1 VRF info: (vrf in name/id, vrf out name/id) 1 te3-1-10G.par9.CTA1.GRU.gblx.net (67.16.142.26) 120 msec 124 msec 2 122.5.125.189.static.impsat.net.br (189.125.5.122) 120 msec 120 msec 3 10.0.0.1 [AS 262487] 124 msec 120 msec Apparently the customer didn't have proper inbound filter...... Reply from 10.0.0.1: bytes=32 time=132ms TTL=61 From LarrySheldon at cox.net Sun Jul 21 04:31:22 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Jul 2013 23:31:22 -0500 Subject: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 In-Reply-To: <2sT91m01V1Una3W01sTAdy> References: <2sT91m01V1Una3W01sTAdy> Message-ID: <51EB641A.2090301@cox.net> On 7/20/2013 11:26 PM, Yang Yu wrote: > It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an > AS3549 customer. I wonder why people don't drop any update that contains stuff like RFC 1918 space. -- 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 sh.vahabzadeh at gmail.com Sun Jul 21 05:05:48 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 21 Jul 2013 09:35:48 +0430 Subject: OSPF and Forcing a Subnet In-Reply-To: <1374353497.24249.YahooMailNeo@web184701.mail.ne1.yahoo.com> References: <1374353497.24249.YahooMailNeo@web184701.mail.ne1.yahoo.com> Message-ID: Dear Randy, Thanks for your help, but 172.16/16 belong to that region and for example 172.17/16 belong to another one and I want to ospf bring me the whole subnet not which I used. And summary-address does not to this for me. Thanks On Sun, Jul 21, 2013 at 1:21 AM, Randy wrote: > what you are seeing is the expected behavior. > > you are asking the router to generate a type 3 summary for a type 1 lsa > that doesn't exist for area 10 via the "area 10 range' command" (also, that > is why it works when you add a /32 to loopback) > > 172.16/16 is an external route. If you want to generate a type 5 aggregate > use summary-addr as Jon has pointed out. Else, leave static in place, > redist static subnets but remove "area 10 range 172.16.0.0 255.255.0.0" > from ospf config. > ./Randy > > > > > _______________________________ > > From: Shahab Vahabzadeh > >To: Jon Lewis > >Cc: nanog > >Sent: Saturday, July 20, 2013 12:55 PM > >Subject: Re: OSPF and Forcing a Subnet > > > > > >Dear Jon I have a mistake in my last email, there is a static route like > >this: > > > >ip route 172.16.0.0 255.255.0.0 10.20.76.12 > > > >but again it is redistributing > > > > > >On Sun, Jul 21, 2013 at 12:22 AM, Jon Lewis wrote: > > > >> You don't have a route for 172.16/16 in the config below, so ospf will > not > >> advertise it. You do have a route for a subnet of 172.16/16, so either > use > >> summary-address 172.16.0.0 255.255.0.0 or nail up a static route for > >> 172.16.0.0 255.255.0.0 to null0 and redistribute static subnets, and > then > >> ospf can redistribute that static route. > >> > >> > >> On Sun, 21 Jul 2013, Shahab Vahabzadeh wrote: > >> > >> Dear Friends, > >>> I have an OSPF over GRE configuration sending you below in which I have > >>> problem. > >>> I want to force OSPF to advertise 172.16/16 range without checking > >>> anything. > >>> And as you see I have an static route for it in routing table but again > >>> OSPF do not advertise it, only it advertise when I put one /32 subnet > on > >>> loopback interface. > >>> even I put "redistribute static subnets" command with/without route-map > >>> but > >>> again do not work. > >>> I think because of having my providers address range in my static > routes, > >>> routers and ospf confused when wanna advertise routers. > >>> > >>> > >>> interface Tunnel0 > >>> > >>>> ip address 128.140.40.2 255.255.255.252 > >>>> tunnel source 10.20.76.2 > >>>> tunnel destination 10.20.75.2 > >>>> interface GigabitEthernet0/0 > >>>> description UPSTREAM - INTRANET > >>>> ip address 10.20.76.2 255.255.255.248 > >>>> interface GigabitEthernet0/1 > >>>> description CONNECTED ROUTER > >>>> ip address 10.20.76.9 255.255.255.248 > >>>> > >>>> router ospf 10 > >>>> log-adjacency-changes > >>>> area 10 range 172.16.0.0 255.255.0.0 > >>>> passive-interface default > >>>> no passive-interface Tunnel0 > >>>> network 172.16.0.0 0.0.255.255 area 10 > >>>> network 128.140.40.0 0.0.0.3 area 0 > >>>> ip route 0.0.0.0 0.0.0.0 10.20.76.1 > >>>> ip route 172.16.0.0 255.255.224.0 10.20.76.12 > >>>> ip route 10.20.76.0 255.255.255.0 10.20.76.12 > >>>> ip route 10.20.77.0 255.255.255.0 10.20.76.12 > >>>> > >>> > >>> > >>> > >>> 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 > >>> > >>> > >> > ------------------------------**------------------------------**---------- > >> Jon Lewis, MCP :) | I route > >> | therefore you are > >> _________ http://www.lewis.org/~jlewis/**pgp< > http://www.lewis.org/~jlewis/pgp>for PGP public key_________ > >> > > > > > > > >-- > >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 > > > > > > > -- 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 streiner at cluebyfour.org Sun Jul 21 05:33:06 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 21 Jul 2013 01:33:06 -0400 (EDT) Subject: Vendors CLI Usability vs UNIX Shell In-Reply-To: References: Message-ID: On Sun, 21 Jul 2013, Kasper Adel wrote: > My vendor is giving me speeches on how they are improving their > product Serviceability, Usability and Manageability. They told me they > are adding a lot of new way of doing things, introducing more Unix-like > utilities and over all making CLI smarter by exposing more visibility into > system status and stuff like that. So... catching up with where many other vendors have been for years? > I wouldnt imagine Huawei doing anything advanced there so i guess its J vs > C on this front. But i'd be interested in comparing them to Unix/Linux > Shells too. JunOS is pretty much BSD on top of specialized hardware, so a lot of the CLI functionality is Unix-like. You can pipe the output of a command into another command, do regex matching, tab auto-completion, start shells, etc. Cisco is leaning in that direction, depending on the platform. IOS has some of the same functionality, but NX-OS is built on a Linux kernel, so the Unix-like functionality is 'closer to the surface' than it is with IOS. Some other vendors' gear (F5, Infoblox) is built on a Linux kernel, so their CLIs are often 'shells' within that environment, and how much access to the underlying OS depends on what the CLI allows you to do. I'm not too sure what other major vendors' CLIs look like, so I can't comment on them. Also, some vendors offer other ways of managing their gear (web interfaces, proprietary GUIs (there is a special place in hell for these vendors), etc. One thing to watch out for is whether parity exists between the CLI and whatever other means the vendor provides for managing their stuff. I can think of a few cases where this isn't (or wasn't) the case. jms From drohan at gmail.com Sun Jul 21 05:51:18 2013 From: drohan at gmail.com (Daniel Rohan) Date: Sat, 20 Jul 2013 22:51:18 -0700 Subject: Vendors CLI Usability vs UNIX Shell In-Reply-To: References: Message-ID: On Sat, Jul 20, 2013 at 10:33 PM, Justin M. Streiner < streiner at cluebyfour.org> wrote: > One thing to watch out for is whether parity exists between the CLI and > whatever other means the vendor provides for managing their stuff. I can > think of a few cases where this isn't (or wasn't) the case. Riverbed RiOS deserves a special shaming for this particular practice. From fernando at gont.com.ar Sun Jul 21 15:29:23 2013 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 21 Jul 2013 17:29:23 +0200 Subject: Article: "IPv6 addressing requires special attention to ensure security" Message-ID: <51EBFE53.4020103@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, I've just realized that about a month ago Techtarget published an article I authored for them entitled "IPv6 addressing requires special attention to ensure security". The article is available at: (the ful article is available at the aforementioned URL, *without* the need to register --- just scroll down past the ad as necessary). Thanks, - -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR6/5AAAoJEJbuqe/Qdv/x9f4IAK+ST64iqq/LXVAcEojhv94f 2wovt/fK/tjBXrm8xy0XjiQCnit/tAULnRFtBxmpw4dwgWO9Ih6npELHCTC+loia olbONSb9y60iP4I8Deou5+V8jVv6sdDwxSFJP32ZVFN2GoPGyzIPN02qDIrbAtUT TwVmWsgcJopb9IWnd/NTgTsRzu7a2eeiS/9Nfm0Qdth7LRQhD+pU90lbI0lCxPCT 2cT42rFfP6hC2cieMWwVvghT3tbaL04qU7YPV3LIshbaPaYk6R8KZPYg4kzNs6z4 h1g3EEl6RShCxYAYZAKvF7I4bkZof71nQ21JdelaVHPBUKhpSffrKzfjufHh89M= =a7O6 -----END PGP SIGNATURE----- From martin.stiemerling at neclab.eu Mon Jul 22 08:30:02 2013 From: martin.stiemerling at neclab.eu (Martin Stiemerling) Date: Mon, 22 Jul 2013 10:30:02 +0200 Subject: forming an IETF AQM working group Message-ID: <51ECED8A.8030605@neclab.eu> Hi, For those who are interested in Active Queue Management (AQM): The IETF is trying to start a working group in the Transport Area to focus on Active Queue Management (AQM) and packet scheduling or fair queuing algorithms. There is a mailing list setup at: https://www.ietf.org/mailman/listinfo/aqm Anyone interested is free and welcomed to join the discussion. We especially want to have people with different perspectives participating, including hardware and software developers for different types of systems, network operators, academics, etc. There will also be a Birds of a Feather (BoF) meeting at the IETF meeting in Berlin (http://www.ietf.org/meeting/87) later this month, which we wanted to make people aware of. The goal of the meeting is to form a working group following the meeting. A draft charter that is being discussed can be found here: http://www.ietf.org/mail-archive/web/aqm/current/msg00165.html Thanks, Martin -- IETF Transport Area Director martin.stiemerling at neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From David.Siegel at Level3.com Mon Jul 22 19:36:18 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Mon, 22 Jul 2013 19:36:18 +0000 Subject: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 In-Reply-To: <51EB641A.2090301@cox.net> References: <2sT91m01V1Una3W01sTAdy> <51EB641A.2090301@cox.net> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05BE294E5@USIDCWVEMBX05.corp.global.level3.com> This should now be fixed. As a general matter of policy, we do filter out 10/8, but somehow the filter list for a customer was empty which then defaults to an implicit accept. We're in the process of improving our config audits to catch this in the future. Dave -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Saturday, July 20, 2013 10:31 PM To: nanog at nanog.org Subject: Re: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 On 7/20/2013 11:26 PM, Yang Yu wrote: > It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an > AS3549 customer. I wonder why people don't drop any update that contains stuff like RFC 1918 space. -- 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 morrowc.lists at gmail.com Mon Jul 22 19:44:39 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Jul 2013 15:44:39 -0400 Subject: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC05BE294E5@USIDCWVEMBX05.corp.global.level3.com> References: <51EB641A.2090301@cox.net> <970945E55BFD8C4EA4CAD74B647A9DC05BE294E5@USIDCWVEMBX05.corp.global.level3.com> Message-ID: On Mon, Jul 22, 2013 at 3:36 PM, Siegel, David wrote: > This should now be fixed. > > As a general matter of policy, we do filter out 10/8, but somehow the filter list for a customer was empty which then defaults to an implicit accept. We're in the process of improving our config audits to catch this in the future. > what happens if they register a route object for 10/8? :) > Dave > > > > -----Original Message----- > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > Sent: Saturday, July 20, 2013 10:31 PM > To: nanog at nanog.org > Subject: Re: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 > > On 7/20/2013 11:26 PM, Yang Yu wrote: >> It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an >> AS3549 customer. > > I wonder why people don't drop any update that contains stuff like RFC > 1918 space. > -- > 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 chip.gwyn at gmail.com Mon Jul 22 19:53:27 2013 From: chip.gwyn at gmail.com (chip) Date: Mon, 22 Jul 2013 15:53:27 -0400 Subject: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 In-Reply-To: References: <51EB641A.2090301@cox.net> <970945E55BFD8C4EA4CAD74B647A9DC05BE294E5@USIDCWVEMBX05.corp.global.level3.com> Message-ID: Perhaps we should all take a moment and review RFC 5735, 6598, 6890, and 5156 and implement filtering in the appropriate places and help make the Internet a safer place to play. Think of the children! ...heh --chip On Mon, Jul 22, 2013 at 3:44 PM, Christopher Morrow wrote: > On Mon, Jul 22, 2013 at 3:36 PM, Siegel, David > wrote: > > This should now be fixed. > > > > As a general matter of policy, we do filter out 10/8, but somehow the > filter list for a customer was empty which then defaults to an implicit > accept. We're in the process of improving our config audits to catch this > in the future. > > > > what happens if they register a route object for 10/8? :) > > > Dave > > > > > > > > -----Original Message----- > > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > > Sent: Saturday, July 20, 2013 10:31 PM > > To: nanog at nanog.org > > Subject: Re: AS3549 Level3/GBLX carrying routing for 10.0.0.0/8 > > > > On 7/20/2013 11:26 PM, Yang Yu wrote: > >> It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an > >> AS3549 customer. > > > > I wonder why people don't drop any update that contains stuff like RFC > > 1918 space. > > -- > > 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) > > > > > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From owen at delong.com Mon Jul 22 21:34:03 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2013 17:04:03 -0430 Subject: ARIN question In-Reply-To: References: Message-ID: <51F2DBC2-DAE3-4272-9F19-F6B2B3A82381@delong.com> On Jul 19, 2013, at 8:49 PM, Jimmy Hess wrote: > On 7/19/13, Warren Bailey wrote: >> All, >> Does anyone have a baseline on the "maximum" allocation a small to mid-sized >> ISP can receive from ARIN? I realize resources are scarce in IPv4 land, and >> I am a bit nervous to initiate the process myself without an understanding >> of what can/cannot be allocated. I'm not looking for anything insane, maybe > > https://www.arin.net/policy/nrpm.html > ^ > > There's not a predefined "maximum" allocation, there are maximums > that apply in certain circumstances; the maximum is a 3 month supply > of IP addresses that you have documented justification for, subject > to the slow-start rule (I'm assuming you can't show justified need > for a /8 or other allocation size which the free pool exhaustion > would make impossible); if you don't already have a /22, you can't > apply for a /16, for example, under the normal allocation policy. > > There is a minimum allocation size, and you need to meet the > requirements shown in the policy. > To clarify, the time horizons in policy depend on the nature of the request. ISPs are currently limited to 3 months for IPv4. End users can get 12 months IPv4. ISPs or end users can get up to 24 months IPv4 through the transfer process. IPv6 does not have a clearly defined time horizon and long-term (~5 years) planning is recommended when preparing an IPv6 request. Owen From m4rtntns at gmail.com Tue Jul 23 08:18:30 2013 From: m4rtntns at gmail.com (Martin T) Date: Tue, 23 Jul 2013 11:18:30 +0300 Subject: common practice for IP address announcement agreement if addresses belong to other ISP Message-ID: Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. However, what if customer, who has it's own AS number, wants to buy IP transit from RIPE region ISP using addresses from APNIC region and customer claims that owner of those addresses in APNIC region allows him to do so? Common sense suggest that if one wants to announce someone else address space, then they should inform the owner of the address space and the owner of the address space needs to agree. Is there a common practice how this agreement should look like? A simple e-mail? A signed document, which is scanned and sent from address space owner to ISP who wants to announce those addresses? regards, Martin From bmeshier at amherst.com Tue Jul 23 16:40:06 2013 From: bmeshier at amherst.com (Meshier, Brent) Date: Tue, 23 Jul 2013 16:40:06 +0000 Subject: Comcast Message-ID: <68C2CBC977F3E04799DF9C76E938E7091F26EB@DFEXCH1.asglp.com> Need a phone number for Comcast corporate. Trying to resolve issues across all our sites nationwide and their phone system is driving me insane. **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst's views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. From mikeal.clark at gmail.com Tue Jul 23 17:02:10 2013 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Tue, 23 Jul 2013 12:02:10 -0500 Subject: Charter Business Cable Network contact? Message-ID: Anyone with visibility of Charter's Business network in Wisconsin available for a quick discussion off list? Thanks, From brez at brezworks.com Wed Jul 24 14:59:41 2013 From: brez at brezworks.com (Jeremy Bresley) Date: Wed, 24 Jul 2013 09:59:41 -0500 Subject: 48V DC Terminal server recommendations Message-ID: <51EFEBDD.4010704@brezworks.com> Looking for recommendations on a good terminal server to put into a telco colocate facility. Requirements: 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or better) compliance. So far I've found Perle has several models that meet 3 out of 4, but none that meet all the requirements. The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Anybody have any recommendations for one they've used that meets all 4 of those requirements? Thanks! Jeremy "TheBrez" Bresley brez at brezworks.com From bill at herrin.us Wed Jul 24 15:08:46 2013 From: bill at herrin.us (William Herrin) Date: Wed, 24 Jul 2013 11:08:46 -0400 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: On Wed, Jul 24, 2013 at 10:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. Hi Jeremy, Have you considered the obvious: a Cisco 2610/2811 or equivalent with a 16 port async NM card, an analog modem WIC card and a DC power supply? I didn't see it on the list of things you'd considered. 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 Jul 24 15:14:53 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 24 Jul 2013 15:14:53 +0000 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: Uplogix. Sent from my Mobile Device. -------- Original message -------- From: Jeremy Bresley Date: 07/24/2013 8:02 AM (GMT-08:00) To: nanog at nanog.org Subject: 48V DC Terminal server recommendations Looking for recommendations on a good terminal server to put into a telco colocate facility. Requirements: 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or better) compliance. So far I've found Perle has several models that meet 3 out of 4, but none that meet all the requirements. The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Anybody have any recommendations for one they've used that meets all 4 of those requirements? Thanks! Jeremy "TheBrez" Bresley brez at brezworks.com From michael at supermathie.net Wed Jul 24 15:14:58 2013 From: michael at supermathie.net (Michael Brown) Date: Wed, 24 Jul 2013 11:14:58 -0400 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: <51EFEF72.3010008@supermathie.net> On 13-07-24 10:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a > telco colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have > to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > Avocent's (formerly Cyclades) ACS devices meet all of your constraints: http://www.emersonnetworkpower.com/documents/en-us/brands/avocent/documents/datasheets/01/acs6000-ds-en.pdf M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From joe at nethead.com Wed Jul 24 15:18:08 2013 From: joe at nethead.com (Joe Hamelin) Date: Wed, 24 Jul 2013 08:18:08 -0700 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: I guess Cyclades is now Avocent, used these at Clearwire. Can come with dual 48VDC supplies. Think of a 48 serial port Linux box. Has PCM/CIA slot for modem. Multiple users can be logged in at the same time. http://www.emersonnetworkpower.com/en-US/Products/InfrastructureManagement/SerialConsoles/Pages/AvocentACS6000AdvancedConsoleServer.aspx -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention > anything about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > > From wbailey at satelliteintelligencegroup.com Wed Jul 24 15:31:55 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 24 Jul 2013 15:31:55 +0000 Subject: 48V DC Terminal server recommendations In-Reply-To: References: <51EFEBDD.4010704@brezworks.com>, Message-ID: We used these quite a bit. Uplogix has some interesting automation, and the phone line/OOB is pretty slick. One cool thing about uplogix is it has a surgical rollback feature. You can set many different conditions and rules, and the router will dutifully execute a fall back procedure automatically. We had a switch plugged in, and I did a port range and added "shut" to all of the ports. Once they all went down, uplogix noticed and after a pre defined time it went back in and restored to the last known good configuration. If these bells and whistles don't blow your skirt up, check out the website. Sent from my Mobile Device. -------- Original message -------- From: Joe Hamelin Date: 07/24/2013 8:23 AM (GMT-08:00) To: Jeremy Bresley Cc: NANOG list Subject: Re: 48V DC Terminal server recommendations I guess Cyclades is now Avocent, used these at Clearwire. Can come with dual 48VDC supplies. Think of a 48 serial port Linux box. Has PCM/CIA slot for modem. Multiple users can be logged in at the same time. http://www.emersonnetworkpower.com/en-US/Products/InfrastructureManagement/SerialConsoles/Pages/AvocentACS6000AdvancedConsoleServer.aspx -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention > anything about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > > From nanog at ijg.me.uk Wed Jul 24 15:34:55 2013 From: nanog at ijg.me.uk (Ian Goodall) Date: Wed, 24 Jul 2013 16:34:55 +0100 Subject: 48V DC Terminal server recommendations In-Reply-To: References: <51EFEBDD.4010704@brezworks.com> Message-ID: <29BEACC0-02EB-43BF-BF32-6935A1C5B847@ijg.me.uk> On 24 Jul 2013, at 15:59, Jeremy Bresley wrote: > The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Not sure about NEBS but we use the Opengear IM4200 range which meet your other requirements: http://opengear.com/product-im4200.html -48v and Cisco pinout available. I guess the small 4 port units you found were the ACM5000s. These come with an external transformer which is a pain to rack mount unlike the larger IM4200. Avocent were good when I used them a few years ago but very expensive. Ian From davidpeahi at gmail.com Wed Jul 24 15:49:25 2013 From: davidpeahi at gmail.com (david peahi) Date: Wed, 24 Jul 2013 08:49:25 -0700 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: We have used the Avocent console/power terminal servers for several years. Although the browser interface is cluttered, and the use of Java sometimes poses connectivity challengesm Avocent is a useful console server for all types of devices, and has the ability to remotely power-cycle AC and DC devices. Avocent devices meet your specs (-48V PS, NEBS compliance). Regards, David On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention > anything about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > > From jackson.tim at gmail.com Wed Jul 24 15:52:35 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Wed, 24 Jul 2013 08:52:35 -0700 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: Digi TS-16 Works well, but doesn't have USB/modem.. MRV's LX line meets all of that, but I've had mixed issues with reliability with them.. On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention anything > about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > From jra at baylink.com Wed Jul 24 15:57:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 24 Jul 2013 11:57:38 -0400 (EDT) Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> Message-ID: <3437569.1986.1374681458084.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeremy Bresley" > NEBS Level 1 (or better) compliance. Do you require NEBS "compliance" or the much more expensive still "NEBS certification"? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cliff.bowles at apollogrp.edu Wed Jul 24 16:11:12 2013 From: cliff.bowles at apollogrp.edu (Cliff Bowles) Date: Wed, 24 Jul 2013 09:11:12 -0700 Subject: NANOG Digest, Vol 66, Issue 60 In-Reply-To: References: Message-ID: <1A5C3257AD8D4946A4B497A6FAF501743AA981E009@EXCH07-01.apollogrp.edu> +1 on the Cyclades (Avocent). We have about 8 of them spread across 3 data centers. We've used them for roughly 4-5 years. Won't say they are intuitive to set up, but once they are, they work well. Don't think I've seen one go down, but then again, they aren't subject to much change. Cost was pretty reasonable, but that's relative to your business/budget. -CWB -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Wednesday, July 24, 2013 8:59 AM To: nanog at nanog.org Subject: NANOG Digest, Vol 66, Issue 60 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. 48V DC Terminal server recommendations (Jeremy Bresley) 2. Re: 48V DC Terminal server recommendations (William Herrin) 3. RE: 48V DC Terminal server recommendations (Warren Bailey) 4. Re: 48V DC Terminal server recommendations (Michael Brown) 5. Re: 48V DC Terminal server recommendations (Joe Hamelin) 6. Re: 48V DC Terminal server recommendations (Warren Bailey) 7. Re: 48V DC Terminal server recommendations (Ian Goodall) 8. Re: 48V DC Terminal server recommendations (david peahi) 9. Re: 48V DC Terminal server recommendations (Tim Jackson) 10. Re: 48V DC Terminal server recommendations (Jay Ashworth) ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Jul 2013 09:59:41 -0500 From: Jeremy Bresley To: nanog at nanog.org Subject: 48V DC Terminal server recommendations Message-ID: <51EFEBDD.4010704 at brezworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Looking for recommendations on a good terminal server to put into a telco colocate facility. Requirements: 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or better) compliance. So far I've found Perle has several models that meet 3 out of 4, but none that meet all the requirements. The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Anybody have any recommendations for one they've used that meets all 4 of those requirements? Thanks! Jeremy "TheBrez" Bresley brez at brezworks.com ------------------------------ Message: 2 Date: Wed, 24 Jul 2013 11:08:46 -0400 From: William Herrin To: Jeremy Bresley Cc: nanog at nanog.org Subject: Re: 48V DC Terminal server recommendations Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 24, 2013 at 10:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a > telco colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have > to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or > better) compliance. Hi Jeremy, Have you considered the obvious: a Cisco 2610/2811 or equivalent with a 16 port async NM card, an analog modem WIC card and a DC power supply? I didn't see it on the list of things you'd considered. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ------------------------------ Message: 3 Date: Wed, 24 Jul 2013 15:14:53 +0000 From: Warren Bailey To: Jeremy Bresley , "nanog at nanog.org" Subject: RE: 48V DC Terminal server recommendations Message-ID: Content-Type: text/plain; charset="iso-8859-1" Uplogix. Sent from my Mobile Device. -------- Original message -------- From: Jeremy Bresley Date: 07/24/2013 8:02 AM (GMT-08:00) To: nanog at nanog.org Subject: 48V DC Terminal server recommendations Looking for recommendations on a good terminal server to put into a telco colocate facility. Requirements: 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or better) compliance. So far I've found Perle has several models that meet 3 out of 4, but none that meet all the requirements. The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Anybody have any recommendations for one they've used that meets all 4 of those requirements? Thanks! Jeremy "TheBrez" Bresley brez at brezworks.com ------------------------------ Message: 4 Date: Wed, 24 Jul 2013 11:14:58 -0400 From: Michael Brown To: Jeremy Bresley Cc: nanog at nanog.org Subject: Re: 48V DC Terminal server recommendations Message-ID: <51EFEF72.3010008 at supermathie.net> Content-Type: text/plain; charset=ISO-8859-1 On 13-07-24 10:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a > telco colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have > to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > Avocent's (formerly Cyclades) ACS devices meet all of your constraints: http://www.emersonnetworkpower.com/documents/en-us/brands/avocent/documents/datasheets/01/acs6000-ds-en.pdf M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian ------------------------------ Message: 5 Date: Wed, 24 Jul 2013 08:18:08 -0700 From: Joe Hamelin To: Jeremy Bresley Cc: NANOG list Subject: Re: 48V DC Terminal server recommendations Message-ID: Content-Type: text/plain; charset=ISO-8859-1 I guess Cyclades is now Avocent, used these at Clearwire. Can come with dual 48VDC supplies. Think of a 48 serial port Linux box. Has PCM/CIA slot for modem. Multiple users can be logged in at the same time. http://www.emersonnetworkpower.com/en-US/Products/InfrastructureManagement/SerialConsoles/Pages/AvocentACS6000AdvancedConsoleServer.aspx -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention > anything about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > > ------------------------------ Message: 6 Date: Wed, 24 Jul 2013 15:31:55 +0000 From: Warren Bailey To: Joe Hamelin , Jeremy Bresley Cc: NANOG list Subject: Re: 48V DC Terminal server recommendations Message-ID: Content-Type: text/plain; charset="iso-8859-1" We used these quite a bit. Uplogix has some interesting automation, and the phone line/OOB is pretty slick. One cool thing about uplogix is it has a surgical rollback feature. You can set many different conditions and rules, and the router will dutifully execute a fall back procedure automatically. We had a switch plugged in, and I did a port range and added "shut" to all of the ports. Once they all went down, uplogix noticed and after a pre defined time it went back in and restored to the last known good configuration. If these bells and whistles don't blow your skirt up, check out the website. Sent from my Mobile Device. -------- Original message -------- From: Joe Hamelin Date: 07/24/2013 8:23 AM (GMT-08:00) To: Jeremy Bresley Cc: NANOG list Subject: Re: 48V DC Terminal server recommendations I guess Cyclades is now Avocent, used these at Clearwire. Can come with dual 48VDC supplies. Think of a 48 serial port Linux box. Has PCM/CIA slot for modem. Multiple users can be logged in at the same time. http://www.emersonnetworkpower.com/en-US/Products/InfrastructureManagement/SerialConsoles/Pages/AvocentACS6000AdvancedConsoleServer.aspx -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention > anything about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > > ------------------------------ Message: 7 Date: Wed, 24 Jul 2013 16:34:55 +0100 From: Ian Goodall To: Jeremy Bresley Cc: nanog at nanog.org Subject: Re: 48V DC Terminal server recommendations Message-ID: <29BEACC0-02EB-43BF-BF32-6935A1C5B847 at ijg.me.uk> Content-Type: text/plain; charset=iso-8859-1 On 24 Jul 2013, at 15:59, Jeremy Bresley wrote: > The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Not sure about NEBS but we use the Opengear IM4200 range which meet your other requirements: http://opengear.com/product-im4200.html -48v and Cisco pinout available. I guess the small 4 port units you found were the ACM5000s. These come with an external transformer which is a pain to rack mount unlike the larger IM4200. Avocent were good when I used them a few years ago but very expensive. Ian ------------------------------ Message: 8 Date: Wed, 24 Jul 2013 08:49:25 -0700 From: david peahi To: Jeremy Bresley Cc: NANOG Subject: Re: 48V DC Terminal server recommendations Message-ID: Content-Type: text/plain; charset=ISO-8859-1 We have used the Avocent console/power terminal servers for several years. Although the browser interface is cluttered, and the use of Java sometimes poses connectivity challengesm Avocent is a useful console server for all types of devices, and has the ability to remotely power-cycle AC and DC devices. Avocent devices meet your specs (-48V PS, NEBS compliance). Regards, David On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention > anything about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > > ------------------------------ Message: 9 Date: Wed, 24 Jul 2013 08:52:35 -0700 From: Tim Jackson To: Jeremy Bresley Cc: nanog list Subject: Re: 48V DC Terminal server recommendations Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Digi TS-16 Works well, but doesn't have USB/modem.. MRV's LX line meets all of that, but I've had mixed issues with reliability with them.. On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley wrote: > Looking for recommendations on a good terminal server to put into a telco > colocate facility. > > Requirements: > 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) > -48V DC power > USB/internal modem for OOB access > NEBS Level 1 (or better) compliance. > > So far I've found Perle has several models that meet 3 out of 4, but none > that meet all the requirements. The only OpenGear boxes we're seeing with > DC power is a little 4 port unit and they don't mention NEBS compliance. > Lantronix mentions DC power for their SLC line, but doesn't mention anything > about NEBS compliance either. > > Anybody have any recommendations for one they've used that meets all 4 of > those requirements? > > Thanks! > > Jeremy "TheBrez" Bresley > brez at brezworks.com > ------------------------------ Message: 10 Date: Wed, 24 Jul 2013 11:57:38 -0400 (EDT) From: Jay Ashworth To: NANOG Subject: Re: 48V DC Terminal server recommendations Message-ID: <3437569.1986.1374681458084.JavaMail.root at benjamin.baylink.com> Content-Type: text/plain; charset=utf-8 ----- Original Message ----- > From: "Jeremy Bresley" > NEBS Level 1 (or better) compliance. Do you require NEBS "compliance" or the much more expensive still "NEBS certification"? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 End of NANOG Digest, Vol 66, Issue 60 ************************************* This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From cma at cmadams.net Wed Jul 24 17:08:11 2013 From: cma at cmadams.net (Chris Adams) Date: Wed, 24 Jul 2013 12:08:11 -0500 Subject: 48V DC Terminal server recommendations In-Reply-To: References: <51EFEBDD.4010704@brezworks.com> Message-ID: <20130724170811.GA8343@cmadams.net> Once upon a time, Joe Hamelin said: > I guess Cyclades is now Avocent And Avocent is part of Emerson (for several years now actually). -- Chris Adams From charles-lists at knownelement.com Wed Jul 24 17:55:11 2013 From: charles-lists at knownelement.com (Charles N Wyble) Date: Wed, 24 Jul 2013 12:55:11 -0500 Subject: 48V DC Terminal server recommendations In-Reply-To: References: <51EFEBDD.4010704@brezworks.com> Message-ID: <24f7693f-cd6b-4a41-a6ef-fc812ce83b56@email.android.com> I just use SSH to ip:portnum . Used the web ui for initial setup. Never used an applet. Didn't know one existed. This is on an acs48 model. I forget the pdu model (cyclades i something), they just daisychain off the acs and you can hit a key combo to powercycle. david peahi wrote: >We have used the Avocent console/power terminal servers for several >years. >Although the browser interface is cluttered, and the use of Java >sometimes >poses connectivity challengesm Avocent is a useful console server for >all >types of devices, and has the ability to remotely power-cycle AC and DC >devices. >Avocent devices meet your specs (-48V PS, NEBS compliance). > >Regards, > >David > > >On Wed, Jul 24, 2013 at 7:59 AM, Jeremy Bresley >wrote: > >> Looking for recommendations on a good terminal server to put into a >telco >> colocate facility. >> >> Requirements: >> 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we >have to) >> -48V DC power >> USB/internal modem for OOB access >> NEBS Level 1 (or better) compliance. >> >> So far I've found Perle has several models that meet 3 out of 4, but >none >> that meet all the requirements. The only OpenGear boxes we're seeing >with >> DC power is a little 4 port unit and they don't mention NEBS >compliance. >> Lantronix mentions DC power for their SLC line, but doesn't mention >> anything about NEBS compliance either. >> >> Anybody have any recommendations for one they've used that meets all >4 of >> those requirements? >> >> Thanks! >> >> Jeremy "TheBrez" Bresley >> brez at brezworks.com >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From wingrum at yahoo.com Wed Jul 24 18:44:46 2013 From: wingrum at yahoo.com (Bill Ingrum) Date: Wed, 24 Jul 2013 11:44:46 -0700 (PDT) Subject: Verizon MPLS / BGP help needed Message-ID: <1374691486.94231.YahooMailNeo@web120005.mail.ne1.yahoo.com> Hello, ? In my experience, all MPLS providers allow their customers to influence their own BGP route metrics by sending community values to the provider, with the provider adjusting metrics (such as local preference), based on these BGP communities (reference = http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801475b2.shtml). ? I sent a simple request to our Verizon reps, asking for the community syntax required to perform this task on a Verizon MPLS network.? I expected a list of acceptable communities in the form of ASN:xxx (example:? 65000:120 to set local preference to 120). ? My contacts at Verizon are insisting that this ?feature? is not available and will not be available until September 2013!? From my perspective, they are basically telling me that we are not allowed to enforce our own route policy on our own network. ? If someone from Verizon is able to help, I would appreciate an offline response. ? Thank you! ? Bill From universe at truemetal.org Wed Jul 24 22:23:04 2013 From: universe at truemetal.org (Markus) Date: Thu, 25 Jul 2013 00:23:04 +0200 Subject: CLEC willing to offer rev-share Message-ID: <51F053C8.3010500@truemetal.org> Hello! Since there are not only ISPs on this list but also CLECs: I have a few million minutes to US DIDs every month but my current DID provider is not offering any revenue share. I'd like to change that. Any CLEC here who is willing to share a bit of the revenue with me? Operators in other countries: please get in touch as well! Regards Markus From crogers at inerail.net Thu Jul 25 01:50:35 2013 From: crogers at inerail.net (Chris Rogers) Date: Wed, 24 Jul 2013 21:50:35 -0400 Subject: Verizon MPLS / BGP help needed In-Reply-To: <1374691486.94231.YahooMailNeo@web120005.mail.ne1.yahoo.com> References: <1374691486.94231.YahooMailNeo@web120005.mail.ne1.yahoo.com> Message-ID: This might be a starting point: http://onesc.net/communities/as701/ Not sure if it's accurate, as we don't have AS701 transit... Regards, Chris Rogers CEO, Inerail +1.302.357.3696 x2110 http://inerail.net/ On Wed, Jul 24, 2013 at 2:44 PM, Bill Ingrum wrote: > Hello, > > In my experience, > all MPLS providers allow their customers to influence their own BGP route > metrics by sending community values to the provider, with the provider > adjusting metrics (such as local preference), based on these BGP > communities > (reference = > http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801475b2.shtml > ). > > I sent a simple > request to our Verizon reps, asking for the community syntax required to > perform this task on a Verizon MPLS network. I expected a list of > acceptable communities in the form of ASN:xxx > (example: 65000:120 to set local > preference to 120). > > My contacts at > Verizon are insisting that this ?feature? is not available and will not be > available until September 2013! From my > perspective, they are basically telling me that we are not allowed to > enforce > our own route policy on our own network. > > If someone from > Verizon is able to help, I would appreciate an offline response. > > Thank you! > > Bill > From morrowc.lists at gmail.com Thu Jul 25 01:57:41 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 24 Jul 2013 21:57:41 -0400 Subject: Verizon MPLS / BGP help needed In-Reply-To: References: <1374691486.94231.YahooMailNeo@web120005.mail.ne1.yahoo.com> Message-ID: he needs the info for the PIP (Private IP) network though, which isn't covered in 701/2/3's data... the PIP network probably does NOT have this sort of capability, essentially the users are on their own to do some bgp policy on their side of the fence, since the MPLS network is enclosed and doesn't route to anything but 'you'... On Wed, Jul 24, 2013 at 9:50 PM, Chris Rogers wrote: > This might be a starting point: http://onesc.net/communities/as701/ > > Not sure if it's accurate, as we don't have AS701 transit... > > Regards, > Chris Rogers > CEO, Inerail > +1.302.357.3696 x2110 > http://inerail.net/ > > > On Wed, Jul 24, 2013 at 2:44 PM, Bill Ingrum wrote: > >> Hello, >> >> In my experience, >> all MPLS providers allow their customers to influence their own BGP route >> metrics by sending community values to the provider, with the provider >> adjusting metrics (such as local preference), based on these BGP >> communities >> (reference = >> http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801475b2.shtml >> ). >> >> I sent a simple >> request to our Verizon reps, asking for the community syntax required to >> perform this task on a Verizon MPLS network. I expected a list of >> acceptable communities in the form of ASN:xxx >> (example: 65000:120 to set local >> preference to 120). >> >> My contacts at >> Verizon are insisting that this ?feature? is not available and will not be >> available until September 2013! From my >> perspective, they are basically telling me that we are not allowed to >> enforce >> our own route policy on our own network. >> >> If someone from >> Verizon is able to help, I would appreciate an offline response. >> >> Thank you! >> >> Bill >> From frnkblk at iname.com Thu Jul 25 04:22:01 2013 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 24 Jul 2013 23:22:01 -0500 Subject: 48V DC Terminal server recommendations In-Reply-To: <51EFEBDD.4010704@brezworks.com> References: <51EFEBDD.4010704@brezworks.com> Message-ID: <009d01ce88ee$82fc9b70$88f5d250$@iname.com> I'm surprised no one mention WTI's product: http://www.wti.com/p-137-tsm-24dc-console-server-24-port-rj45-48v-dc.aspx It seems to lack NEBs compliancy, though. Frank -----Original Message----- From: Jeremy Bresley [mailto:brez at brezworks.com] Sent: Wednesday, July 24, 2013 10:00 AM To: nanog at nanog.org Subject: 48V DC Terminal server recommendations Looking for recommendations on a good terminal server to put into a telco colocate facility. Requirements: 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or better) compliance. So far I've found Perle has several models that meet 3 out of 4, but none that meet all the requirements. The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Anybody have any recommendations for one they've used that meets all 4 of those requirements? Thanks! Jeremy "TheBrez" Bresley brez at brezworks.com From cbrake at axeda.com Thu Jul 25 12:09:30 2013 From: cbrake at axeda.com (Charlie Brake) Date: Thu, 25 Jul 2013 12:09:30 +0000 Subject: 48V DC Terminal server recommendations In-Reply-To: <009d01ce88ee$82fc9b70$88f5d250$@iname.com> References: <51EFEBDD.4010704@brezworks.com> <009d01ce88ee$82fc9b70$88f5d250$@iname.com> Message-ID: <5F5F2A000DFB22479CBBD2863264EF66ADED0F@DAGN09c-e6.exg6.exghost.com> Lantronix SLC. Has USB modem. SLC is NEBS Level 3 compliant. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Thursday, July 25, 2013 12:22 AM To: 'Jeremy Bresley'; nanog at nanog.org Subject: RE: 48V DC Terminal server recommendations I'm surprised no one mention WTI's product: http://www.wti.com/p-137-tsm-24dc-console-server-24-port-rj45-48v-dc.aspx It seems to lack NEBs compliancy, though. Frank -----Original Message----- From: Jeremy Bresley [mailto:brez at brezworks.com] Sent: Wednesday, July 24, 2013 10:00 AM To: nanog at nanog.org Subject: 48V DC Terminal server recommendations Looking for recommendations on a good terminal server to put into a telco colocate facility. Requirements: 8-16 ports for Cisco console access (RJ-45s preferred, DB9s if we have to) -48V DC power USB/internal modem for OOB access NEBS Level 1 (or better) compliance. So far I've found Perle has several models that meet 3 out of 4, but none that meet all the requirements. The only OpenGear boxes we're seeing with DC power is a little 4 port unit and they don't mention NEBS compliance. Lantronix mentions DC power for their SLC line, but doesn't mention anything about NEBS compliance either. Anybody have any recommendations for one they've used that meets all 4 of those requirements? Thanks! Jeremy "TheBrez" Bresley brez at brezworks.com From jon.chleboun at gmail.com Thu Jul 25 13:32:21 2013 From: jon.chleboun at gmail.com (Jon Chleboun) Date: Thu, 25 Jul 2013 09:32:21 -0400 Subject: Homegrown SIP load testing platform Message-ID: I am interested to see if y'all have recommendations for putting together a SIP load testing platform using general purpose hardware and open-source (or inexpensive) software. We are aware of Empirix Hammer and similar solutions, and we are looking to see if there is an alternative option. Goals: - Generate somewhere on the order of 20k phone calls with real SIP and RTP. - Route the flows through our VoIP infrastructure to test performance limits. - Receive and analyze the SIP and RTP on the other end to find out at what load the signaling and/or media start to break down. Attempted already: - SIPp spread across many servers. Here the limiting factor seemed to be the CPU load from the interrupts from each packet. The CPU on the servers sending and receiving the phone calls got bogged down before the VoIP core. - We have dabbled with interrupt moderation in the NIC drivers, but this has not seemed to help very much. Looks interesting: - Has anyone had success using PF_RING with Direct NIC Access and libzero from the folks at ntop? Has anyone been able to use this with SIPp or some other SIP and RTP generator? Many thanks, Jon Chleboun From j at 2600hz.com Thu Jul 25 15:34:44 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 25 Jul 2013 15:34:44 +0000 Subject: Homegrown SIP load testing platform In-Reply-To: References: Message-ID: <53202048-388E-4C0F-BF54-2BC3465D13FD@2600hz.com> Hey Jon, This comes up on the voice ops list pretty regularly. Some folks have mentioned SIPVicious as a method for sip testing, but I think that's more for pentesting. The Empirix stuff seems to be the state of the art today. On a previous thread I talked a bit about quality monitoring and why the stuff in the industry today isn't really giving you the kinds of feedback you're looking for, but load testing is a different problem. If you do end up playing with the interrupt timers on the NICs, and you're successful, I'd love to hear what worked. Some food for thought: we've got a set of tickets open with the TAC because a large router (sorry I don't have the model number) bricked in a repeatable fashion at 300 calls per second. It shouldn't be true, but sometimes the gateway device is the limitation, although I don't know if this is applicable in your example. Anyways, I'm sorry I can't be of more help, but I personally see load testing at scale as a big unsolved problem for operators. Cheers, Joshua Sent from my iPad On Jul 25, 2013, at 7:32 AM, "Jon Chleboun" wrote: > I am interested to see if y'all have recommendations for putting together a > SIP load testing platform using general purpose hardware and open-source > (or inexpensive) software. We are aware of Empirix Hammer and similar > solutions, and we are looking to see if there is an alternative option. > > Goals: > - Generate somewhere on the order of 20k phone calls with real SIP and RTP. > - Route the flows through our VoIP infrastructure to test performance > limits. > - Receive and analyze the SIP and RTP on the other end to find out at what > load the signaling and/or media start to break down. > > Attempted already: > - SIPp spread across many servers. Here the limiting factor seemed to be > the CPU load from the interrupts from each packet. The CPU on the servers > sending and receiving the phone calls got bogged down before the VoIP core. > - We have dabbled with interrupt moderation in the NIC drivers, but this > has not seemed to help very much. > > Looks interesting: > - Has anyone had success using PF_RING with Direct NIC Access and libzero > from the folks at ntop? Has anyone been able to use this with SIPp or some > other SIP and RTP generator? > > > Many thanks, > > Jon Chleboun From justin.vocke at gmail.com Thu Jul 25 23:02:20 2013 From: justin.vocke at gmail.com (Justin Vocke) Date: Thu, 25 Jul 2013 18:02:20 -0500 Subject: ARIN WHOIS for leads Message-ID: Sent this little e-mail to ARIN: I'm not sure that you guys can do anything about this, but it's worth looking into. I registered AS626XX a week ago, and since it's registration, I've been getting calls from "wholesale" carriers trying to get me to purchase IP transit from them. Someone is obviously using your database of contact information to generate sales leads. 512-377-6827 was one of the numbers trying to get more information about my network and how they could "help" me. My guess is someone is using your mass whois database, looking at the most recently issued/created AS numbers, and cold calling. Just thought I'd pass this along. --------- Due to the amount of calls I've received, I'm guessing its probably a good idea to remove my contact info from the registration and setup role's instead. Does this sorta thing happen frequently with new registrations or did I just draw the short straw? Best, Justin From wbailey at satelliteintelligencegroup.com Thu Jul 25 23:19:42 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 25 Jul 2013 23:19:42 +0000 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: Wouldn't that defeat the purpose of maintaining the whois? We registered a few domains and get the same thing, I think it's something that people are going to have to live with. :/ Sent from my Mobile Device. -------- Original message -------- From: Justin Vocke Date: 07/25/2013 4:04 PM (GMT-08:00) To: nanog at nanog.org Subject: ARIN WHOIS for leads Sent this little e-mail to ARIN: I'm not sure that you guys can do anything about this, but it's worth looking into. I registered AS626XX a week ago, and since it's registration, I've been getting calls from "wholesale" carriers trying to get me to purchase IP transit from them. Someone is obviously using your database of contact information to generate sales leads. 512-377-6827 was one of the numbers trying to get more information about my network and how they could "help" me. My guess is someone is using your mass whois database, looking at the most recently issued/created AS numbers, and cold calling. Just thought I'd pass this along. --------- Due to the amount of calls I've received, I'm guessing its probably a good idea to remove my contact info from the registration and setup role's instead. Does this sorta thing happen frequently with new registrations or did I just draw the short straw? Best, Justin From surfer at mauigateway.com Thu Jul 25 23:20:27 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 25 Jul 2013 16:20:27 -0700 Subject: ARIN WHOIS for leads Message-ID: <20130725162027.122C415A@resin11.mta.everyone.net> --- justin.vocke at gmail.com wrote: From: Justin Vocke My guess is someone is using your mass whois database, looking at the most recently issued/created AS numbers, and cold calling. -------------------------------------------- I'd be interested in knowing who it is, so I can be sure to never buy from them. scott From surfer at mauigateway.com Thu Jul 25 23:24:29 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 25 Jul 2013 16:24:29 -0700 Subject: ARIN WHOIS for leads Message-ID: <20130725162429.122C41DB@resin11.mta.everyone.net> --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey We registered a few domains and get the same thing, I think it's something that people are going to have to live with. :/ ----------------------------------------------------------- No, we don't have to live with it. Name-n-shame and let us vote with our dollars. As I've said in the past, the ONLY thing they'll understand is negative impact to their bottom line... scott From otis at ocosa.com Thu Jul 25 23:29:03 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Thu, 25 Jul 2013 18:29:03 -0500 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Thursday, July 25, 2013 6:20 PM To: Justin Vocke; nanog at nanog.org Subject: RE: ARIN WHOIS for leads >Wouldn't that defeat the purpose of maintaining the whois? Yep! >We registered a few domains and get the same thing, I think it's something that people are going to have to live with. :/ I agree. We just politely tell them we are not interested and move on about our day. Some cold callers we have taken up on offers. It just depends who calls and whether or not we are looking for new service. WHOIS Privacy is nice for the domains and we use for some of our domains but not all. We just hate when customers get those scam notices and call us or open tickets about it. Otis -------- Original message -------- From: Justin Vocke Date: 07/25/2013 4:04 PM (GMT-08:00) To: nanog at nanog.org Subject: ARIN WHOIS for leads Sent this little e-mail to ARIN: I'm not sure that you guys can do anything about this, but it's worth looking into. I registered AS626XX a week ago, and since it's registration, I've been getting calls from "wholesale" carriers trying to get me to purchase IP transit from them. Someone is obviously using your database of contact information to generate sales leads. 512-377-6827 was one of the numbers trying to get more information about my network and how they could "help" me. My guess is someone is using your mass whois database, looking at the most recently issued/created AS numbers, and cold calling. Just thought I'd pass this along. --------- Due to the amount of calls I've received, I'm guessing its probably a good idea to remove my contact info from the registration and setup role's instead. Does this sorta thing happen frequently with new registrations or did I just draw the short straw? Best, Justin From wbailey at satelliteintelligencegroup.com Thu Jul 25 23:30:52 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 25 Jul 2013 23:30:52 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <20130725162429.122C41DB@resin11.mta.everyone.net> References: <20130725162429.122C41DB@resin11.mta.everyone.net> Message-ID: I read your response and totally agree. I'm just saying that your dollars not being spent with someone will probably not result in the calls stopping. Advertising and marketing dominates this planet now, and people make big money by selling "lists" to organizations making a buck. Not saying these people didn't get it directly, but it should not be expected to stop unless there is a do not call registry (as I would think those guys would fall under a telemarketing agency). I could be wrong.. Sent from my Mobile Device. -------- Original message -------- From: Scott Weeks Date: 07/25/2013 4:28 PM (GMT-08:00) To: nanog at nanog.org Subject: RE: ARIN WHOIS for leads --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey We registered a few domains and get the same thing, I think it's something that people are going to have to live with. :/ ----------------------------------------------------------- No, we don't have to live with it. Name-n-shame and let us vote with our dollars. As I've said in the past, the ONLY thing they'll understand is negative impact to their bottom line... scott From MGauvin at dryden.ca Thu Jul 25 23:30:38 2013 From: MGauvin at dryden.ca (Mark Gauvin) Date: Thu, 25 Jul 2013 18:30:38 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> Message-ID: <0B607F1E-3443-4893-8839-00BC782981C2@dryden.ca> Welcome to nanog aka the cold call jungle Sent from my iPhone On 2013-07-25, at 6:31 PM, "Otis L. Surratt, Jr." wrote: > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Thursday, July 25, 2013 6:20 PM > To: Justin Vocke; nanog at nanog.org > Subject: RE: ARIN WHOIS for leads > >> Wouldn't that defeat the purpose of maintaining the whois? > > Yep! > >> We registered a few domains and get the same thing, I think it's > something that people are going to have to live with. :/ > > I agree. We just politely tell them we are not interested and move on > about our day. Some cold callers we have taken up on offers. It just > depends who calls and whether or not we are looking for new service. > WHOIS Privacy is nice for the domains and we use for some of our domains > but not all. We just hate when customers get those scam notices and call > us or open tickets about it. > > Otis > > -------- Original message -------- > From: Justin Vocke > Date: 07/25/2013 4:04 PM (GMT-08:00) > To: nanog at nanog.org > Subject: ARIN WHOIS for leads > > > Sent this little e-mail to ARIN: > > I'm not sure that you guys can do anything about this, but it's worth > looking into. I registered AS626XX a week ago, and since it's > registration, I've been getting calls from "wholesale" carriers trying > to get me to purchase IP transit from them. Someone is obviously using > your database of contact information to generate sales leads. > > 512-377-6827 was one of the numbers trying to get more information about > my network and how they could "help" me. > > My guess is someone is using your mass whois database, looking at the > most recently issued/created AS numbers, and cold calling. > > Just thought I'd pass this along. > --------- > > Due to the amount of calls I've received, I'm guessing its probably a > good idea to remove my contact info from the registration and setup > role's instead. > > Does this sorta thing happen frequently with new registrations or did I > just draw the short straw? > > Best, > Justin > From wbailey at satelliteintelligencegroup.com Thu Jul 25 23:33:43 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 25 Jul 2013 23:33:43 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> References: , <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> Message-ID: I've had a guy calling me for 6 months about my phone number being selected to win a prize. This isn't on the company line, this is on the bat phone. I have told him numerous times I understand how he is contacting me and that I will not be sending him any money but that hasn't stopped the problem. Best thing to do is list a Google voice number on your whois and make the voice mail a greeting about how to email you. It's horrible, but I just can't see how it will stop. Sent from my Mobile Device. -------- Original message -------- From: "Otis L. Surratt, Jr." Date: 07/25/2013 4:29 PM (GMT-08:00) To: Warren Bailey ,Justin Vocke ,nanog at nanog.org Subject: RE: ARIN WHOIS for leads -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Thursday, July 25, 2013 6:20 PM To: Justin Vocke; nanog at nanog.org Subject: RE: ARIN WHOIS for leads >Wouldn't that defeat the purpose of maintaining the whois? Yep! >We registered a few domains and get the same thing, I think it's something that people are going to have to live with. :/ I agree. We just politely tell them we are not interested and move on about our day. Some cold callers we have taken up on offers. It just depends who calls and whether or not we are looking for new service. WHOIS Privacy is nice for the domains and we use for some of our domains but not all. We just hate when customers get those scam notices and call us or open tickets about it. Otis -------- Original message -------- From: Justin Vocke Date: 07/25/2013 4:04 PM (GMT-08:00) To: nanog at nanog.org Subject: ARIN WHOIS for leads Sent this little e-mail to ARIN: I'm not sure that you guys can do anything about this, but it's worth looking into. I registered AS626XX a week ago, and since it's registration, I've been getting calls from "wholesale" carriers trying to get me to purchase IP transit from them. Someone is obviously using your database of contact information to generate sales leads. 512-377-6827 was one of the numbers trying to get more information about my network and how they could "help" me. My guess is someone is using your mass whois database, looking at the most recently issued/created AS numbers, and cold calling. Just thought I'd pass this along. --------- Due to the amount of calls I've received, I'm guessing its probably a good idea to remove my contact info from the registration and setup role's instead. Does this sorta thing happen frequently with new registrations or did I just draw the short straw? Best, Justin From justin.vocke at gmail.com Thu Jul 25 23:37:42 2013 From: justin.vocke at gmail.com (Justin Vocke) Date: Thu, 25 Jul 2013 18:37:42 -0500 Subject: ARIN WHOIS for leads In-Reply-To: References: <20130725162429.122C41DB@resin11.mta.everyone.net> Message-ID: I'm pretty sure you have to sign a AUP or something to get access to the mass whois tool with ARIN, I'm just not sure of how they enforce what people are actually doing with the list. On Thu, Jul 25, 2013 at 6:30 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > I read your response and totally agree. I'm just saying that your dollars > not being spent with someone will probably not result in the calls > stopping. Advertising and marketing dominates this planet now, and people > make big money by selling "lists" to organizations making a buck. Not > saying these people didn't get it directly, but it should not be expected > to stop unless there is a do not call registry (as I would think those guys > would fall under a telemarketing agency). I could be wrong.. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Scott Weeks > Date: 07/25/2013 4:28 PM (GMT-08:00) > To: nanog at nanog.org > Subject: RE: ARIN WHOIS for leads > > > > > --- wbailey at satelliteintelligencegroup.com wrote: > From: Warren Bailey > > We registered a few domains and get the same thing, I think > it's something that people are going to have to live with. :/ > ----------------------------------------------------------- > > > No, we don't have to live with it. Name-n-shame and let us > vote with our dollars. As I've said in the past, the ONLY > thing they'll understand is negative impact to their bottom > line... > > scott > > From wbailey at satelliteintelligencegroup.com Thu Jul 25 23:41:32 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 25 Jul 2013 23:41:32 +0000 Subject: ARIN WHOIS for leads In-Reply-To: References: <20130725162429.122C41DB@resin11.mta.everyone.net> , Message-ID: I won't pretend to know how it's getting out there. Google your email address in about 10 minutes and see this conversation in 10 different lists. As Mark mentioned, this list has a lot of valuable eyes looking at it - so it's often a sales guy's wet dream. On the upside, solarwinds sent me a random 10 dollar amazon gift card a few weeks back so not all is lost.. ;) Sent from my Mobile Device. -------- Original message -------- From: Justin Vocke Date: 07/25/2013 4:37 PM (GMT-08:00) To: Warren Bailey Cc: surfer at mauigateway.com,nanog at nanog.org Subject: Re: ARIN WHOIS for leads I'm pretty sure you have to sign a AUP or something to get access to the mass whois tool with ARIN, I'm just not sure of how they enforce what people are actually doing with the list. On Thu, Jul 25, 2013 at 6:30 PM, Warren Bailey > wrote: I read your response and totally agree. I'm just saying that your dollars not being spent with someone will probably not result in the calls stopping. Advertising and marketing dominates this planet now, and people make big money by selling "lists" to organizations making a buck. Not saying these people didn't get it directly, but it should not be expected to stop unless there is a do not call registry (as I would think those guys would fall under a telemarketing agency). I could be wrong.. Sent from my Mobile Device. -------- Original message -------- From: Scott Weeks > Date: 07/25/2013 4:28 PM (GMT-08:00) To: nanog at nanog.org Subject: RE: ARIN WHOIS for leads --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey > We registered a few domains and get the same thing, I think it's something that people are going to have to live with. :/ ----------------------------------------------------------- No, we don't have to live with it. Name-n-shame and let us vote with our dollars. As I've said in the past, the ONLY thing they'll understand is negative impact to their bottom line... scott From surfer at mauigateway.com Thu Jul 25 23:50:41 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 25 Jul 2013 16:50:41 -0700 Subject: ARIN WHOIS for leads Message-ID: <20130725165041.122C4EB3@resin11.mta.everyone.net> --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey ...this list has a lot of valuable eyes looking at it - so it's often a sales guy's wet dream. ... ----------------------------------------------------------------- And when they see their names on this list as spammers they freak out. Trust me. It has happened in the past where I named-n-shamed and got immediate response from the sales droid's manager apologizing and letting me know it won't happen again. And it didn't. Don't let a $10 bribe skew the ugliness of spammers. scott From dseagrav at humancapitaldev.com Fri Jul 26 11:42:02 2013 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Fri, 26 Jul 2013 06:42:02 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <20130725162027.122C415A@resin11.mta.everyone.net> References: <20130725162027.122C415A@resin11.mta.everyone.net> Message-ID: <8659AB97-1CA4-4F9C-828D-DB572CFA7BD2@humancapitaldev.com> On Jul 25, 2013, at 6:20 PM, "Scott Weeks" wrote: > I'd be interested in knowing who it is, so I can be sure to > never buy from them. This is the way to go. Spammers and telemarketers don't do what they do for fun or malice, they do so because it's profitable. If people would stop buying from them and boycott them instead, they would stop. Anyone who buys from a spammer or telemarketer is just as guilty of perpetuating the problem as those who are building spam botnets or abusing insecure PBXes. From netsecguy at gmail.com Fri Jul 26 12:59:54 2013 From: netsecguy at gmail.com (NetSecGuy) Date: Fri, 26 Jul 2013 08:59:54 -0400 Subject: BGPmon.net /32 hijack alerts Message-ID: BGPMon.net has alerted me to /32 hijacks. Does anyone have thoughts on what this might be and if it's malicious or misconfiguration? Date OriginAS Prefix Type ASPath 2013.07.24 25459 72.52.11.117/32 A 286 25459 25459 25459 2013.07.24 25459 72.52.11.117/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 74.120.64.17/32 A 286 25459 25459 25459 2013.07.24 25459 74.120.64.17/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 77.243.235.57/32 A 286 25459 25459 25459 2013.07.24 25459 77.243.235.57/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 79.110.92.75/32 A 286 25459 25459 25459 2013.07.24 25459 79.110.92.75/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 79.170.88.67/32 A 286 25459 25459 25459 2013.07.24 25459 79.170.88.67/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 83.84.194.112/32 A 286 25459 25459 25459 2013.07.24 25459 83.84.194.112/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 89.33.242.99/32 A 286 25459 25459 25459 2013.07.24 25459 89.33.242.99/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 91.121.183.228/32 A 286 25459 25459 25459 2013.07.24 25459 91.121.183.228/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 91.121.82.179/32 A 286 25459 25459 25459 2013.07.24 25459 91.121.82.179/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 94.126.8.26/32 A 286 25459 25459 25459 2013.07.24 25459 94.126.8.26/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 94.23.207.222/32 A 286 25459 25459 25459 2013.07.24 25459 94.23.207.222/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 94.23.40.106/32 A 286 25459 25459 25459 2013.07.24 25459 94.23.40.106/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 94.236.46.240/32 A 286 25459 25459 25459 2013.07.24 25459 94.236.46.240/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 95.211.113.200/32 A 286 25459 25459 25459 2013.07.24 25459 95.211.113.200/32 A 3333 1103 286 25459 25459 25459 2013.07.24 25459 95.211.211.76/32 A 286 25459 25459 25459 2013.07.24 25459 95.211.211.76/32 A 3333 1103 286 25459 25459 25459 My first thought is leaked null routes. Is this even worth alerting on? From Grzegorz at Janoszka.pl Fri Jul 26 13:09:04 2013 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 26 Jul 2013 15:09:04 +0200 Subject: BGPmon.net /32 hijack alerts In-Reply-To: References: Message-ID: <51F274F0.2080902@Janoszka.pl> On 26-07-13 14:59, NetSecGuy wrote: > BGPMon.net has alerted me to /32 hijacks. Does anyone have thoughts on > what this might be and if it's malicious or misconfiguration? > My first thought is leaked null routes. Is this even worth alerting on? We had similar cases. In most cases they appeared to be indeed leaked null routes. -- Grzegorz Janoszka From job.snijders at atrato.com Fri Jul 26 13:12:56 2013 From: job.snijders at atrato.com (Job Snijders) Date: Fri, 26 Jul 2013 15:12:56 +0200 Subject: BGPmon.net /32 hijack alerts In-Reply-To: <51F274F0.2080902@Janoszka.pl> References: <51F274F0.2080902@Janoszka.pl> Message-ID: On Jul 26, 2013, at 3:09 PM, Grzegorz Janoszka wrote: > On 26-07-13 14:59, NetSecGuy wrote: >> BGPMon.net has alerted me to /32 hijacks. Does anyone have thoughts on >> what this might be and if it's malicious or misconfiguration? >> My first thought is leaked null routes. Is this even worth alerting on? > > We had similar cases. In most cases they appeared to be indeed leaked null routes. I'll poke AS 25459, they are fellow Dutchies Kind regards, Job From paradox at nac.net Fri Jul 26 13:32:57 2013 From: paradox at nac.net (Ryan Pavely) Date: Fri, 26 Jul 2013 09:32:57 -0400 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: <51F27A89.4080704@nac.net> What about the 2am phone calls from the guy, who did a nslookup on a website, and then whois on the ip, who is calling to say his porn site is partially not working and he's pissed. imho. The days of having public records like whois/rwhois available has passed. The data use to be protected with a simple clue test. Only the clue minded folks knew about the data, and were pretty responsible with it. Now anyone can look it up. We use to use that data to be able to directly communicate with another provider for a serious problem. It was great knowing exactly how to get a hold of someone, and not have to forage your way through tech support... noc.. etc.. Even the anti-spam army out there seem to ignore 'This is the abuse contact', and end up spamming all whois org contacts. What's the point in that? Why can't we implement a method where you have to be a registered, and paying, user/member with an AS number to be able to get IP whois 'contact' info? Sure list my name and company. But keep my email and phone number private. In fact show me a web log of all registered users that looked me up. I doubt that will ever happen. So it's time for me to update my arin contact as this past weekend I got exactly that 2am porn call and it was quite disturbing which website was being referenced. In all my years I knew there was some crazy stuff out there, but this took the cake. Ryan Pavely Net Access Corporation http://www.nac.net/ On 7/25/2013 7:02 PM, Justin Vocke wrote: > Sent this little e-mail to ARIN: > > I'm not sure that you guys can do anything about this, but it's worth > looking into. I registered AS626XX a week ago, and since it's registration, > I've been getting calls from "wholesale" carriers trying to get me to > purchase IP transit from them. Someone is obviously using your database of > contact information to generate sales leads. > > 512-377-6827 was one of the numbers trying to get more information about my > network and how they could "help" me. > > My guess is someone is using your mass whois database, looking at the most > recently issued/created AS numbers, and cold calling. > > Just thought I'd pass this along. > --------- > > Due to the amount of calls I've received, I'm guessing its probably a good > idea to remove my contact info from the registration and setup role's > instead. > > Does this sorta thing happen frequently with new registrations or did I > just draw the short straw? > > Best, > Justin From otis at ocosa.com Fri Jul 26 14:42:11 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 26 Jul 2013 09:42:11 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <51F27A89.4080704@nac.net> References: <51F27A89.4080704@nac.net> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> -----Original Message----- From: Ryan Pavely [mailto:paradox at nac.net] Sent: Friday, July 26, 2013 8:33 AM To: nanog at nanog.org Subject: Re: ARIN WHOIS for leads > Even the anti-spam army out there seem to ignore 'This is the abuse contact', and end up spamming all whois org contacts. What's the point in that? I agree. Most of them end up blasting all contacts which is completely stupid!!! That's why you see on the comment sections with many providers something along the lines of "Please use Abuse Handle or please send requests for DMCA to this handle" >Why can't we implement a method where you have to be a registered, and paying, user/member with an AS number to be able to get IP whois 'contact' info? Sure list my name and company. But keep my email and phone number private. In fact show me >a web log of all registered users that looked me up. This could be doable. But some minor details worked out or requirements. >I doubt that will ever happen. Have a little faith. ;-) If many providers wanted the feature, I'm sure ARIN would not have a problem implementing it. --Otis From patrick at ianai.net Fri Jul 26 14:46:30 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 26 Jul 2013 10:46:30 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> Message-ID: <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> On Jul 25, 2013, at 19:29 , "Otis L. Surratt, Jr." wrote: > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] >> Wouldn't that defeat the purpose of maintaining the whois? > > Yep! > >> We registered a few domains and get the same thing, I think it's > something that people are going to have to live with. :/ > > I agree. We just politely tell them we are not interested and move on > about our day. Some cold callers we have taken up on offers. It just > depends who calls and whether or not we are looking for new service. > WHOIS Privacy is nice for the domains and we use for some of our domains > but not all. We just hate when customers get those scam notices and call > us or open tickets about it. The fact you take some cold callers "up on offers" means they will continue to call. Please do not reward people who scrape whois or the NANOG-l archive. If it is not profitable to call people, they will stop. Put another way: You are making life worse for all of us. -- TTFN, patrick From Valdis.Kletnieks at vt.edu Fri Jul 26 14:52:58 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Jul 2013 10:52:58 -0400 Subject: ARIN WHOIS for leads In-Reply-To: Your message of "Fri, 26 Jul 2013 09:42:11 -0500." <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> Message-ID: <37731.1374850378@turing-police.cc.vt.edu> On Fri, 26 Jul 2013 09:42:11 -0500, "Otis L. Surratt, Jr." said: > > Even the anti-spam army out there seem to ignore 'This is the abuse > contact', and end up spamming all whois org contacts. What's the point > in that? > > I agree. Most of them end up blasting all contacts which is completely > stupid!!! That's why you see on the comment sections with many providers > something along the lines of "Please use Abuse Handle or please send > requests for DMCA to this handle" Well, if the community actually did it's job so mail to abuse@ and postmaster@ and similar role addresses actually got delivered instead of bouncing, and then actually did some good rather than being unread/ignored, maybe we wouldn't have to rely on a DNS jockey listed in a SOA record being pissed off enough at being cc'ed on an abuse mail to get a co-worker's butt in gear. Just sayin'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From patrick at ianai.net Fri Jul 26 14:58:23 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 26 Jul 2013 10:58:23 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <51F27A89.4080704@nac.net> References: <51F27A89.4080704@nac.net> Message-ID: <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> On Jul 26, 2013, at 09:32 , Ryan Pavely wrote: > What about the 2am phone calls from the guy, who did a nslookup on a website, and then whois on the ip, who is calling to say his porn site is partially not working and he's pissed. > > imho. The days of having public records like whois/rwhois available has passed. The data use to be protected with a simple clue test. Only the clue minded folks knew about the data, and were pretty responsible with it. Now anyone can look it up. We use to use that data to be able to directly communicate with another provider for a serious problem. It was great knowing exactly how to get a hold of someone, and not have to forage your way through tech support... noc.. etc.. > > Even the anti-spam army out there seem to ignore 'This is the abuse contact', and end up spamming all whois org contacts. What's the point in that? > > Why can't we implement a method where you have to be a registered, and paying, user/member with an AS number to be able to get IP whois 'contact' info? Sure list my name and company. But keep my email and phone number private. In fact show me a web log of all registered users that looked me up. > > I doubt that will ever happen. So it's time for me to update my arin contact as this past weekend I got exactly that 2am porn call and it was quite disturbing which website was being referenced. In all my years I knew there was some crazy stuff out there, but this took the cake. You can change anything you want. ARIN & ICANN are both member organizations. Propose a change, get the votes, and POOF!, things are changed. Even better, only the "clued" (and paid) get to vote. So it is exactly what you wanted. -- TTFN, patrick > On 7/25/2013 7:02 PM, Justin Vocke wrote: >> Sent this little e-mail to ARIN: >> >> I'm not sure that you guys can do anything about this, but it's worth >> looking into. I registered AS626XX a week ago, and since it's registration, >> I've been getting calls from "wholesale" carriers trying to get me to >> purchase IP transit from them. Someone is obviously using your database of >> contact information to generate sales leads. >> >> 512-377-6827 was one of the numbers trying to get more information about my >> network and how they could "help" me. >> >> My guess is someone is using your mass whois database, looking at the most >> recently issued/created AS numbers, and cold calling. >> >> Just thought I'd pass this along. >> --------- >> >> Due to the amount of calls I've received, I'm guessing its probably a good >> idea to remove my contact info from the registration and setup role's >> instead. >> >> Does this sorta thing happen frequently with new registrations or did I >> just draw the short straw? >> >> Best, >> Justin > > From drc at virtualized.org Fri Jul 26 15:05:58 2013 From: drc at virtualized.org (David Conrad) Date: Fri, 26 Jul 2013 08:05:58 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> Message-ID: <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> On Jul 26, 2013, at 7:58 AM, "Patrick W. Gilmore" wrote: > You can change anything you want. ARIN & ICANN are both member organizations. Propose a change, get the votes, and POOF!, things are changed. Err. ICANN isn't a membership organization. It is possible to change things at ICANN, but the mechanisms are ... different and much slower (since it involves getting consensus in a multi-stakeholder environment). Regards, -drc From snoble at sonn.com Fri Jul 26 15:06:53 2013 From: snoble at sonn.com (Steven Noble) Date: Fri, 26 Jul 2013 08:06:53 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> Message-ID: <89E6A2D7-E9C9-4713-91DF-327E2749B87A@sonn.com> On Jul 26, 2013, at 7:58 AM, Patrick W. Gilmore wrote: > On Jul 26, 2013, at 09:32 , Ryan Pavely wrote: > >> >> I doubt that will ever happen. So it's time for me to update my arin contact as this past weekend I got exactly that 2am porn call and it was quite disturbing which website was being referenced. In all my years I knew there was some crazy stuff out there, but this took the cake. > > You can change anything you want. ARIN & ICANN are both member organizations. Propose a change, get the votes, and POOF!, things are changed. > > Even better, only the "clued" (and paid) get to vote. So it is exactly what you wanted. Oh Patrick, you know that's not true.. I've been paying ARIN for 13 years and for many of those ARIN wouldn't even let me modify my ASN. I don't get a vote, but I pay. :) > > -- > TTFN, > patrick From Joel.Snyder at Opus1.COM Fri Jul 26 15:32:26 2013 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Fri, 26 Jul 2013 08:32:26 -0700 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: <51F2968A.3090701@opus1.com> >What about the 2am phone calls from the guy, who did a >nslookup on a website, and then whois on the ip, >who is calling to say his porn site >is partially not working and he's pissed. No amount of changing contacts is going to solve this type of problem. We routinely get support calls, sometimes even in the emergency support line, from people who are pissed off at an ISP 2,000 miles away called "Opus" something-or-another-but-not-Opus-One. Apparently their dialup service is not so hot anymore and when it doesn't work, the one-step-down-from-AOL customer base they attract types "opus" into their browser and then calls whatever phone number comes to the top of whatever search engine their browser vendor chose for them. Changing the nature of WHOIS isn't going to keep the stupid from doing stupid things. However, it might make life harder for the not-stupid trying to solve real problems. Honestly, this seems to me like a non-problem. I liken it to the hypersensitivity of some people to spam, where if they get 1 message through their filters it's somehow a major crisis. Maybe our ACD, which requires the clue-challenged to be able to spell the first or last name of the person their calling, or perhaps read the extension number from a directory listing, screens the worst of the worst out from us... I also don't see the problem of cold calling when it's obviously for a service or product that I am interested in, just as I don't see the problem of cold snail-mailing for the same services. I'm in business, and I expect other businesses to try and market to me. I don't want to hear from window, insurance, and other crap sellers, but if a Cisco reseller or bandwidth seller wants to make contact and say "how can I help you?" that doesn't seem out of line to me. Only in the world of email do we (justifiably) get all weirded out by the prospect of unsolicited sales pitches. It seems to me that if you don't want people to call you, don't give out your phone number (or give out a phone number that makes it hard for anyone but a real person who really wants to talk to you to get to you). How did our little capitalist industry suddenly become a "you must have permission to contact me by any means no matter what" industry? jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From patrick at ianai.net Fri Jul 26 15:40:12 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 26 Jul 2013 11:40:12 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> Message-ID: <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> On Jul 26, 2013, at 11:05 , David Conrad wrote: > On Jul 26, 2013, at 7:58 AM, "Patrick W. Gilmore" wrote: >> You can change anything you want. ARIN & ICANN are both member organizations. Propose a change, get the votes, and POOF!, things are changed. > > Err. ICANN isn't a membership organization. It is possible to change things at ICANN, but the mechanisms are ... different and much slower (since it involves getting consensus in a multi-stakeholder environment). Sure it is, the membership is just very .. uh .. selective. :) "Stakeholder" is just a fancy way of saying "member". They vote, things change. Like I said, this is _exactly_ what Ryan wanted. Only the "anointed" get to decide things. Works out well, doesn't it? -- TTFN, patrick From otis at ocosa.com Fri Jul 26 15:59:37 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 26 Jul 2013 10:59:37 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Friday, July 26, 2013 9:47 AM To: NANOG list Subject: Re: ARIN WHOIS for leads On Jul 25, 2013, at 19:29 , "Otis L. Surratt, Jr." wrote: > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] >> Wouldn't that defeat the purpose of maintaining the whois? > > Yep! > >> We registered a few domains and get the same thing, I think it's > something that people are going to have to live with. :/ > > I agree. We just politely tell them we are not interested and move on > about our day. Some cold callers we have taken up on offers. It just > depends who calls and whether or not we are looking for new service. > WHOIS Privacy is nice for the domains and we use for some of our > domains but not all. We just hate when customers get those scam > notices and call us or open tickets about it. >>The fact you take some cold callers "up on offers" means they will continue to call. >>Please do not reward people who scrape whois or the NANOG-l archive. If it is not profitable to call people, they will stop. >>Put another way: You are making life worse for all of us. >>-- >>TTFN, >>patrick I'm not sure how they receive their data or if they mined from other sources. But one can draw some conclusions that they get information from some list/database and if you are a new provider or a new recipient of number resources then yes; that's probably how ARIN WHOIS database. But why don't we take off our hat for one moment that would call this spam and simply look at it for what it is. I'm sure others would agree. Sales teams typically would compile a list of names and phone numbers in a local community and cold call to see if there is any interest. Waiting on folks to call you could be weeks, months and years thus adversely affecting your business. I'm sure every company has done some cold calling before. If you have not then you must have a customer base of that is making you the profit you desire and/or you are already a billionaire. Thus you the resources for advertisements on local/regional/national TV. (Not the only form of advertising BTW) I can name several tier 1 and 2 providers who have reached out to us for IP transit based on cold calling/ARIN WHOIS. We've been an ARIN paying member since 2005 and have not had any contact with any sales folks until last 4 to 5 years maybe. IMHO, you guys should get off this spam kick and simply tell folks you are not interested and move on about your day. Life is way too short. I'm not sure how cold calling is spamming? The folks that received the porn calls.... my response is SMH and I am very disgusted. But I definitely can understand your feelings for cold calling. Again, life is too short to get all worked up about it. Like I said before simply tell them not interested and don't call again. We do and we very seldom find a stubborn sales person that continue with repeated calls. For the ones we do we have our phone system immediately hang up their call based on number. If they someone how gain my or others mobile numbers we simply add as contact and send to voicemail. After a while they'll get the message. One I threaten him and he never called again. I wouldn't recommend but it worked! LOL Everyone's point is we shouldn't have to deal with or provide those types of workarounds for unprofessional sales folks that don't understand the word "NO". And I whole heartily agree. What happen to the days when you could simply tell someone not interested, don't call again and you wouldn't hear from them ever again????? Or the days when everything wasn't treated as spam???? --Otis From Valdis.Kletnieks at vt.edu Fri Jul 26 16:36:35 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Jul 2013 12:36:35 -0400 Subject: ARIN WHOIS for leads In-Reply-To: Your message of "Fri, 26 Jul 2013 10:59:37 -0500." <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> Message-ID: <5556.1374856595@turing-police.cc.vt.edu> On Fri, 26 Jul 2013 10:59:37 -0500, "Otis L. Surratt, Jr." said: > What happen to the days when you could simply tell someone not > interested, don't call again and you wouldn't hear from them ever > again????? It's not just networking - recently I received a cold call from a local company trying to sell me home improvements. I had the joy of reminding them that I explained to them that I rent and thus will not be even a remotely plausible customer, the *last* time they called me. You'd think with better analytics, this sort of thing would happen less, not more. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From brunner at nic-naa.net Fri Jul 26 16:38:54 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 26 Jul 2013 09:38:54 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> Message-ID: <51F2A61E.7040503@nic-naa.net> On 7/26/13 8:40 AM, Patrick W. Gilmore wrote: > On Jul 26, 2013, at 11:05 , David Conrad wrote: >> > On Jul 26, 2013, at 7:58 AM, "Patrick W. Gilmore" wrote: >>> >> You can change anything you want. ARIN & ICANN are both member organizations. Propose a change, get the votes, and POOF!, things are changed. >> > >> > Err. ICANN isn't a membership organization. It is possible to change things at ICANN, but the mechanisms are ... different and much slower (since it involves getting consensus in a multi-stakeholder environment). > Sure it is, the membership is just very .. uh .. selective. :) > > "Stakeholder" is just a fancy way of saying "member". They vote, things change. > > Like I said, this is _exactly_ what Ryan wanted. Only the "anointed" get to decide things. Works out well, doesn't it? Actually the member / non-member distinction is important in California corporations law. Also important is the distinction between agency of government and anything else, there's about two reams of double-sided 11pt text on the subject, and that's just between Michael Froomkin and Joe Simms. Cheers, Eric From scott at doc.net.au Fri Jul 26 16:46:48 2013 From: scott at doc.net.au (Scott Howard) Date: Fri, 26 Jul 2013 09:46:48 -0700 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: On Thu, Jul 25, 2013 at 4:02 PM, Justin Vocke wrote: > 512-377-6827 was one of the numbers trying to get more information about > my > network and how they could "help" me. > Which appears to be http://www.siptrunksproviders.com/ Which in turns appears to be the same company as http://giglinx.com/ Scott From wbailey at satelliteintelligencegroup.com Fri Jul 26 16:47:35 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 26 Jul 2013 16:47:35 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> Message-ID: My opinion: it's the rebuttal. Sales has come lightyears in the last 20 years, advertising is a direct reflection of that. If you visit a travel website, suddenly every website you visit for the next 2 weeks is how to buy what you didn't the first time. Case in point.. And I'm going to name drop, but do not consider this a shame. I have been looking at various filtering technologies, and was looking at Barracudas site. I went on with my day, but noticed that filtering vendors start showing up on random websites. Fast forward 24 hours later.. Any website I visit with any "major" advertising (Slashdot was where it was first VERY apparent) was socked with barracuda ads. We see talking at least 3 of 5 major ad spaces were now ONLY barracuda. It's called retargeting and they are using cookies to do it. The problem is, nearly everyone is doing this as the pay per click is substantially larger (something like 4x of regular). People want to make money, and this is a fantastic source of it. It annoys people, but I'm not so sure I'd call it spam. I almost think it's suggestive but just transparent enough so you don't feel like big business knows as much as they do. And I don't know how the rest of you have it, but if I get 10 bucks in the mail.. I'm spending it. Sent from my Mobile Device. -------- Original message -------- From: "Otis L. Surratt, Jr." Date: 07/26/2013 9:01 AM (GMT-08:00) To: "Patrick W. Gilmore" ,NANOG list Subject: RE: ARIN WHOIS for leads -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Friday, July 26, 2013 9:47 AM To: NANOG list Subject: Re: ARIN WHOIS for leads On Jul 25, 2013, at 19:29 , "Otis L. Surratt, Jr." wrote: > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] >> Wouldn't that defeat the purpose of maintaining the whois? > > Yep! > >> We registered a few domains and get the same thing, I think it's > something that people are going to have to live with. :/ > > I agree. We just politely tell them we are not interested and move on > about our day. Some cold callers we have taken up on offers. It just > depends who calls and whether or not we are looking for new service. > WHOIS Privacy is nice for the domains and we use for some of our > domains but not all. We just hate when customers get those scam > notices and call us or open tickets about it. >>The fact you take some cold callers "up on offers" means they will continue to call. >>Please do not reward people who scrape whois or the NANOG-l archive. If it is not profitable to call people, they will stop. >>Put another way: You are making life worse for all of us. >>-- >>TTFN, >>patrick I'm not sure how they receive their data or if they mined from other sources. But one can draw some conclusions that they get information from some list/database and if you are a new provider or a new recipient of number resources then yes; that's probably how ARIN WHOIS database. But why don't we take off our hat for one moment that would call this spam and simply look at it for what it is. I'm sure others would agree. Sales teams typically would compile a list of names and phone numbers in a local community and cold call to see if there is any interest. Waiting on folks to call you could be weeks, months and years thus adversely affecting your business. I'm sure every company has done some cold calling before. If you have not then you must have a customer base of that is making you the profit you desire and/or you are already a billionaire. Thus you the resources for advertisements on local/regional/national TV. (Not the only form of advertising BTW) I can name several tier 1 and 2 providers who have reached out to us for IP transit based on cold calling/ARIN WHOIS. We've been an ARIN paying member since 2005 and have not had any contact with any sales folks until last 4 to 5 years maybe. IMHO, you guys should get off this spam kick and simply tell folks you are not interested and move on about your day. Life is way too short. I'm not sure how cold calling is spamming? The folks that received the porn calls.... my response is SMH and I am very disgusted. But I definitely can understand your feelings for cold calling. Again, life is too short to get all worked up about it. Like I said before simply tell them not interested and don't call again. We do and we very seldom find a stubborn sales person that continue with repeated calls. For the ones we do we have our phone system immediately hang up their call based on number. If they someone how gain my or others mobile numbers we simply add as contact and send to voicemail. After a while they'll get the message. One I threaten him and he never called again. I wouldn't recommend but it worked! LOL Everyone's point is we shouldn't have to deal with or provide those types of workarounds for unprofessional sales folks that don't understand the word "NO". And I whole heartily agree. What happen to the days when you could simply tell someone not interested, don't call again and you wouldn't hear from them ever again????? Or the days when everything wasn't treated as spam???? --Otis From Joshua_Sholes at cable.comcast.com Fri Jul 26 16:40:22 2013 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Fri, 26 Jul 2013 16:40:22 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> Message-ID: On 7/26/13 11:59 AM, "Otis L. Surratt, Jr." wrote: >What happen to the days when you could simply tell someone not >interested, don't call again and you wouldn't hear from them ever >again????? >Or the days when everything wasn't treated as spam???? When the former days disappeared, the latter days did also. In that exact order. If marketing wants to talk about "nurturing" leads, then I don't want to be a lead. Period. My attitude changed the day I got my SIXTH call from the same sales guy who I'd told "I might have the budget and need next year to get $product, and if so I'll definitely call you. The problem is that in this day and age of autodialers and call centers, most of the incoming unsolicited communications anyone gets are of a nature that they cost the person initiating the conversation orders of magnitude less to send than it costs you to answer. In the snail mail days, that balance was a lot closer to even, and so you weren't getting constant bombardments of semi- or un-targeted marketing solely because you had a publicly visible contact path. -- Josh Sholes From alex at corp.nac.net Fri Jul 26 16:54:21 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 26 Jul 2013 12:54:21 -0400 Subject: ARIN WHOIS for leads In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> > Case in point.. And I'm going to name drop, but do not consider this a shame. > I have been looking at various filtering technologies, and was looking at > Barracudas site. I went on with my day, but noticed that filtering vendors > start showing up on random websites. Fast forward 24 hours later.. You know what I am waiting for? The LED billboards on the side of the road displaying targeted advertisements, based on your proximity to them, because your android phone is telling the sign where you are. Who thinks I am crazy? From wbailey at satelliteintelligencegroup.com Fri Jul 26 16:55:19 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 26 Jul 2013 16:55:19 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> , <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> Message-ID: You are not crazy. Sent from my Mobile Device. -------- Original message -------- From: Alex Rubenstein Date: 07/26/2013 9:53 AM (GMT-08:00) To: Warren Bailey ,"Otis L. Surratt, Jr." ,"Patrick W. Gilmore" ,NANOG list Subject: RE: ARIN WHOIS for leads > Case in point.. And I'm going to name drop, but do not consider this a shame. > I have been looking at various filtering technologies, and was looking at > Barracudas site. I went on with my day, but noticed that filtering vendors > start showing up on random websites. Fast forward 24 hours later.. You know what I am waiting for? The LED billboards on the side of the road displaying targeted advertisements, based on your proximity to them, because your android phone is telling the sign where you are. Who thinks I am crazy? From patrick at ianai.net Fri Jul 26 17:04:08 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 26 Jul 2013 13:04:08 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> Message-ID: <679A16A0-A57C-4194-B8E3-6EE00B3A8FF5@ianai.net> > What happen to the days when you could simply tell someone not > interested, don't call again and you wouldn't hear from them ever > again????? I don't know, but that is part of the reason why you can't ignore these people or buy from them. Ever heard of the "one bite at the apple" idea? Marketers think they should each be able to ask you just once to buy something from them. Ignoring the fact they ask more than once, in the US alone, there are 23 million small businesses . How many calls / emails do you want to get if even 10% of them decide they get _one_ chance to ask you to buy something? The reason this is not a problem for snail mail is there has to be a serious return to cover the cost of printing, postage, etc. What's the cost of sending 23 million emails? Two cents? > Or the days when everything wasn't treated as spam???? Everything is not. I admit that "the other side" frequently goes in-frickin'-sane and calls even non-scraped, individually addressed mail to a single person "spam". We shouldn't listen to them any more than we should listen to the marketer calling back the four time in a week to sell my father life insurance - after he had passed away. Suggestion: Put tagged addresses and, if possible, phone numbers in your ARIN whois and other public records. When someone emails that address or calls that number, make sure you put them on a "never buy from" list, and they know it. Write them a physical (form) letter, explaining why, and make it public (web page, blog, whatever. If even a small percentage of people did this, many companies would change their practices. _Especially_ Internet companies. -- TTFN, patrick On Jul 26, 2013, at 11:59 , "Otis L. Surratt, Jr." wrote: > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Friday, July 26, 2013 9:47 AM > To: NANOG list > Subject: Re: ARIN WHOIS for leads > > On Jul 25, 2013, at 19:29 , "Otis L. Surratt, Jr." > wrote: >> From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > >>> Wouldn't that defeat the purpose of maintaining the whois? >> >> Yep! >> >>> We registered a few domains and get the same thing, I think it's >> something that people are going to have to live with. :/ >> >> I agree. We just politely tell them we are not interested and move on >> about our day. Some cold callers we have taken up on offers. It just >> depends who calls and whether or not we are looking for new service. >> WHOIS Privacy is nice for the domains and we use for some of our >> domains but not all. We just hate when customers get those scam >> notices and call us or open tickets about it. > >>> The fact you take some cold callers "up on offers" means they will > continue to call. > >>> Please do not reward people who scrape whois or the NANOG-l archive. > If it is not profitable to call people, they will stop. > >>> Put another way: You are making life worse for all of us. > >>> -- >>> TTFN, >>> patrick > > I'm not sure how they receive their data or if they mined from other > sources. But one can draw some conclusions that they get information > from some list/database and if you are a new provider or a new recipient > of number resources then yes; that's probably how ARIN WHOIS database. > > But why don't we take off our hat for one moment that would call this > spam and simply look at it for what it is. I'm sure others would agree. > Sales teams typically would compile a list of names and phone numbers in > a local community and cold call to see if there is any interest. Waiting > on folks to call you could be weeks, months and years thus adversely > affecting your business. I'm sure every company has done some cold > calling before. If you have not then you must have a customer base of > that is making you the profit you desire and/or you are already a > billionaire. Thus you the resources for advertisements on > local/regional/national TV. (Not the only form of advertising BTW) > > I can name several tier 1 and 2 providers who have reached out to us for > IP transit based on cold calling/ARIN WHOIS. > We've been an ARIN paying member since 2005 and have not had any contact > with any sales folks until last 4 to 5 years maybe. > > IMHO, you guys should get off this spam kick and simply tell folks you > are not interested and move on about your day. Life is way too short. > I'm not sure how cold calling is spamming? > > The folks that received the porn calls.... my response is SMH and I am > very disgusted. But I definitely can understand your feelings for cold > calling. Again, life is too short to get all worked up about it. Like I > said before simply tell them not interested and don't call again. We do > and we very seldom find a stubborn sales person that continue with > repeated calls. For the ones we do we have our phone system immediately > hang up their call based on number. If they someone how gain my or > others mobile numbers we simply add as contact and send to voicemail. > After a while they'll get the message. One I threaten him and he never > called again. I wouldn't recommend but it worked! LOL > > Everyone's point is we shouldn't have to deal with or provide those > types of workarounds for unprofessional sales folks that don't > understand the word "NO". And I whole heartily agree. > > What happen to the days when you could simply tell someone not > interested, don't call again and you wouldn't hear from them ever > again????? > Or the days when everything wasn't treated as spam???? > > --Otis > > > From mike at mtcc.com Fri Jul 26 17:06:13 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 26 Jul 2013 10:06:13 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> Message-ID: <51F2AC85.7050204@mtcc.com> On 7/26/13 9:54 AM, Alex Rubenstein wrote: >> Case in point.. And I'm going to name drop, but do not consider this a shame. >> I have been looking at various filtering technologies, and was looking at >> Barracudas site. I went on with my day, but noticed that filtering vendors >> start showing up on random websites. Fast forward 24 hours later.. > You know what I am waiting for? > > The LED billboards on the side of the road displaying targeted advertisements, based on your proximity to them, because your android phone is telling the sign where you are. > > Who thinks I am crazy? > > Now, if it broadcast the grocery list and all I had to do is blink twice to approve it so that all I had to do is drive through... that i might be able to live with. Mike From patrick at ianai.net Fri Jul 26 17:06:53 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 26 Jul 2013 13:06:53 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> Message-ID: <03217FBC-62C5-4C93-BE03-517769A38649@ianai.net> On Jul 26, 2013, at 12:54 , Alex Rubenstein wrote: >> Case in point.. And I'm going to name drop, but do not consider this a shame. >> I have been looking at various filtering technologies, and was looking at >> Barracudas site. I went on with my day, but noticed that filtering vendors >> start showing up on random websites. Fast forward 24 hours later.. > > You know what I am waiting for? > > The LED billboards on the side of the road displaying targeted advertisements, based on your proximity to them, because your android phone is telling the sign where you are. > > Who thinks I am crazy? I do. Only 'cause you singled out Android, as if Apple, Blackberry, etc. wouldn't do this too. -- TTFN, patrick From Valdis.Kletnieks at vt.edu Fri Jul 26 17:06:39 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Jul 2013 13:06:39 -0400 Subject: ARIN WHOIS for leads In-Reply-To: Your message of "Fri, 26 Jul 2013 12:54:21 -0400." <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> Message-ID: <7415.1374858399@turing-police.cc.vt.edu> On Fri, 26 Jul 2013 12:54:21 -0400, Alex Rubenstein said: > The LED billboards on the side of the road displaying targeted > advertisements, based on your proximity to them, because your android phone is > telling the sign where you are. There's 6 other drivers within range. What set of targeted ads do you put up? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Fri Jul 26 17:21:45 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 26 Jul 2013 17:21:45 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <51F2AC85.7050204@mtcc.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net>, <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net>, <51F2AC85.7050204@mtcc.com> Message-ID: Blink twice? Is this 1996? I expect it to read my face like animals do. I simply do not care if it results in me riding in the Virgin spaceship. ;) Sent from my Mobile Device. -------- Original message -------- From: Michael Thomas Date: 07/26/2013 10:10 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: ARIN WHOIS for leads On 7/26/13 9:54 AM, Alex Rubenstein wrote: >> Case in point.. And I'm going to name drop, but do not consider this a shame. >> I have been looking at various filtering technologies, and was looking at >> Barracudas site. I went on with my day, but noticed that filtering vendors >> start showing up on random websites. Fast forward 24 hours later.. > You know what I am waiting for? > > The LED billboards on the side of the road displaying targeted advertisements, based on your proximity to them, because your android phone is telling the sign where you are. > > Who thinks I am crazy? > > Now, if it broadcast the grocery list and all I had to do is blink twice to approve it so that all I had to do is drive through... that i might be able to live with. Mike From goemon at anime.net Fri Jul 26 17:42:18 2013 From: goemon at anime.net (goemon at anime.net) Date: Fri, 26 Jul 2013 10:42:18 -0700 (PDT) Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> Message-ID: On Fri, 26 Jul 2013, Otis L. Surratt, Jr. wrote: > -----Original Message----- > From: Ryan Pavely [mailto:paradox at nac.net] > Sent: Friday, July 26, 2013 8:33 AM > To: nanog at nanog.org > Subject: Re: ARIN WHOIS for leads > > >> Even the anti-spam army out there seem to ignore 'This is the abuse > contact', and end up spamming all whois org contacts. What's the point > in that? > > I agree. Most of them end up blasting all contacts which is completely > stupid!!! That's why you see on the comment sections with many providers > something along the lines of "Please use Abuse Handle or please send > requests for DMCA to this handle" Because your mail servers are broken. Because you put spamfilters on your abuse@ mailbox, IF you even have an abuse@, which a lot of you don't. Because we tried calling, and your tier1 are clueless. Fix your mailservers. Train your staff. Staff your abuse desk. Then we'll talk. If your network didn't spew sewage into peoples mailboxes, and if you actually took action on abusive customers, this wouldn't be a problem. Some providers have responsive abuse desks. For the rest, well thats what RBL are for I guess. -Dan From bzs at world.std.com Fri Jul 26 18:21:48 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 26 Jul 2013 14:21:48 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <7415.1374858399@turing-police.cc.vt.edu> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> <2D0AF14BA6FB334988BC1F5D4FC38CB827E7B9B615@EXCHMBX.hq.nac.net> <7415.1374858399@turing-police.cc.vt.edu> Message-ID: <20978.48700.125872.727501@world.std.com> On July 26, 2013 at 13:06 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > On Fri, 26 Jul 2013 12:54:21 -0400, Alex Rubenstein said: > > The LED billboards on the side of the road displaying targeted > > advertisements, based on your proximity to them, because your android phone is > > telling the sign where you are. > > There's 6 other drivers within range. What set of targeted ads do you put up? Obviously what's needed are better heads-up displays which make personalized billboards only appear to be on the side of the road. Oh heck, with self-driving vehicles who needs billboards? They'll just blast ads onto your game or fb screen as the car zips itself along the road. Maybe that's the real motivation of autonomous vehicles, to free your eyeballs up for ads. -- -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 cscora at apnic.net Fri Jul 26 18:36:00 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Jul 2013 04:36:00 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201307261836.r6QIa0pD023390@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 27 Jul, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 460435 Prefixes after maximum aggregation: 186881 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 228600 Total ASes present in the Internet Routing Table: 44598 Prefixes per ASN: 10.32 Origin-only ASes present in the Internet Routing Table: 34884 Origin ASes announcing only one prefix: 16214 Transit ASes present in the Internet Routing Table: 5907 Transit-only ASes present in the Internet Routing Table: 148 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 3375 Unregistered ASNs in the Routing Table: 1298 Number of 32-bit ASNs allocated by the RIRs: 4901 Number of 32-bit ASNs visible in the Routing Table: 3807 Prefixes from 32-bit ASNs in the Routing Table: 11468 Special use prefixes present in the Routing Table: 29 Prefixes being announced from unallocated address space: 259 Number of addresses announced to Internet: 2631203148 Equivalent to 156 /8s, 212 /16s and 249 /24s Percentage of available address space announced: 71.1 Percentage of allocated address space announced: 71.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.8 Total number of prefixes smaller than registry allocations: 161515 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110492 Total APNIC prefixes after maximum aggregation: 33889 APNIC Deaggregation factor: 3.26 Prefixes being announced from the APNIC address blocks: 112225 Unique aggregates announced from the APNIC address blocks: 46027 APNIC Region origin ASes present in the Internet Routing Table: 4863 APNIC Prefixes per ASN: 23.08 APNIC Region origin ASes announcing only one prefix: 1221 APNIC Region transit ASes present in the Internet Routing Table: 828 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 614 Number of APNIC addresses announced to Internet: 726272224 Equivalent to 43 /8s, 74 /16s and 8 /24s Percentage of available APNIC address space announced: 84.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159674 Total ARIN prefixes after maximum aggregation: 80509 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 160279 Unique aggregates announced from the ARIN address blocks: 74140 ARIN Region origin ASes present in the Internet Routing Table: 15804 ARIN Prefixes per ASN: 10.14 ARIN Region origin ASes announcing only one prefix: 5999 ARIN Region transit ASes present in the Internet Routing Table: 1653 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1068179008 Equivalent to 63 /8s, 171 /16s and 30 /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: 117958 Total RIPE prefixes after maximum aggregation: 60387 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 121771 Unique aggregates announced from the RIPE address blocks: 78842 RIPE Region origin ASes present in the Internet Routing Table: 17315 RIPE Prefixes per ASN: 7.03 RIPE Region origin ASes announcing only one prefix: 8222 RIPE Region transit ASes present in the Internet Routing Table: 2833 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2378 Number of RIPE addresses announced to Internet: 656056228 Equivalent to 39 /8s, 26 /16s and 159 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 49151 Total LACNIC prefixes after maximum aggregation: 9509 LACNIC Deaggregation factor: 5.17 Prefixes being announced from the LACNIC address blocks: 53708 Unique aggregates announced from the LACNIC address blocks: 25426 LACNIC Region origin ASes present in the Internet Routing Table: 1993 LACNIC Prefixes per ASN: 26.95 LACNIC Region origin ASes announcing only one prefix: 584 LACNIC Region transit ASes present in the Internet Routing Table: 366 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 790 Number of LACNIC addresses announced to Internet: 133823624 Equivalent to 7 /8s, 249 /16s and 252 /24s Percentage of available LACNIC address space announced: 79.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: 11601 Total AfriNIC prefixes after maximum aggregation: 2546 AfriNIC Deaggregation factor: 4.56 Prefixes being announced from the AfriNIC address blocks: 12193 Unique aggregates announced from the AfriNIC address blocks: 3924 AfriNIC Region origin ASes present in the Internet Routing Table: 640 AfriNIC Prefixes per ASN: 19.05 AfriNIC Region origin ASes announcing only one prefix: 188 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46542848 Equivalent to 2 /8s, 198 /16s and 48 /24s Percentage of available AfriNIC address space announced: 46.2 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 2908 11560 919 Korea Telecom (KIX) 17974 2618 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2033 320 109 TPG Internet Pty Ltd 4755 1765 392 195 TATA Communications formerly 9829 1537 1221 45 BSNL National Internet Backbo 9583 1224 92 505 Sify Limited 4808 1173 2153 339 CNCGROUP IP network: China169 9498 1169 309 71 BHARTI Airtel Ltd. 7552 1160 1080 13 Vietel Corporation 24560 1086 394 164 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 2982 3690 65 bellsouth.net, inc. 18566 2067 382 184 Covad Communications 1785 2007 678 127 PaeTec Communications, Inc. 22773 2000 2927 124 Cox Communications, Inc. 20115 1670 1623 622 Charter Communications 4323 1616 1118 405 Time Warner Telecom 701 1524 11120 801 UUNET Technologies, Inc. 30036 1339 302 659 Mediacom Communications Corp 7018 1304 11036 821 AT&T WorldNet Services 11492 1221 218 363 Cable One 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 1578 544 16 Corbina telecom 34984 1296 244 222 BILISIM TELEKOM 2118 1235 97 13 EUnet/RELCOM Autonomous Syste 31148 976 43 22 FreeNet ISP 20940 939 327 738 Akamai Technologies European 13188 838 98 81 Educational Network 6830 831 2372 441 UPC Distribution Services 8551 779 370 45 Bezeq International 12479 685 793 56 Uni2 Autonomous System 34744 602 159 114 SC GVM SISTEM 2003 SRL 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 2957 1591 110 NET Servicos de Comunicao S.A 10620 2639 420 226 TVCABLE BOGOTA 7303 1730 1155 220 Telecom Argentina Stet-France 8151 1273 2750 385 UniNet S.A. de C.V. 18881 1247 844 20 Global Village Telecom 27947 833 94 91 Telconet S.A 6503 818 434 63 AVANTEL, S.A. 3816 719 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 621 88 65 Servicios Alestra S.A de C.V 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 1815 112 5 MOBITEL 24863 881 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 437 956 9 TEDATA 24835 345 80 8 RAYA Telecom - Egypt 3741 259 922 218 The Internet Solution 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 36992 206 527 22 Etisalat MISR 12258 193 28 71 Vodacom Internet Company 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 6389 2982 3690 65 bellsouth.net, inc. 28573 2957 1591 110 NET Servicos de Comunicao S.A 4766 2908 11560 919 Korea Telecom (KIX) 10620 2639 420 226 TVCABLE BOGOTA 17974 2618 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2067 382 184 Covad Communications 7545 2033 320 109 TPG Internet Pty Ltd 1785 2007 678 127 PaeTec Communications, Inc. 22773 2000 2927 124 Cox Communications, Inc. 36998 1815 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2957 2847 NET Servicos de Comunicao S.A 17974 2618 2526 PT TELEKOMUNIKASI INDONESIA 10620 2639 2413 TVCABLE BOGOTA 4766 2908 1989 Korea Telecom (KIX) 7545 2033 1924 TPG Internet Pty Ltd 18566 2067 1883 Covad Communications 1785 2007 1880 PaeTec Communications, Inc. 22773 2000 1876 Cox Communications, Inc. 36998 1815 1810 MOBITEL 4755 1765 1570 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 30621 UNALLOCATED 12.151.74.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2541 >>UNKNOWN<< 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.40.0/24 60449 >>UNKNOWN<< 128.0.42.0/24 60619 >>UNKNOWN<< 128.0.43.0/24 60619 >>UNKNOWN<< 128.0.45.0/24 60657 >>UNKNOWN<< 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. 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:11 /10:30 /11:92 /12:251 /13:478 /14:906 /15:1602 /16:12732 /17:6643 /18:11081 /19:22505 /20:32121 /21:34670 /22:48474 /23:42550 /24:242336 /25:1298 /26:1641 /27:848 /28:44 /29:71 /30:17 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 36998 1780 1815 MOBITEL 6389 1714 2982 bellsouth.net, inc. 22773 1302 2000 Cox Communications, Inc. 8402 1270 1578 Corbina telecom 30036 1205 1339 Mediacom Communications Corp 11492 1182 1221 Cable One 1785 1074 2007 PaeTec Communications, Inc. 6983 1020 1147 ITC^Deltacom 10620 984 2639 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:827 2:711 3:3 4:19 5:843 6:17 8:572 12:1912 13:2 14:864 15:11 16:3 17:10 20:17 23:296 24:1769 27:1504 31:1305 32:45 33:2 34:5 36:60 37:1849 38:890 39:2 40:175 41:3282 42:247 44:8 46:1946 47:2 49:673 50:817 52:12 54:35 55:8 57:26 58:1161 59:581 60:331 61:1424 62:1166 63:2009 64:4357 65:2149 66:4190 67:2022 68:1096 69:3285 70:797 71:490 72:1918 74:2500 75:324 76:306 77:1117 78:1022 79:601 80:1294 81:1009 82:635 83:584 84:581 85:1206 86:468 87:1027 88:543 89:1801 90:150 91:5538 92:623 93:1745 94:1925 95:1613 96:518 97:344 98:1026 99:43 100:30 101:347 103:3036 105:522 106:140 107:208 108:520 109:1856 110:945 111:1071 112:564 113:817 114:700 115:1014 116:953 117:822 118:1142 119:1288 120:372 121:740 122:1802 123:1241 124:1374 125:1390 128:643 129:223 130:309 131:669 132:360 133:160 134:268 135:72 136:239 137:242 138:342 139:190 140:211 141:329 142:533 143:382 144:512 145:98 146:527 147:401 148:662 149:351 150:147 151:552 152:414 153:189 154:27 155:414 156:267 157:394 158:278 159:744 160:350 161:452 162:498 163:225 164:583 165:507 166:252 167:596 168:1027 169:127 170:1065 171:184 172:23 173:1595 174:557 175:497 176:1129 177:2174 178:1864 179:74 180:1485 181:564 182:1273 183:419 184:668 185:696 186:2290 187:1375 188:1894 189:1286 190:6755 192:6832 193:5711 194:4713 195:3588 196:1344 197:942 198:4554 199:5364 200:6015 201:2241 202:8832 203:8886 204:4511 205:2600 206:2825 207:2874 208:4001 209:3575 210:2923 211:1523 212:2225 213:2019 214:915 215:99 216:5266 217:1610 218:615 219:313 220:1283 221:552 222:321 223:449 End of report From drc at virtualized.org Fri Jul 26 18:40:06 2013 From: drc at virtualized.org (David Conrad) Date: Fri, 26 Jul 2013 11:40:06 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> Message-ID: <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> Patrick, On Jul 26, 2013, at 8:40 AM, Patrick W. Gilmore wrote: >> Err. ICANN isn't a membership organization. It is possible to change things at ICANN, but the mechanisms are ... different and much slower (since it involves getting consensus in a multi-stakeholder environment). > > Sure it is, the membership is just very .. uh .. selective. :) > > "Stakeholder" is just a fancy way of saying "member". They vote, things change. You appear to be using a rather ... expansive definition of the word 'member'. > Like I said, this is _exactly_ what Ryan wanted. Only the "anointed" get to decide things. Works out well, doesn't it? In the sense that the ones who actively participate, scream the loudest, lobby the most, etc., get to decide things, I suppose one could say it works out. However, since anyone can actively participate, scream, lobby, etc., I'm not sure how that can be described as "only the anointed get to decide things". Regards, -drc From ncnet at sbcglobal.net Fri Jul 26 19:01:55 2013 From: ncnet at sbcglobal.net (Larry Stites) Date: Fri, 26 Jul 2013 12:01:55 -0700 (PDT) Subject: ARIN WHOIS for leads In-Reply-To: <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> Message-ID: <1374865315.91754.YahooMailNeo@web181503.mail.ne1.yahoo.com> NANOG : network operators are precisely those who directly assisted in creating the 'magic lamp' and the cork which held the marketing Jeanie inside. The same operators who took the cork out and rubbed the 'magic lamp'... The Jeanie is now out of the bottle and you all are complaining about it, all the while creating new magic, more lamps and more Jeanie's... Go figure. NANOG complaining about being harassed by the marketing technologies it has created... >________________________________ > From: David Conrad >To: Patrick W. Gilmore >Cc: NANOG list >Sent: Friday, July 26, 2013 11:40 AM >Subject: Re: ARIN WHOIS for leads > > >Patrick, > >On Jul 26, 2013, at 8:40 AM, Patrick W. Gilmore wrote: >>> Err. ICANN isn't a membership organization. It is possible to change things at ICANN, but the mechanisms are ... different and much slower (since it involves getting consensus in a multi-stakeholder environment). >> >> Sure it is, the membership is just very .. uh .. selective. :) >> >> "Stakeholder" is just a fancy way of saying "member". They vote, things change. > >You appear to be using a rather ... expansive definition of the word 'member'. > >> Like I said, this is _exactly_ what Ryan wanted. Only the "anointed" get to decide things. Works out well, doesn't it? > >In the sense that the ones who actively participate, scream the loudest, lobby the most, etc., get to decide things, I suppose one could say it works out.? However, since anyone can actively participate, scream, lobby, etc., I'm not sure how that can be described as "only the anointed get to decide things". > >Regards, >-drc > > > > > From rsk at gsp.org Fri Jul 26 19:23:06 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Jul 2013 15:23:06 -0400 Subject: ARIN WHOIS for leads In-Reply-To: References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> Message-ID: <20130726192306.GA25560@gsp.org> On Fri, Jul 26, 2013 at 10:42:18AM -0700, goemon at anime.net wrote: > Because your mail servers are broken. Because you put spamfilters on > your abuse@ mailbox, IF you even have an abuse@, which a lot of you > don't. Because we tried calling, and your tier1 are clueless. > > Fix your mailservers. Train your staff. Staff your abuse desk. Then > we'll talk. Precisely. This and the rest, which I've elided. If clueful email to "abuse at yourdomain" is not dealt with in an effective and timely manner [1] -- then you have only yourself to blame. Never build what you can't control. ---rsk [1] The only tools really needed are root passwords and wirecutters. From otis at ocosa.com Fri Jul 26 20:01:36 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 26 Jul 2013 15:01:36 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <20130726192306.GA25560@gsp.org> References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> <20130726192306.GA25560@gsp.org> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018795@ocsbs.ocosa.com> -----Original Message----- From: Rich Kulawiec [mailto:rsk at gsp.org] Sent: Friday, July 26, 2013 2:23 PM To: nanog at nanog.org Subject: Re: ARIN WHOIS for leads On Fri, Jul 26, 2013 at 10:42:18AM -0700, goemon at anime.net wrote: > Because your mail servers are broken. Because you put spamfilters on > your abuse@ mailbox, IF you even have an abuse@, which a lot of you > don't. Because we tried calling, and your tier1 are clueless. > > Fix your mailservers. Train your staff. Staff your abuse desk. Then > we'll talk. >>Precisely. This and the rest, which I've elided. If clueful email to "abuse at yourdomain" is not dealt with in an effective and timely manner [1] -- then you have only yourself to blame. To be quite honest; even if you had clueful and trained staff, folks would still blast all of your role accounts....just because history shows many providers don't answer abuse inquiries so they assume every provider is the same. For example, we reported some issues to a tier 1 couple weeks ago. Their automated abuse ticket response was basically if you want your issue handled include x,y,z and we did from the start so we were good. They issue stopped and we were happy. But what happened if we didn't include the following and didn't plan too? Well, the issue probably wouldn't have been resolved. Case and point, many abuse desks have directions that must be followed in order for a complaint to be processed efficiently and correctly. From jcurran at arin.net Fri Jul 26 21:05:57 2013 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jul 2013 21:05:57 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <679A16A0-A57C-4194-B8E3-6EE00B3A8FF5@ianai.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018792@ocsbs.ocosa.com> <2C6887E6-C0EA-4377-8579-8CBFE1835AEA@ianai.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018794@ocsbs.ocosa.com> <679A16A0-A57C-4194-B8E3-6EE00B3A8FF5@ianai.net> Message-ID: On Jul 26, 2013, at 10:04 AM, Patrick W. Gilmore wrote: > > Suggestion: Put tagged addresses and, if possible, phone numbers in your ARIN whois and other public records. When someone emails that address or calls that number, make sure you put them on a "never buy from" list, and they know it. Write them a physical (form) letter, explaining why, and make it public (web page, blog, whatever. If even a small percentage of people did this, many companies would change their practices. _Especially_ Internet companies. And please ARIN me on your letter... We do send fairly nasty letters on occasion citing the Whois terms and conditions, this is done when it is clear from complaints that parties are mining Whois or the mailing list for spamming, but we need to know it is going on. (We also do have artifacts in the database which sometimes lets us occasionally catch this on own, but most reliable are reports from folks who know the email and/or phone abused only occurs on their Whois entry.) Thanks! /John John Curran President and CEO ARIN From surfer at mauigateway.com Fri Jul 26 21:36:01 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 26 Jul 2013 14:36:01 -0700 Subject: ARIN WHOIS for leads Message-ID: <20130726143601.122FF527@m0005296.ppops.net> --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey It's called retargeting and they are using cookies to do it. ---------------------------------------------------------- So, properly manage your cookies and this will stop: Flash cookies: https://en.wikipedia.org/wiki/Local_Shared_Object firefox: http://support.mozilla.org/en-US/kb/enable-and-disable-cookies-website-preferences?redirectlocale=en-US&redirectslug=Enabling+and+disabling+cookies scott From jcurran at arin.net Fri Jul 26 21:40:58 2013 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jul 2013 21:40:58 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> Message-ID: <3914388E-43DD-44A7-BF6B-BF95E0FFD52C@corp.arin.net> On Jul 26, 2013, at 7:42 AM, "Otis L. Surratt, Jr." wrote: > >> Why can't we implement a method where you have to be a registered, and > paying, user/member with an AS number to be able to get IP whois > 'contact' info? Sure list my name and company. But keep my email and > phone number private. In fact show me >a web log of all registered > users that looked me up. > > This could be doable. But some minor details worked out or requirements. > >> I doubt that will ever happen. > > Have a little faith. ;-) If many providers wanted the feature, I'm sure > ARIN would not have a problem implementing it. ARIN will run the Whois database however you folks collectively want it run. Write up the change you seek (should be fairly easy), show rough consensus in the community for the change (slightly more difficult task), and then, (quoting patrick) "POOF!, things are changed." We know the process works; for example, it followed recently and resulted in the addition of the abuse point-of-contact. Steven notes that _voting_ requires membership, and only ISPs are members by default (not end-users/legacy holders)... This is definitely true, but you actually don't need to be a member to suggest changes to the number resource address policy or to make suggestions regarding ARIN operations. (If you do feel the urgent need to vote for AC and Board members, support ARIN's Internet Governance mission and help offset costs of ARIN's meetings, feel free to add paid "ARIN Membership" for the $500/year. Details are available here: Many end-users with IP addresses just want the registry to work, and not embedding these costs in the annual end-user fees are they are only be $100/year/resource.) Thanks! /John John Curran President and CEO ARIN From cidr-report at potaroo.net Fri Jul 26 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Jul 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201307262200.r6QM000P021554@wattle.apnic.net> This report has been generated at Fri Jul 26 21:13:25 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 19-07-13 470686 267677 20-07-13 470966 267992 21-07-13 470849 265755 22-07-13 471142 266003 23-07-13 470970 266883 24-07-13 471645 267187 25-07-13 471515 266939 26-07-13 471541 267118 AS Summary 44738 Number of ASes in routing system 18459 Number of ASes announcing only one prefix 4234 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117330144 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'). --- 26Jul13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 471601 267231 204370 43.3% All ASes AS6389 2982 69 2913 97.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2956 489 2467 83.5% NET Servi?os de Comunica??o S.A. AS17974 2618 187 2431 92.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4234 2100 2134 50.4% WINDSTREAM - Windstream Communications Inc AS4766 2908 932 1976 68.0% KIXS-AS-KR Korea Telecom AS22773 2001 228 1773 88.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2067 468 1599 77.4% COVAD - Covad Communications Co. AS10620 2639 1055 1584 60.0% Telmex Colombia S.A. AS4323 2984 1534 1450 48.6% TWTC - tw telecom holdings, inc. AS36998 1815 386 1429 78.7% SDN-MOBITEL AS7545 2040 757 1283 62.9% TPG-INTERNET-AP TPG Telecom Limited AS7303 1730 453 1277 73.8% Telecom Argentina S.A. AS18881 1247 43 1204 96.6% Global Village Telecom AS2118 1235 51 1184 95.9% RELCOM-AS OOO "NPO Relcom" AS4755 1763 584 1179 66.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1141 159 982 86.1% VIETEL-AS-AP Vietel Corporation AS22561 1207 225 982 81.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2007 1160 847 42.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1003 182 821 81.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS33363 1915 1125 790 41.3% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS4808 1173 396 777 66.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1527 807 720 47.2% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 841 139 702 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1276 575 701 54.9% Uninet S.A. de C.V. AS855 733 55 678 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1147 480 667 58.2% ITCDELTA - ITC^Deltacom AS24560 1086 436 650 59.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 747 121 626 83.8% GIGAINFRA Softbank BB Corp. AS31148 976 352 624 63.9% FREENET-AS Freenet Ltd. AS3356 1098 512 586 53.4% LEVEL3 Level 3 Communications Total 53096 16060 37036 69.8% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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. 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.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.185.0.0/20 AS36219 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 80.68.144.0/20 AS33982 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 173.45.192.0/19 AS6461 MFNX MFN - Metromedia Fiber Network 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.79.48.0/22 AS39117 194.169.237.0/24 AS12968 CDP Netia SA 195.238.120.0/22 AS33837 PRQ-AS PeRiQuito AB 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.123.17.0/24 AS27363 SWISSRE-US-AS Swiss Re America Holding Corporation 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.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.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 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.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 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 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, 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 Jul 26 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Jul 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201307262200.r6QM01Aa021568@wattle.apnic.net> BGP Update Report Interval: 18-Jul-13 -to- 25-Jul-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18403 52054 1.7% 86.9 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 2 - AS9829 41878 1.4% 27.2 -- BSNL-NIB National Internet Backbone 3 - AS10620 38236 1.2% 14.1 -- Telmex Colombia S.A. 4 - AS8402 34166 1.1% 18.8 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS27738 31782 1.0% 55.2 -- Ecuadortelecom S.A. 6 - AS28573 30482 1.0% 10.1 -- NET Servi?os de Comunica??o S.A. 7 - AS15003 24421 0.8% 28.6 -- NOBIS-TECH - Nobis Technology Group, LLC 8 - AS10428 22779 0.7% 3254.1 -- CWV-NETWORKS - The College of West Virginia 9 - AS50710 21019 0.7% 87.9 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 10 - AS17974 19021 0.6% 7.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS33770 18402 0.6% 242.1 -- KDN 12 - AS9416 17973 0.6% 345.6 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 13 - AS4775 17165 0.6% 201.9 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS14287 15121 0.5% 240.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 15 - AS8151 14566 0.5% 11.3 -- Uninet S.A. de C.V. 16 - AS52280 13218 0.4% 2203.0 -- INTERNEXA Chile S.A. 17 - AS36998 13085 0.4% 7.2 -- SDN-MOBITEL 18 - AS3356 12927 0.4% 11.7 -- LEVEL3 Level 3 Communications 19 - AS7552 12202 0.4% 10.2 -- VIETEL-AS-AP Vietel Corporation 20 - AS13188 11816 0.4% 14.1 -- BANKINFORM-AS TOV "Bank-Inform" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6174 7163 0.2% 3581.5 -- SPRINTLINK8 - Sprint 2 - AS10428 22779 0.7% 3254.1 -- CWV-NETWORKS - The College of West Virginia 3 - AS3 2567 0.1% 1508.0 -- CMED-AS Cmed Technology Ltd 4 - AS36976 2288 0.1% 2288.0 -- SONANGOL 5 - AS52280 13218 0.4% 2203.0 -- INTERNEXA Chile S.A. 6 - AS31421 1528 0.1% 1528.0 -- YUG-SVYAZ-SERVICE-AS Yug Sviaz Service Ltd 7 - AS9854 2960 0.1% 1480.0 -- KTO-AS-KR KTO 8 - AS34969 10400 0.3% 1300.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 9 - AS37367 1273 0.0% 1273.0 -- CALLKEY 10 - AS57483 868 0.0% 868.0 -- JBM-AS "J.B.M. Distribution" LLC 11 - AS53197 784 0.0% 784.0 -- Meta Telecomunica??es Ltda 12 - AS48612 10172 0.3% 726.6 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 13 - AS50099 657 0.0% 657.0 -- VKB-AS Volkskreditbank AG 14 - AS4 1299 0.0% 269.0 -- BEMAR TECNOLOGIA LTDA - ME 15 - AS37584 1142 0.0% 571.0 -- FastNetAS 16 - AS49076 508 0.0% 508.0 -- COMPASS-EOS COMPASS ELECTRO-OPTICAL SYSTEMS LTD 17 - AS3976 502 0.0% 502.0 -- ERX-NURI-ASN I.Net Technologies Inc. 18 - AS42953 492 0.0% 492.0 -- MOSCOWCAPITALBANK-AS Bank Moscowskiy Kapital Ltd. 19 - AS37577 893 0.0% 446.5 -- Airtel-BF 20 - AS2 435 0.0% 292.0 -- ABBVIEINC-AS-AP AbbVie, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 190.211.175.0/24 13607 0.4% AS28032 -- INTERNEXA S.A. AS52280 -- INTERNEXA Chile S.A. 2 - 92.246.207.0/24 9996 0.3% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 203.118.232.0/21 9025 0.2% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 203.118.224.0/21 8784 0.2% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 192.58.232.0/24 8579 0.2% AS6629 -- NOAA-AS - NOAA 6 - 222.127.0.0/24 8267 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 120.28.62.0/24 8264 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 12.43.218.0/24 7567 0.2% AS10428 -- CWV-NETWORKS - The College of West Virginia 9 - 199.248.240.0/24 7565 0.2% AS10428 -- CWV-NETWORKS - The College of West Virginia 10 - 205.166.165.0/24 7565 0.2% AS10428 -- CWV-NETWORKS - The College of West Virginia 11 - 65.90.49.0/24 7243 0.2% AS3356 -- LEVEL3 Level 3 Communications 12 - 62.84.76.0/24 6364 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 13 - 115.170.128.0/17 5045 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 14 - 69.38.178.0/24 4653 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 15 - 64.187.64.0/23 4159 0.1% AS16608 -- KENTEC - Kentec Communications, Inc. 16 - 208.16.110.0/24 3582 0.1% AS6174 -- SPRINTLINK8 - Sprint 17 - 206.105.75.0/24 3581 0.1% AS6174 -- SPRINTLINK8 - Sprint 18 - 64.187.64.0/24 3200 0.1% AS16608 -- KENTEC - Kentec Communications, Inc. 19 - 208.73.244.0/22 2967 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 20 - 208.88.232.0/21 2965 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, 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 wbailey at satelliteintelligencegroup.com Fri Jul 26 23:24:53 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 26 Jul 2013 23:24:53 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <20130726143601.122FF527@m0005296.ppops.net> References: <20130726143601.122FF527@m0005296.ppops.net> Message-ID: I'm just saying.. It happens more frequently which means it will be the next subject of legislation.. Spam (unsolicited) has been pretty well taken care of from my perspective.. I rarely see the madness I saw only 10 years ago. Someone pointed out earlier that we were bitching about the problem that we created, there is a lot of truth to that. It seems like every public communications infrastructure known to man has been a shouting/listening post to advertisers forever. Radio.. Then TV.. Then expanded tv.. Now the Internet and subsequently streaming tv. Someone else pointed out the car that drove itself and freed you to watch ads. Demolition Man (don't hate..) actually depicted the same thing.. Cruising down the road in a society who is scared of everything, eating taco bell and listening to old commercials. And you get fined for saying naughty words.. Isn't that kind of what's happening? Sent from my Mobile Device. -------- Original message -------- From: Scott Weeks Date: 07/26/2013 2:38 PM (GMT-08:00) To: nanog at nanog.org Subject: RE: ARIN WHOIS for leads --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey It's called retargeting and they are using cookies to do it. ---------------------------------------------------------- So, properly manage your cookies and this will stop: Flash cookies: https://en.wikipedia.org/wiki/Local_Shared_Object firefox: http://support.mozilla.org/en-US/kb/enable-and-disable-cookies-website-preferences?redirectlocale=en-US&redirectslug=Enabling+and+disabling+cookies scott From mysidia at gmail.com Fri Jul 26 23:34:28 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 26 Jul 2013 18:34:28 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <3914388E-43DD-44A7-BF6B-BF95E0FFD52C@corp.arin.net> References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> <3914388E-43DD-44A7-BF6B-BF95E0FFD52C@corp.arin.net> Message-ID: On 7/26/13, John Curran wrote: > ARIN will run the Whois database however you folks collectively want it run. > Write up the change you seek (should be fairly easy), show rough consensus > in the community for the change (slightly more difficult task), and then, I personally think there is too little evidence at this point of widespread abuse to merit restricting access to WHOIS. Assuming you don't consider sending DMCA-like request letters to technical or abuse contacts an abuse of WHOIS. I can see how such things might be construed as spam in high volume, for large networks that provide only IP connectivity services that aren't subject to DMCA letter provisions and don't have a policy of turning off IP transit/telco services for Trademark/Copyvio without a court order. My very strong recommendation would be: * Conduct a study on the subject of WHOIS "marketing spam" type abuse. Am I correct in suggesting, that the ARIN staff would have authority to create temporary "dummy" IP address and ASN allocations of various sizes for short periods of time, using multiple e-mail To domains, and announcing them among the new allocations, and finding some ISP to bring up some of the prefixes, for the purpose of studying, if these contacts (that could have been learned only through WHOIS) receive e-mail? I would be interested in... * Is whether there is an AS allocated, IP address allocated, ORG allocated, or just POC handle created, or BGP announcement for a certain prefix correlated with the probability that a contact is spammed? * Who did the spam come from? * What IP addresses requested WHOIS on "dummy allocations" or "dummy org" records that shouldn't have shown up on the internet, e.g. so "legitimate" WHOIS queries should be minimal? --- If someone studies that and finds there is a correlation to spam based on WHOIS listing alone, then perhaps.... there must be a solution for this.... on occasion; allocate one or two new AS numbers and a /24 on a temporary basis (6 to 12 months) solely for "spammer detection" purposes, in other words "intentional erroneous allocations" that the RIR would publish as if a real allocation. If spam is received... research into what IP addresses performed WHOIS requests for those, and publish for the world to see, every email message received, plus any followups into search-for-the-guilty to clear up the pattern of network contact abuse. In other words: for starters, assume the number of "bad actors" is small, and let the community pressure them and their peers to retaliate, before diminishing the average usefulness of WHOIS to everyone, (which restricting access to a small number of users does). > My guess is someone is using your mass whois database, looking > at the most recently issued/created AS numbers, and cold calling. > -------------------------------------------- > I'd be interested in knowing who it is, so I can be sure to > never buy from them. > > scott -- -JH From jcurran at arin.net Fri Jul 26 23:43:50 2013 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jul 2013 23:43:50 +0000 Subject: ARIN WHOIS for leads In-Reply-To: References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> <3914388E-43DD-44A7-BF6B-BF95E0FFD52C@corp.arin.net> Message-ID: <640AF583-224C-4E71-B402-387CDC237079@arin.net> On Jul 26, 2013, at 4:34 PM, Jimmy Hess wrote: > If someone studies that and finds there is a correlation to spam based > on WHOIS listing alone, > then perhaps.... No study has been conducted, but we do receive a small number of complaints each year about email contact information being solicited in cases were the email address is exclusively used on IP address blocks and nowhere else. (Often, the culprits are network equipment vendors or technical recruiters) When we receive such, we send a nasty letter indicating violation of the Whois terms of use. Most companies seem to pay attention to this, but then again, it's generally been a misguided individual at an otherwise legitimate enterprise causing the problem, as opposed to typical bulk email harvesting operation. > In other words: for starters, assume the number of "bad actors" is > small, and let the community pressure them and their peers to > retaliate, before diminishing the average usefulness of WHOIS > to everyone, (which restricting access to a small number of users > does). I believe we can arrange to publicly post our notices of violation; let me look into this option. Thanks! /John John Curran President and CEO ARIN From lists at beatmixed.com Sat Jul 27 01:02:31 2013 From: lists at beatmixed.com (Matt Hite) Date: Fri, 26 Jul 2013 18:02:31 -0700 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: I actually think it's important to have contact information publicly available. I realize this opens the door for abuse, but I've found that using a call screening service (Google Voice) at least provides a bit of shield. On Thu, Jul 25, 2013 at 4:02 PM, Justin Vocke wrote: > Sent this little e-mail to ARIN: > > I'm not sure that you guys can do anything about this, but it's worth > looking into. I registered AS626XX a week ago, and since it's registration, > I've been getting calls from "wholesale" carriers trying to get me to > purchase IP transit from them. Someone is obviously using your database of > contact information to generate sales leads. > > 512-377-6827 was one of the numbers trying to get more information about > my > network and how they could "help" me. > > My guess is someone is using your mass whois database, looking at the most > recently issued/created AS numbers, and cold calling. > > Just thought I'd pass this along. > --------- > > Due to the amount of calls I've received, I'm guessing its probably a good > idea to remove my contact info from the registration and setup role's > instead. > > Does this sorta thing happen frequently with new registrations or did I > just draw the short straw? > > Best, > Justin > From jlewis at lewis.org Sat Jul 27 01:13:04 2013 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 26 Jul 2013 21:13:04 -0400 (EDT) Subject: ARIN WHOIS for leads In-Reply-To: <1374865315.91754.YahooMailNeo@web181503.mail.ne1.yahoo.com> References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> <1374865315.91754.YahooMailNeo@web181503.mail.ne1.yahoo.com> Message-ID: On Fri, 26 Jul 2013, Larry Stites wrote: > NANOG : network operators are precisely those who directly assisted in > creating the 'magic lamp' and the cork which held the marketing Jeanie > inside. The same operators who took the cork out and rubbed the 'magic > lamp'... The Jeanie is now out of the bottle and you all are complaining > about it, all the while creating new magic, more lamps and more > Jeanie's... Go figure. NANOG complaining about being harassed by the > marketing technologies it has created... We're also the people at the controls, and the people holding the wire cutters (physical and virtual), so we're not a good demographic to piss off. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From wbailey at satelliteintelligencegroup.com Sat Jul 27 01:18:30 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 27 Jul 2013 01:18:30 +0000 Subject: ARIN WHOIS for leads In-Reply-To: References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> <1374865315.91754.YahooMailNeo@web181503.mail.ne1.yahoo.com>, Message-ID: Said the Network Engineer of The City of San Francisco.. Sent from my Mobile Device. -------- Original message -------- From: Jon Lewis Date: 07/26/2013 6:17 PM (GMT-08:00) To: Larry Stites Cc: NANOG list Subject: Re: ARIN WHOIS for leads On Fri, 26 Jul 2013, Larry Stites wrote: > NANOG : network operators are precisely those who directly assisted in > creating the 'magic lamp' and the cork which held the marketing Jeanie > inside. The same operators who took the cork out and rubbed the 'magic > lamp'... The Jeanie is now out of the bottle and you all are complaining > about it, all the while creating new magic, more lamps and more > Jeanie's... Go figure. NANOG complaining about being harassed by the > marketing technologies it has created... We're also the people at the controls, and the people holding the wire cutters (physical and virtual), so we're not a good demographic to piss off. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mysidia at gmail.com Sat Jul 27 01:18:52 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 26 Jul 2013 20:18:52 -0500 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: On 7/26/13, Matt Hite wrote: > I actually think it's important to have contact information publicly > available. I realize this opens the door for abuse, but I've found that > using a call screening service (Google Voice) at least provides a bit of > shield. Hm.. a thought does occur, that /some/ operators might be inclined to offer more useful contact listings than they would otherwise do; if there were an option to list some additional details under an "enhanced" private WHOIS, as a side-by-side enhancement to the public version; that is a WHOIS that when the asker is authenticated with an implied promise that only vetted individuals with a proven network engineering experience background can see the 'additional' information, that allows them to review the query history for their record, and possibly post a "parameterized" contact URL whose use would be linked to the query. Some operators might be comfortable listing something other than their generic support phone#, or e-mail address that is so filtered, the critical message will probably not get to the right contact, for at least days or weeks. -- -JH From MGauvin at dryden.ca Sat Jul 27 01:18:45 2013 From: MGauvin at dryden.ca (Mark Gauvin) Date: Fri, 26 Jul 2013 20:18:45 -0500 Subject: ARIN WHOIS for leads In-Reply-To: References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> <1374865315.91754.YahooMailNeo@web181503.mail.ne1.yahoo.com> Message-ID: <06CFFB9A-EBBA-428E-ADC5-040EB9A49C5D@dryden.ca> Lol yet we can't use the side cutters cause we all report to the corporate overlords Sent from my iPhone On 2013-07-26, at 8:18 PM, "Jon Lewis" wrote: > On Fri, 26 Jul 2013, Larry Stites wrote: > >> NANOG : network operators are precisely those who directly assisted in >> creating the 'magic lamp' and the cork which held the marketing Jeanie >> inside. The same operators who took the cork out and rubbed the 'magic >> lamp'... The Jeanie is now out of the bottle and you all are complaining >> about it, all the while creating new magic, more lamps and more >> Jeanie's... Go figure. NANOG complaining about being harassed by the >> marketing technologies it has created... > > We're also the people at the controls, and the people holding the wire > cutters (physical and virtual), so we're not a good demographic to piss > off. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From mysidia at gmail.com Sat Jul 27 01:36:59 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 26 Jul 2013 20:36:59 -0500 Subject: ARIN WHOIS for leads In-Reply-To: References: <51F27A89.4080704@nac.net> <972EBB98-A4B3-47BC-957E-18D0F17134F2@ianai.net> <55F15309-CA40-46A2-9D14-66757DEBC903@virtualized.org> <8450E437-4F62-4AA9-BEA5-9A968A46A085@ianai.net> <66C5D0E1-C273-4E06-8350-A0080338A362@virtualized.org> <1374865315.91754.YahooMailNeo@web181503.mail.ne1.yahoo.com> Message-ID: On 7/26/13, Warren Bailey wrote: > Said the Network Engineer of The City of San Francisco.. Hey, noone said the operators at the controls don't have to give the keys up if their owners demand it -- the owners just can't drive. If you collectively piss off the guild of taxi drivers, in a world with no other cars; that doesn't mean they have a right to run you over on the street, but good luck hailing a cab while your face is on the collective list of "people not to stop for". Likewise... if you're in the network device or transit provider service; taking the risk of angering your very potential customer base by failing to keep the reigns on your marketing department / making sure they don't spam or risk conducting other faux pas that could eventually be brand-destroying faux pas is not a great idea :) > Sent from my Mobile Device. -- -JH From paradox at nac.net Sat Jul 27 05:34:42 2013 From: paradox at nac.net (Ryan Pavely) Date: Sat, 27 Jul 2013 01:34:42 -0400 Subject: ARIN WHOIS for leads In-Reply-To: References: Message-ID: <51F35BF2.7030802@nac.net> > Because your mail servers are broken. Because you put spamfilters on > your abuse@ mailbox, IF you even have an abuse@, which a lot of you > don't. Because we tried calling, and your tier1 are clueless. > > Fix your mailservers. Train your staff. Staff your abuse desk. Then > we'll talk. My mail servers are just fine. My abuse department is standing by to serve your requests. They are listed on all domains, ip allocations, and abuse.org, etc, etc.. If you suggest folks attempt to reach an abuse contact, fail, and them spam. Ok. No problem. But starting out with receiving an email that is CC'd to 3 departments, 2 direct people, and the same for all other org's involved is offensive, abusive, etc. And if you suggest for a second someone attempted to call, and gave up, and then spammed; yeah that never happened. A phone call? Really? Maybe one a decade, versus many spammed-spam complaints a day. > Someone else wrote and I seem to have deleted it.. but basically 'I > don't think these occurrences happen that often to warrant a change.' Well. If it's not happening that often, then lets fix it now before it does :) > I actually think it's important to have contact information publicly > available. > Why? Who outside 'the business' needs that level of detailed contact information to IP mgmt folks? Does an end-user need that access? No. Does a web hoster need that access? No. They can go through their ISP or contact my OPS contact. Do you need that access? Do you have an AS, and IP blocks? If so then sure, why not. Now there is a big bug in locking down access to those registered members. Registered with whom? Arin? Ok so how do my brit friends whois my IP contact info? That complicates things, beyond suggesting an Arin policy. So I don't ever see this as changing, as I think I said, but it should change. Just like we shouldn't have echo/chargen anymore. They were cool 'back in the day'. Ryan Pavely Net Access Corporation http://www.nac.net/ On 7/26/2013 9:02 PM, Matt Hite wrote: From me at staticsafe.ca Sat Jul 27 10:27:59 2013 From: me at staticsafe.ca (staticsafe) Date: Sat, 27 Jul 2013 06:27:59 -0400 Subject: [security-officer@isc.org: Notice: BIND Security Jul2013 CVE2013-4854] Message-ID: <20130727102758.GB23736@uriel.asininetech.com> ----- Forwarded message from ISC Security Officer ----- Date: Fri, 26 Jul 2013 13:46:50 -0700 From: ISC Security Officer To: bind-announce at lists.isc.org, bind-workers at lists.isc.org, bind-users at lists.isc.org Subject: Notice: BIND Security Jul2013 CVE2013-4854 IMPORTANT: The security issue described below has been confirmed by ISC to be 'in the wild' as of 18:00UTC July 26, and exploitation of this vulnerability against production servers has been reported by multiple organizations. Please be advised that immediate action is recommended. A specially crafted query can cause BIND to terminate CVE: CVE-2013-4854 Document Version: 2.0 Posting date: 26 July 2013 Program Impacted: BIND Versions affected: Open source: 9.7.0->9.7.7, 9.8.0->9.8.5-P1, 9.9.0->9.9.3-P1, 9.8.6b1 and 9.9.4b1; Subscription: 9.9.3-S1 and 9.9.4-S1b1 Severity: Critical Exploitable: Remotely Description: A specially crafted query that includes malformed rdata can cause named to terminate with an assertion failure while rejecting the malformed query. BIND 9.6 and BIND 9.6-ESV are unaffected by this problem. Earlier branches of BIND 9 are believed to be unaffected but have not been tested. BIND 10 is also unaffected by this issue. Please Note: All versions of BIND 9.7 are known to be affected, but these branches are beyond their "end of life" (EOL) and no longer receive testing or security fixes from ISC. For current information on which versions are actively supported, please see http://www.isc.org/downloads/software-support-policy/bind-software-status/. Impact: Authoritative and recursive servers are equally vulnerable. Intentional exploitation of this condition can cause a denial of service in all nameservers running affected versions of BIND 9. Access Control Lists do not provide any protection from malicious clients. In addition to the named server, applications built using libraries from the affected source distributions may crash with assertion failures triggered in the same fashion. CVSS Score: 7.8 CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C) Workarounds: No known workarounds at this time. Active exploits: Crashes have been reported by multiple ISC customers. First observed in the wild on 26 July 2013, 18:00 UTC. Solution: Upgrade to the patched release most closely related to your current version of BIND. Open source versions can all be downloaded from http://www.isc.org/downloads. Subscription version customers will be contacted directly by ISC Support regarding delivery. BIND 9 version 9.8.5-P2 BIND 9 version 9.9.3-P2 BIND 9 version 9.9.3-S1-P1 (Subscription version available via DNSco) Acknowledgements: ISC would like to thank Maxim Shudrak and the HP Zero Day Initiative for reporting this issue. Document Revision History: 1.0 Phase One Advance Notification, 18 July 2013 1.1 Phases Two and Three Advance Notification, 26 July 2013 2.0 Notification to public (Phase Four), 26 July 2013 Related Documents: Spanish Translation: planned Japanese Translation: https://kb.isc.org/article/AA-01023 Portuguese Translation: https://kb.isc.org/article/AA-01021 See our BIND Security Matrix for a complete listing of Security Vulnerabilities and versions affected. This Knowledge Base article https://kb.isc.org/article/AA-01016 provides additional information and Frequently Asked Questions about this advisory. If you'd like more information on our product support or about our Subscription versions of BIND, please visit http://www.dns-co.com/solutions Do you still have questions? Questions regarding this advisory should go to security-officer at isc.org. To report a new issue, please encrypt your message using security-officer at isc.org's PGP key which can be found here: https://www.isc.org/downloads/software-support-policy/openpgp-key If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/mission/contact/. Note: ISC patches only currently supported versions. When possible we indicate EOL versions affected. ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: ISC Software Defect and Security Vulnerability Disclosure Policy This Knowledge Base article https://kb.isc.org/article/AA-01015 is the complete and official security advisory document. Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. (c) 2001-2013 Internet Systems Consortium _______________________________________________ bind-announce mailing list bind-announce at lists.isc.org https://lists.isc.org/mailman/listinfo/bind-announce ----- End forwarded message ----- -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. Please don't CC! I'm subscribed to whatever list I just posted on. From frnkblk at iname.com Sat Jul 27 19:59:07 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Jul 2013 14:59:07 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <51F35BF2.7030802@nac.net> References: <51F35BF2.7030802@nac.net> Message-ID: <00ee01ce8b03$c0aeffa0$420cfee0$@iname.com> For the folks who aren't aware, there is working being done on a proposal for a complete do-over of WHOIS: http://www.circleid.com/posts/20130703_rebooting_whois/ I don't believe this work address the regional registry information, which is what initiated the discussion, but this conversation has crossed over into the domain names, too. Frank -----Original Message----- From: Ryan Pavely [mailto:paradox at nac.net] Sent: Saturday, July 27, 2013 12:35 AM To: nanog at nanog.org Subject: Re: ARIN WHOIS for leads > Because your mail servers are broken. Because you put spamfilters on > your abuse@ mailbox, IF you even have an abuse@, which a lot of you > don't. Because we tried calling, and your tier1 are clueless. > > Fix your mailservers. Train your staff. Staff your abuse desk. Then > we'll talk. My mail servers are just fine. My abuse department is standing by to serve your requests. They are listed on all domains, ip allocations, and abuse.org, etc, etc.. If you suggest folks attempt to reach an abuse contact, fail, and them spam. Ok. No problem. But starting out with receiving an email that is CC'd to 3 departments, 2 direct people, and the same for all other org's involved is offensive, abusive, etc. And if you suggest for a second someone attempted to call, and gave up, and then spammed; yeah that never happened. A phone call? Really? Maybe one a decade, versus many spammed-spam complaints a day. > Someone else wrote and I seem to have deleted it.. but basically 'I > don't think these occurrences happen that often to warrant a change.' Well. If it's not happening that often, then lets fix it now before it does :) > I actually think it's important to have contact information publicly > available. > Why? Who outside 'the business' needs that level of detailed contact information to IP mgmt folks? Does an end-user need that access? No. Does a web hoster need that access? No. They can go through their ISP or contact my OPS contact. Do you need that access? Do you have an AS, and IP blocks? If so then sure, why not. Now there is a big bug in locking down access to those registered members. Registered with whom? Arin? Ok so how do my brit friends whois my IP contact info? That complicates things, beyond suggesting an Arin policy. So I don't ever see this as changing, as I think I said, but it should change. Just like we shouldn't have echo/chargen anymore. They were cool 'back in the day'. Ryan Pavely Net Access Corporation http://www.nac.net/ On 7/26/2013 9:02 PM, Matt Hite wrote: From jcurran at arin.net Sat Jul 27 22:11:57 2013 From: jcurran at arin.net (John Curran) Date: Sat, 27 Jul 2013 22:11:57 +0000 Subject: DNS Whois Requirements (was: Re: ARIN WHOIS for leads) In-Reply-To: <00ee01ce8b03$c0aeffa0$420cfee0$@iname.com> References: <51F35BF2.7030802@nac.net> <00ee01ce8b03$c0aeffa0$420cfee0$@iname.com> Message-ID: On Jul 27, 2013, at 12:59 PM, Frank Bulk wrote: > For the folks who aren't aware, there is working being done on a proposal > for a complete do-over of WHOIS: > http://www.circleid.com/posts/20130703_rebooting_whois/ > I don't believe this work address the regional registry information, which > is what initiated the discussion, but this conversation has crossed over > into the domain names, too. Excellent pointer Frank... This effort at ICANN is specifically with respect to requirements for DNS Whois, but it is possible that some of these requirements are in common with those of the number resource Whois directory service, and the Internet address community may be encouraged at some point to give a similar level of consideration to the long-term number resource Whois requirements, including the DNS result as one of many inputs to that process. Note that the comment period on the DNS Whois recommendations remains open till 12 August 2013, and parties that have views on this matter should make them known to the DNS directory services expert working group which is drafting the recommendations. FYI (and Thanks)! /John John Curran President and CEO ARIN From rob at invaluement.com Sat Jul 27 23:20:21 2013 From: rob at invaluement.com (Rob McEwen) Date: Sat, 27 Jul 2013 19:20:21 -0400 Subject: DNS Whois Requirements In-Reply-To: References: <51F35BF2.7030802@nac.net> <00ee01ce8b03$c0aeffa0$420cfee0$@iname.com> Message-ID: <51F455B5.8090507@invaluement.com> On 7/27/2013 6:11 PM, John Curran wrote: > Excellent pointer Frank... I confess, I haven't followed this conversation very closely (which meandered around much, given the random few messages I saw.. who has the time to read them all?). So forgive me if I'm repeating some of the info already covered. But I think you all would be very interested in some of my experiences this past year! To ARIN's credit, they revamped their requirements for data access just this past year. They cut off all access, then made members resend in new Bulk Whois agreements to keep their access turned on. So ARIN is obviously doing some GOOD things to try to prevent their data from being used by marketers! I think our usage of that data might be one of the most credible situations in existence. I manage an anti-spam blacklist which is used by hundreds of organizations across the world, including multiple Fortune 500 technology companies and even a few notable ISPs. One of our three blacklists preemptively blocks /24 blocks if/when we see a pattern where a snowshoe spammer is burning through the IPs on that block one at a time... we then blacklist that /24 block (well... sort of...). But our ivmSIP/24 list is no ordinary /24 list. We OFTEN set up boundaries if/when we detect either (a) any other IP(s) on that block that we deem as legit, and/or (b) a situation where portions of the same /24 block are delegated to DIFFERENT organizations. In those cases, we only blacklist the subsection of the /24 block belonging to the spammers, making ivmSIP/24 a much safer list for outright blocking or high scoring... in comparison to what can be accomplished with other /24 anti-spam blacklists. Having ARIN data is an invaluable tool that helps ivmSIP/24 do a better job of only blacklisting the spammers, while leaving the innocent bystandards untouched, in situations where the /24 block is shared by spammers and non-spammers. I know it is frustrating that marketers somehow continue to game the system... but I hope that this never causes the legit uses of that data, such as what we're doing... to be discontinued. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From rob at invaluement.com Sat Jul 27 23:28:55 2013 From: rob at invaluement.com (Rob McEwen) Date: Sat, 27 Jul 2013 19:28:55 -0400 Subject: DNS Whois Requirements In-Reply-To: <51F455B5.8090507@invaluement.com> References: <51F35BF2.7030802@nac.net> <00ee01ce8b03$c0aeffa0$420cfee0$@iname.com> <51F455B5.8090507@invaluement.com> Message-ID: <51F457B7.2050604@invaluement.com> On 7/27/2013 7:20 PM, Rob McEwen wrote: > They cut off all access Correction... that didn't come across the right way. They didn't just cut everyone's access off. What I meant was that anyone who didn't re-signup by filling out a rather comprehensive form, with very pointed questions about their usage, were cut off. But PLENTY of warning was given. I actually got lazy and didn't get the form in on time... so my access was cut off for a period of time. But that was my own fault. (and showed that they were serious about this!) -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From brunner at nic-naa.net Sat Jul 27 23:34:23 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 27 Jul 2013 16:34:23 -0700 Subject: DNS Whois Requirements In-Reply-To: References: <51F35BF2.7030802@nac.net> <00ee01ce8b03$c0aeffa0$420cfee0$@iname.com> Message-ID: <51F458FF.1090701@nic-naa.net> > On Jul 27, 2013, at 12:59 PM, Frank Bulk wrote: > >> For the folks who aren't aware, there is working being done on a proposal >> for a complete do-over of WHOIS: >> http://www.circleid.com/posts/20130703_rebooting_whois/ >> I don't believe this work address the regional registry information, which >> is what initiated the discussion, but this conversation has crossed over >> into the domain names, too. > > Excellent pointer Frank... This effort at ICANN is specifically with > respect to requirements for DNS Whois, but it is possible that some of > these requirements are in common with those of the number resource Whois > directory service, and the Internet address community may be encouraged > at some point to give a similar level of consideration to the long-term > number resource Whois requirements, including the DNS result as one of > many inputs to that process. Er ... Um ... Well ... there is weirds, and you're free to browse the list archives which are in the usual location: https://www.ietf.org/mailman/listinfo/weirds Then there is the somewhat ... incompletely specified ... project that may, or may not be lead by Chris Gift, which may, or may not, lead to actual bits being replicated across the contracted domain registries. Eric From mpetach at netflight.com Sun Jul 28 02:10:14 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 27 Jul 2013 19:10:14 -0700 Subject: Office 365..? how Microsoft handed the NSA access to encrypted messages In-Reply-To: <51E30DE6.5010402@wholesaleinternet.net> References: <-7573758388908123780@unknownmsgid> <616B4ECE1290D441AD56124FEBB03D0817147AB24C@mailserver2007.nyigc.globe> <340FBE63-CBBA-45C6-8C1F-DB671458039C@gmail.com> <1abe3wcyrvpu1ab38qmxqd7e.1373674350184@email.android.com> <356729289-1373687421-cardhu_decombobulator_blackberry.rim.net-1729297104-@b3.c8.bise6.blackberry> <-4184666514164210262@unknownmsgid> <1373834247.2182.4.camel@Andromeda> <51E30DE6.5010402@wholesaleinternet.net> Message-ID: On Sun, Jul 14, 2013 at 1:45 PM, Aaron Wendel wrote: > On 7/14/2013 3:37 PM, Richard Golodner wrote: > >> On Sun, 2013-07-14 at 09:36 -1000, Randy Bush wrote: >> >>> in >>> fact, they were all likely in the same rotten boat. >>> >> >> Why I love open source. Look at my mail, track my web site >> visits. None >> of this should come as any surprise, especially to the members of this >> list. Now for the guy down the street that is working on his 69 Camaro >> at two in the morning it may have come as a shock. >> Richard >> >> >> > We (ISPs) are all compelled to provide information from time to time under > a court order. The PRISM program is voluntary. These companies gave the > NSA access to their systems voluntarily. To me there is a big difference. > I would be interested to know what they got out of it. > > It was far from voluntary, and it apparently didn't happen without a lot of resistance. At least some details of the long, hard fight that started five years ago are finally being allowed to be declassified now: http://money.cnn.com/2013/07/16/technology/security/yahoo-fisa-court/index.html http://mashable.com/2013/07/16/yahoo-fisa-court-2008-prism/ It will be interesting to see how much of the court documents will be visible and unredacted when they are released on Monday. Matt From Valdis.Kletnieks at vt.edu Sun Jul 28 02:57:12 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 27 Jul 2013 22:57:12 -0400 Subject: ARIN WHOIS for leads In-Reply-To: Your message of "Fri, 26 Jul 2013 20:18:52 -0500." References: Message-ID: <64151.1374980232@turing-police.cc.vt.edu> On Fri, 26 Jul 2013 20:18:52 -0500, Jimmy Hess said: > authenticated with an implied promise that only vetted > individuals with a proven network engineering experience > background can see the 'additional' information, I have to admit that this is the biggest can-o-worms suggestion I've seen all week. (Hint: our org chart says I work in our Network Storage and Backup group - the lurker in the next cubicle does our abuse@ handling but you've probably never heard of him. Have fun unsnarling that sort of issue for 20K ASN's. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mysidia at gmail.com Sun Jul 28 04:00:34 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 27 Jul 2013 23:00:34 -0500 Subject: ARIN WHOIS for leads In-Reply-To: <64151.1374980232@turing-police.cc.vt.edu> References: <64151.1374980232@turing-police.cc.vt.edu> Message-ID: On 7/27/13, Valdis.Kletnieks at vt.edu wrote: > On Fri, 26 Jul 2013 20:18:52 -0500, Jimmy Hess said: > I have to admit that this is the biggest can-o-worms suggestion > I've seen all week. > (Hint: our org chart says I work in our Network Storage and Backup > group - the lurker in the next cubicle does our abuse@ handling but My implication was not that ORG charts or person's actual job should be looked at. By vetted; I meant the person was subject to a background check, and also proved that they have technical knowledge. That's about "reducing noise" by providing contacts that can only be accessed by people who proved they knew well enough what they were doing, to avoid submitting "false outage reports"; for example, so they wouldn't be the people complaining to the hosting provider's IP technical contact about some random customer web server spitting out 404 pages.. In other words --- they would have passed a knowledge proof, showing they deserve the right to bypass "Level 1 call center drones". E.g. to gain enhanced access in a world with 'an additional level of whois access' Step 1... 1. Submit an application with a nominal fee, explain to the RIR your periodic use of WHOIS, and how you would benefit from seeing 'special contacts' data; also including signed NDA regarding 'enhanced' extra contact information. 2. Pay ongoing fees for criminal/spammer background checks, with results forwarded to the RIR. 3. Show up at a RIR meeting, and sign the guest list -- or otherwise, get other members of the community to vouch for your character and technical capability, or, as an alternative show technical credentials in the form of an earned professional level networking industry certification requiring a performance-based lab assessment with advanced network troubleshooting of Layer 1 through 4 on real equipment. Those were some examples. I didn't mean to imply "Ask to see companies' org charts, try to untangle the mess for every AS, and examine job descriptions" -- -JH From jcurran at arin.net Sun Jul 28 04:34:18 2013 From: jcurran at arin.net (John Curran) Date: Sun, 28 Jul 2013 04:34:18 +0000 Subject: ARIN WHOIS for leads In-Reply-To: References: <64151.1374980232@turing-police.cc.vt.edu> Message-ID: On Jul 27, 2013, at 9:00 PM, Jimmy Hess wrote: > ... > In other words --- they would have passed a knowledge proof, showing > they deserve the right to bypass "Level 1 call center drones". > > E.g. to gain enhanced access in a world with 'an additional level of > whois access' > Step 1... > 1. Submit an application with a nominal fee, explain to the RIR > your periodic use of WHOIS, and how you would benefit from seeing > 'special contacts' data; also including signed NDA regarding > 'enhanced' extra contact information. > > 2. Pay ongoing fees for criminal/spammer background checks, with > results forwarded to the RIR. > > 3. Show up at a RIR meeting, and sign the guest list -- or > otherwise, get other members of the community to vouch for your > character and technical capability, or, as an alternative show > technical credentials in the form of an earned professional level > networking industry certification requiring a performance-based lab > assessment with advanced network troubleshooting of Layer 1 through 4 > on real equipment. > > Those were some examples. Jimmy - If I understand you correctly, you are seeking establishment of a database of private operator contact data; this data would only made available to those who are "provably known" (using some process TBD), who furthermore agree to its terms of use, and potentially pay some nominal fee to offset its cost. Based on my (admittedly dated) knowledge of service provider operations, I can see how access to this "enhanced" data might be a useful service, although I'm not certain that it being based on "Whois" or the existing registry data is necessarily required for the service to be useful. Also, while ARIN's purpose and mission could be said to include such services, it's good to note that any organization whose purposes include "areas in which inter-provider cooperation can be mutually beneficial" would be also be a suitable home for such an activity... FYI, /John John Curran President and CEO ARIN p.s. If in the end you feel strongly that _ARIN_ should be offering such a service, please submit into the ARIN Consultation and Suggestion Process.. (which doesn't mean it will happen, only that we'll spec it out and then put it in front of the community for consideration.) From mpetach at netflight.com Sun Jul 28 07:46:35 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 28 Jul 2013 00:46:35 -0700 Subject: ARIN WHOIS for leads In-Reply-To: References: <64151.1374980232@turing-police.cc.vt.edu> Message-ID: On Sat, Jul 27, 2013 at 9:00 PM, Jimmy Hess wrote: > On 7/27/13, Valdis.Kletnieks at vt.edu wrote: > > On Fri, 26 Jul 2013 20:18:52 -0500, Jimmy Hess said: > > I have to admit that this is the biggest can-o-worms suggestion > I've > seen all week. > > (Hint: our org chart says I work in our Network Storage and Backup > > group - the lurker in the next cubicle does our abuse@ handling but > > My implication was not that ORG charts or person's actual job should > be looked at. By vetted; I meant the person was subject to a > background check, and also proved that they have technical knowledge. > > That's about "reducing noise" by providing contacts that can only be > accessed by people who proved they knew well enough what they were > doing, to avoid submitting "false outage reports"; for example, > so they wouldn't be the people complaining to the hosting > provider's IP technical contact about some random customer web > server spitting out 404 pages.. > > In other words --- they would have passed a knowledge proof, showing > they deserve the right to bypass "Level 1 call center drones". > > > E.g. to gain enhanced access in a world with 'an additional level of > whois access' > Step 1... > 1. Submit an application with a nominal fee, explain to the RIR > your periodic use of WHOIS, and how you would benefit from seeing > 'special contacts' data; also including signed NDA regarding > 'enhanced' extra contact information. > > 2. Pay ongoing fees for criminal/spammer background checks, with > results forwarded to the RIR. > > 3. Show up at a RIR meeting, and sign the guest list -- or > otherwise, get other members of the community to vouch for your > character and technical capability, or, as an alternative show > technical credentials in the form of an earned professional level > networking industry certification requiring a performance-based lab > assessment with advanced network troubleshooting of Layer 1 through 4 > on real equipment. > If you're going to *that* level of validation, just join INOC-DBA and be done with it: http://en.wikipedia.org/wiki/INOC-DBA Matt > Those were some examples. > > I didn't mean to imply "Ask to see companies' org charts, try to > untangle the mess for every AS, and examine job descriptions" > > > -- > -JH > > From yazan.jaber at newroztelecom.com Sun Jul 28 07:38:30 2013 From: yazan.jaber at newroztelecom.com (Yazan Jaber) Date: Sun, 28 Jul 2013 10:38:30 +0300 Subject: S Vlan and C VLAN Message-ID: <93605C386857774184E71C2D97E3A38C08E39BFB4DEC@ZNKO-EXM-VR.newroztelecom.com> Hi all, This is my first email to this great group, I want to as if anybody can help me in designing of the network in terms of S vlan and C vlan, what is differences and what is recommended for what and any useful data. Thanks, ________________________________ The content of this email together with any attachments, statements and opinions expressed herein contains information that is private and confidential, are intended for the named addressee/s only. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this message in error, please notify the sender by a reply email immediately and delete the message without making any copies. From drew.linsalata at gmail.com Sun Jul 28 14:16:09 2013 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Sun, 28 Jul 2013 10:16:09 -0400 Subject: Anyone from 6128 listening? Message-ID: Sorry to use the list for this, but we're batting our heads against the wall trying to resolve an intermittent routing issue between OOL cable modem users and AWS. The usual channels are getting us nowhere beyond "reboot your modem and your router". From j at arpa.com Sun Jul 28 14:20:58 2013 From: j at arpa.com (jamie rishaw) Date: Sun, 28 Jul 2013 09:20:58 -0500 Subject: Super Space Self Storage : At The Heart of what was to become the epicenter of Silicon Valley. Message-ID: http://www.theatlantic.com/technology/archive/13/07/not-even-silicon-valley-escapes-history/277824/ -j -- jamie rishaw // .com.arpa at j <- reverse it. ish. *"Reality defeats prejudice."* - *Rep. Barney Frank* From mike at mtcc.com Sun Jul 28 17:37:43 2013 From: mike at mtcc.com (Michael Thomas) Date: Sun, 28 Jul 2013 10:37:43 -0700 Subject: Super Space Self Storage : At The Heart of what was to become the epicenter of Silicon Valley. In-Reply-To: References: Message-ID: <51F556E7.9080602@mtcc.com> On 07/28/2013 07:20 AM, jamie rishaw wrote: > http://www.theatlantic.com/technology/archive/13/07/not-even-silicon-valley-escapes-history/277824/ > > > -j Yeah, that's a fun article. My guess in 20 years the current boom in SF will revert to the wildtype and instead of the Twitter on midmarket the Tenderloin will be as it always was, and skinny jeans will no longer fit. Mike From jmamodio at gmail.com Sun Jul 28 22:36:03 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 28 Jul 2013 17:36:03 -0500 Subject: S Vlan and C VLAN In-Reply-To: <93605C386857774184E71C2D97E3A38C08E39BFB4DEC@ZNKO-EXM-VR.newroztelecom.com> References: <93605C386857774184E71C2D97E3A38C08E39BFB4DEC@ZNKO-EXM-VR.newroztelecom.com> Message-ID: <61696606-8D97-4A48-B658-E3EC0F666BD8@gmail.com> Wrong list to ask that question. After you have a network you can share your experiences and discuss how to operate it. The "O" in NANOG stands for Operators. BTW your email was marked as confidential so this response does not exists Cheers -Jorge On Jul 28, 2013, at 2:38 AM, Yazan Jaber wrote: > Hi all, > > This is my first email to this great group, I want to as if anybody can help me in designing of the network in terms of S vlan and C vlan, what is differences and what is recommended for what and any useful data. > > Thanks, > > ________________________________ > The content of this email together with any attachments, statements and opinions expressed herein contains information that is private and confidential, are intended for the named addressee/s only. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this message in error, please notify the sender by a reply email immediately and delete the message without making any copies. From mysidia at gmail.com Sun Jul 28 23:26:30 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 28 Jul 2013 18:26:30 -0500 Subject: S Vlan and C VLAN In-Reply-To: <93605C386857774184E71C2D97E3A38C08E39BFB4DEC@ZNKO-EXM-VR.newroztelecom.com> References: <93605C386857774184E71C2D97E3A38C08E39BFB4DEC@ZNKO-EXM-VR.newroztelecom.com> Message-ID: On 7/28/13, Yazan Jaber wrote: "S-TAG" and "C-TAG" are used exclusively for networks that need double VLAN tagging, where S belongs to the provider and C belongs to the customer. Please see IEEE 802.1ad standard, and your network vendor's documentation regarding their implementation of the standard. http://www.ieee802.org/1/pages/802.1ad.html I think it is possible I might have received this message in error. Please note that permanent archival copies are made of all email I receive on write-once media, and these cannot be deleted. Also, all items received to this folder may be included in a public disclosure at any time, and the burden rests with the sender to not send any attachments, statements, or opinions containing information that is private or confidential, because once received it is physically impossible to remove or filter messages from the archive. Regards, > Hi all, > > This is my first email to this great group, I want to as if anybody can help > me in designing of the network in terms of S vlan and C vlan, what is > differences and what is recommended for what and any useful data. > > Thanks, > > ________________________________ > The content of this email together with any attachments, statements and > opinions expressed herein contains information that is private and > confidential, are intended for the named addressee/s only. If you are not > the addressee of this email you may not copy, forward, disclose or otherwise > use it or any part of it in any form whatsoever. If you have received this > message in error, please notify the sender by a reply email immediately and > delete the message without making any copies. > -- -JH From cgrundemann at gmail.com Mon Jul 29 06:04:44 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 29 Jul 2013 00:04:44 -0600 Subject: Looking for clue at Yourwebhoster.eu Message-ID: I could use someone with some clue from Yourwebhoster.eu to contact me off list please. Thanks, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From j at arpa.com Mon Jul 29 12:24:15 2013 From: j at arpa.com (jamie rishaw) Date: Mon, 29 Jul 2013 07:24:15 -0500 Subject: Digital Ocean Message-ID: I've been unable to get ahold of cluebies @ digital ocean ; anyone in engr pls contact off list From khomyakov.andrey at gmail.com Mon Jul 29 16:07:19 2013 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 29 Jul 2013 12:07:19 -0400 Subject: management traffic QoS on Tunnel interfaces Message-ID: Hi all, I have been trying to come up with a qos policy (or rather where to apply it) for reserving some bandwidth for management traffic to the local router The setup is that a remote route is a spoke to a DMVPN network, thus has a couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh). I have no issue working out service policy for transiting traffic, however, I can't wrap my head around how to reserve some bandwidth for the locally originated SSH traffic (managing the router). I'd like to mark ssh response packets from the local router (1.1.1.1) with CS2,so i can match them in the tunnel policy shown below. Has anyone come across this task before? interface Loopback0 ip address 1.1.1.1 255.255.255.255 interface Tunnel0 ip address 2.2.2.2 255.255.255.0 qos pre-classify tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile protect-gre shared ! interface FastEthernet0/0 desc DSL/Cable/FiOS ip address 3.3.3.3 255.255.255.0 bandwidth 768 bandwidth receive 1500 service-policy output SHAPE-OUT-768 ! class-map match-any SSH match ip dscp cs2 ! policy-map SHAPE-OUT-768 class class-default shape average 768000 service-policy SSH ! service-policy SSH class SSH bandwidth percent 5 class class-default fair-queue queue-limit 15 packets --Andrey From darrenoc at outlook.com Mon Jul 29 16:31:21 2013 From: darrenoc at outlook.com (Darren O'Connor) Date: Mon, 29 Jul 2013 17:31:21 +0100 Subject: management traffic QoS on Tunnel interfaces In-Reply-To: References: Message-ID: In this class you are matching: class-map match-any SSH match ip dscp cs2 Why not just match an ACL for SSH traffic from the local router back to your management range? > From: khomyakov.andrey at gmail.com > Date: Mon, 29 Jul 2013 12:07:19 -0400 > Subject: management traffic QoS on Tunnel interfaces > To: nanog at nanog.org > > Hi all, > I have been trying to come up with a qos policy (or rather where to apply > it) for reserving some bandwidth for management traffic to the local router > The setup is that a remote route is a spoke to a DMVPN network, thus has a > couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh). > I have no issue working out service policy for transiting traffic, however, > I can't wrap my head around how to reserve some bandwidth for the locally > originated SSH traffic (managing the router). > > I'd like to mark ssh response packets from the local router (1.1.1.1) with > CS2,so i can match them in the tunnel policy shown below. > > Has anyone come across this task before? > > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > > interface Tunnel0 > ip address 2.2.2.2 255.255.255.0 > qos pre-classify > > tunnel source FastEthernet0/0 > tunnel mode gre multipoint > tunnel protection ipsec profile protect-gre shared > ! > interface FastEthernet0/0 > desc DSL/Cable/FiOS > ip address 3.3.3.3 255.255.255.0 > bandwidth 768 > bandwidth receive 1500 > service-policy output SHAPE-OUT-768 > ! > class-map match-any SSH > match ip dscp cs2 > ! > policy-map SHAPE-OUT-768 > class class-default > shape average 768000 > service-policy SSH > ! > service-policy SSH > class SSH > bandwidth percent 5 > class class-default > fair-queue > queue-limit 15 packets > > > > --Andrey From chuckchurch at gmail.com Mon Jul 29 19:47:15 2013 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 29 Jul 2013 15:47:15 -0400 Subject: management traffic QoS on Tunnel interfaces In-Reply-To: References: Message-ID: <003401ce8c94$72a8b2f0$57fa18d0$@gmail.com> Newer IOS support setting precedence or DSCP for outbound SSH: ip ssh prec 2 Thanks, Chuck -----Original Message----- From: Andrey Khomyakov [mailto:khomyakov.andrey at gmail.com] Sent: Monday, July 29, 2013 12:07 PM To: Nanog Subject: management traffic QoS on Tunnel interfaces Hi all, I have been trying to come up with a qos policy (or rather where to apply it) for reserving some bandwidth for management traffic to the local router The setup is that a remote route is a spoke to a DMVPN network, thus has a couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh). I have no issue working out service policy for transiting traffic, however, I can't wrap my head around how to reserve some bandwidth for the locally originated SSH traffic (managing the router). I'd like to mark ssh response packets from the local router (1.1.1.1) with CS2,so i can match them in the tunnel policy shown below. Has anyone come across this task before? interface Loopback0 ip address 1.1.1.1 255.255.255.255 interface Tunnel0 ip address 2.2.2.2 255.255.255.0 qos pre-classify tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile protect-gre shared ! interface FastEthernet0/0 desc DSL/Cable/FiOS ip address 3.3.3.3 255.255.255.0 bandwidth 768 bandwidth receive 1500 service-policy output SHAPE-OUT-768 ! class-map match-any SSH match ip dscp cs2 ! policy-map SHAPE-OUT-768 class class-default shape average 768000 service-policy SSH ! service-policy SSH class SSH bandwidth percent 5 class class-default fair-queue queue-limit 15 packets --Andrey From khomyakov.andrey at gmail.com Mon Jul 29 20:11:42 2013 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 29 Jul 2013 16:11:42 -0400 Subject: management traffic QoS on Tunnel interfaces In-Reply-To: References: Message-ID: Darren, My understanding that qos-preclassify will only copy ToS header from original packet to encrypted packet. Since service-policy is applied to the physical interface and is looking at already encrypted traffic, ACLs won't see the original source/destination Andrey --Andrey On Mon, Jul 29, 2013 at 12:31 PM, Darren O'Connor wrote: > In this class you are matching: > > class-map match-any SSH > match ip dscp cs2 > > Why not just match an ACL for SSH traffic from the local router back to your management range? > > > > > From: khomyakov.andrey at gmail.com > > Date: Mon, 29 Jul 2013 12:07:19 -0400 > > Subject: management traffic QoS on Tunnel interfaces > > To: nanog at nanog.org > > > > > Hi all, > > I have been trying to come up with a qos policy (or rather where to apply > > it) for reserving some bandwidth for management traffic to the local > router > > The setup is that a remote route is a spoke to a DMVPN network, thus has > a > > couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh). > > I have no issue working out service policy for transiting traffic, > however, > > I can't wrap my head around how to reserve some bandwidth for the locally > > originated SSH traffic (managing the router). > > > > I'd like to mark ssh response packets from the local router (1.1.1.1) > with > > CS2,so i can match them in the tunnel policy shown below. > > > > Has anyone come across this task before? > > > > interface Loopback0 > > ip address 1.1.1.1 255.255.255.255 > > > > interface Tunnel0 > > ip address 2.2.2.2 255.255.255.0 > > qos pre-classify > > > > tunnel source FastEthernet0/0 > > tunnel mode gre multipoint > > tunnel protection ipsec profile protect-gre shared > > ! > > interface FastEthernet0/0 > > desc DSL/Cable/FiOS > > ip address 3.3.3.3 255.255.255.0 > > bandwidth 768 > > bandwidth receive 1500 > > service-policy output SHAPE-OUT-768 > > ! > > class-map match-any SSH > > match ip dscp cs2 > > ! > > policy-map SHAPE-OUT-768 > > class class-default > > shape average 768000 > > service-policy SSH > > ! > > service-policy SSH > > class SSH > > bandwidth percent 5 > > class class-default > > fair-queue > > queue-limit 15 packets > > > > > > > > --Andrey > From khomyakov.andrey at gmail.com Mon Jul 29 21:09:55 2013 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 29 Jul 2013 17:09:55 -0400 Subject: management traffic QoS on Tunnel interfaces In-Reply-To: <003401ce8c94$72a8b2f0$57fa18d0$@gmail.com> References: <003401ce8c94$72a8b2f0$57fa18d0$@gmail.com> Message-ID: Looks like exactly what I'm looking for, but for some reason doesn't work. Below produces 0 packet match. ip ssh prec 2 class-map match-any SSH match ip dscp cs2 match ip precedence 2 As a test I also tried this: ip access-list extended Management_Access remark Play nice with router management traffic permit tcp any range 22 telnet any permit tcp any any range 22 telnet class-map match-any management match access-group name Management_Access policy-map Mark-Local-SSH class management set ip dscp cs2 ip local policy route-map Mark-Local-SSH --- Later on this matches 0 packets in both cases class-map match-any SSH match ip dscp cs2 match ip precedence 2 --Andrey On Mon, Jul 29, 2013 at 3:47 PM, Chuck Church wrote: > Newer IOS support setting precedence or DSCP for outbound SSH: > > ip ssh prec 2 > > > Thanks, > > Chuck > > -----Original Message----- > From: Andrey Khomyakov [mailto:khomyakov.andrey at gmail.com] > Sent: Monday, July 29, 2013 12:07 PM > To: Nanog > Subject: management traffic QoS on Tunnel interfaces > > Hi all, > I have been trying to come up with a qos policy (or rather where to apply > it) for reserving some bandwidth for management traffic to the local router > The setup is that a remote route is a spoke to a DMVPN network, thus has a > couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh). > I have no issue working out service policy for transiting traffic, however, > I can't wrap my head around how to reserve some bandwidth for the locally > originated SSH traffic (managing the router). > > I'd like to mark ssh response packets from the local router (1.1.1.1) with > CS2,so i can match them in the tunnel policy shown below. > > Has anyone come across this task before? > > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > > interface Tunnel0 > ip address 2.2.2.2 255.255.255.0 > qos pre-classify > > tunnel source FastEthernet0/0 > tunnel mode gre multipoint > tunnel protection ipsec profile protect-gre shared ! > interface FastEthernet0/0 > desc DSL/Cable/FiOS > ip address 3.3.3.3 255.255.255.0 > bandwidth 768 > bandwidth receive 1500 > service-policy output SHAPE-OUT-768 > ! > class-map match-any SSH > match ip dscp cs2 > ! > policy-map SHAPE-OUT-768 > class class-default > shape average 768000 > service-policy SSH > ! > service-policy SSH > class SSH > bandwidth percent 5 > class class-default > fair-queue > queue-limit 15 packets > > > > --Andrey > > From jrmitche at puck.nether.net Tue Jul 30 00:45:15 2013 From: jrmitche at puck.nether.net (Jon Mitchell) Date: Tue, 30 Jul 2013 02:45:15 +0200 Subject: management traffic QoS on Tunnel interfaces In-Reply-To: References: <003401ce8c94$72a8b2f0$57fa18d0$@gmail.com> Message-ID: <7AD83D5D-9226-4431-A3B7-ACD27DE14760@puck.nether.net> On some platforms locally generated traffic bypasses egress intf ACL/QoS, try your test with an ACL on ingress on a diff router in the path. -Jon On Jul 29, 2013, at 11:09 PM, Andrey Khomyakov wrote: > Looks like exactly what I'm looking for, but for some reason doesn't work. > Below produces 0 packet match. > > ip ssh prec 2 > > class-map match-any SSH > match ip dscp cs2 > match ip precedence 2 > > > As a test I also tried this: > > > > ip access-list extended Management_Access > remark Play nice with router management traffic > permit tcp any range 22 telnet any > permit tcp any any range 22 telnet > > class-map match-any management > match access-group name Management_Access > > policy-map Mark-Local-SSH > class management > set ip dscp cs2 > > ip local policy route-map Mark-Local-SSH > > --- > Later on this matches 0 packets in both cases > class-map match-any SSH > match ip dscp cs2 > match ip precedence 2 > > > > > > --Andrey > > > On Mon, Jul 29, 2013 at 3:47 PM, Chuck Church wrote: > >> Newer IOS support setting precedence or DSCP for outbound SSH: >> >> ip ssh prec 2 >> >> >> Thanks, >> >> Chuck >> >> -----Original Message----- >> From: Andrey Khomyakov [mailto:khomyakov.andrey at gmail.com] >> Sent: Monday, July 29, 2013 12:07 PM >> To: Nanog >> Subject: management traffic QoS on Tunnel interfaces >> >> Hi all, >> I have been trying to come up with a qos policy (or rather where to apply >> it) for reserving some bandwidth for management traffic to the local router >> The setup is that a remote route is a spoke to a DMVPN network, thus has a >> couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh). >> I have no issue working out service policy for transiting traffic, however, >> I can't wrap my head around how to reserve some bandwidth for the locally >> originated SSH traffic (managing the router). >> >> I'd like to mark ssh response packets from the local router (1.1.1.1) with >> CS2,so i can match them in the tunnel policy shown below. >> >> Has anyone come across this task before? >> >> interface Loopback0 >> ip address 1.1.1.1 255.255.255.255 >> >> interface Tunnel0 >> ip address 2.2.2.2 255.255.255.0 >> qos pre-classify >> >> tunnel source FastEthernet0/0 >> tunnel mode gre multipoint >> tunnel protection ipsec profile protect-gre shared ! >> interface FastEthernet0/0 >> desc DSL/Cable/FiOS >> ip address 3.3.3.3 255.255.255.0 >> bandwidth 768 >> bandwidth receive 1500 >> service-policy output SHAPE-OUT-768 >> ! >> class-map match-any SSH >> match ip dscp cs2 >> ! >> policy-map SHAPE-OUT-768 >> class class-default >> shape average 768000 >> service-policy SSH >> ! >> service-policy SSH >> class SSH >> bandwidth percent 5 >> class class-default >> fair-queue >> queue-limit 15 packets >> >> >> >> --Andrey >> >> From basilarchia at gmail.com Tue Jul 30 07:11:15 2013 From: basilarchia at gmail.com (Jeff Carr) Date: Tue, 30 Jul 2013 03:11:15 -0400 Subject: Digital Ocean In-Reply-To: References: Message-ID: I don't mind doing it on list if that makes any difference. Please understand we are all under tremendous stress and growing pains here. Your best bet is to email noc at digitalocean.com. If that doesn't work, email me. -- Jeff Carr Chief Architect PS: We are hiring On Mon, Jul 29, 2013 at 8:24 AM, jamie rishaw wrote: > I've been unable to get ahold of cluebies @ digital ocean ; anyone in engr > pls contact off list > From joly at punkcast.com Tue Jul 30 09:32:56 2013 From: joly at punkcast.com (Joly MacFie) Date: Tue, 30 Jul 2013 05:32:56 -0400 Subject: =?windows-1252?Q?WEBCAST=3A_ISOC_=40_IETF_=96_Improving_Internet_Experien?= =?windows-1252?Q?ce=3A_All_Together_Now?= Message-ID: This is just about to start. Not on the IETF schedule. The panel will tackle the fundamental questions of how to avoid conflicting congestion fixes that screw up transmission protocols. Should be interesting. ** joly posted: "Today, Tuesday July 29 2013 the Internet Society will present a briefing panel at IETF 87 in Berlin, topic: "Improving Internet Experience: All together, now." As Internet use and user expectations grow, it is natural that network and service providers, a" [image: ISOC @ IETF 87]Today, Tuesday July 30 2013 the Internet Society will present a briefing panel at IETF 87 in Berlin, topic: "Improving Internet Experience: All together, now." As Internet use and user expectations grow, it is natural that network and service providers, as well as software developers, are all looking to provide the best experience possible for their users and customers. However, performance issues (especially those related to transient congestion) tend to have collateral effects. This is a case where local optimization strategies may, in fact, not lead to globally optimal network performance for a given activity. In fact, server or client software developers' assumptions about network conditions may lead to disastrously wrong choices in managing network traffic if software elsewhere in the network is making different and countervailing assumptions and choices.This panel will explore some of the different approaches being developed, between website, network transport and server developers, their assumptions about network performance and potential collision of strategies. Panelists will also further elaborate existing work in measuring and developing (and deploying!) standards-based transport layer strategies for robustly improving overall performance. Speakers include Stuart Cheshire of Apple, Jason Livingood of Comcast, and Patrick McManus of Mozilla. Internet Society Chief Internet Technology Officer Leslie Daigle will moderate. The session will be webcast live via the Internet Society livestream channeland an audio feed will also be available. *What*: Internet Society Briefing Panel @ IETF 87 - "Improving Internet Experience: All together, now." *Where*: InterContinental Hotel, Berlin, Germany *When*: Tuesday, 30 July 2013 11:45 am-12:45 pm CEST | 0945-1045 UTC | 0545-0645 EDT *Program*: http://www.internetsociety.org/internet-society-briefing-panel-ietf-87 *Webcast*: https://new.livestream.com/internetsociety/ietf87isocbriefing *Audio stream*: http://www.verilan.com/isoc.m3u *Twitter*: @InternetSociety Comment See all comments *Permalink* http://isoc-ny.org/p2/5835 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From leo.vegoda at icann.org Tue Jul 30 17:15:19 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 30 Jul 2013 10:15:19 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <640AF583-224C-4E71-B402-387CDC237079@arin.net> References: <51F27A89.4080704@nac.net> <5FE1FB6D43B8A647BBC821840C1AEA8B018793@ocsbs.ocosa.com> <3914388E-43DD-44A7-BF6B-BF95E0FFD52C@corp.arin.net> <640AF583-224C-4E71-B402-387CDC237079@arin.net> Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E131A8DD@EXVPMBX100-1.exc.icann.org> Hi, John Curran wrote: > On Jul 26, 2013, at 4:34 PM, Jimmy Hess wrote: > > > If someone studies that and finds there is a correlation to spam based > > on WHOIS listing alone, > > then perhaps.... > > No study has been conducted, but we do receive a small number of complaints > each year about email contact information being solicited in cases were the > email address is exclusively used on IP address blocks and nowhere else. > (Often, the culprits are network equipment vendors or technical recruiters) SSAC conducted a study on the subject of gTLD whois and spam: http://www.icann.org/en/groups/ssac/documents/sac-023-en.htm As the gTLD and ARIN systems are different the outcomes could also be different but it might be useful as a comparison, if nothing else. Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From ryan.landry at gmail.com Tue Jul 30 17:34:25 2013 From: ryan.landry at gmail.com (ryanL) Date: Tue, 30 Jul 2013 13:34:25 -0400 Subject: vodafone contact Message-ID: anyone hanging out from vodafone in europe? or anyone know someone over at vodafone? we are having goofy issues with mobile clients on your LTE network. we're having to dump mtu and advmss a whole bunch to make things work. wondering if you'd be willing to chat offline. appreciated. r From amitchell at isipp.com Tue Jul 30 17:46:06 2013 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Tue, 30 Jul 2013 11:46:06 -0600 Subject: Contacts at ISPs in Mexico? Message-ID: Are there any Mexico ISPs on the list or does anybody here have any contacts at any Mexican ISPs? Thank you, Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 CEO/President: Institute for Social Internet Public Policy Providers: SuretyMail Email Accreditation Member: California Bar Cyberspace Law Committee From nick at foobar.org Tue Jul 30 18:13:57 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 30 Jul 2013 19:13:57 +0100 Subject: vodafone contact In-Reply-To: References: Message-ID: <51F80265.10705@foobar.org> On 30/07/2013 18:34, ryanL wrote: > anyone hanging out from vodafone in europe? or anyone know someone over at > vodafone? we are having goofy issues with mobile clients on your LTE > network. we're having to dump mtu and advmss a whole bunch to make things > work. wondering if you'd be willing to chat offline. "vodafone europe" is mostly run on a per country basis. You'll need to specify which asn + country you're talking about Nick From jwbensley at gmail.com Tue Jul 30 18:21:15 2013 From: jwbensley at gmail.com (James Bensley) Date: Tue, 30 Jul 2013 19:21:15 +0100 Subject: Contacts at ISPs in Mexico? In-Reply-To: References: Message-ID: You might have better luck asking at LACNOG; https://mail.lacnic.net/mailman/listinfo/lacnog Cheers, James. From ryan.landry at gmail.com Tue Jul 30 19:08:23 2013 From: ryan.landry at gmail.com (ryanL) Date: Tue, 30 Jul 2013 15:08:23 -0400 Subject: vodafone contact In-Reply-To: <51F80265.10705@foobar.org> References: <51F80265.10705@foobar.org> Message-ID: the common transit point for this problem is vodafone backone: aut-num: AS3209 as-name: VODANET On Tue, Jul 30, 2013 at 2:13 PM, Nick Hilliard wrote: > On 30/07/2013 18:34, ryanL wrote: > > anyone hanging out from vodafone in europe? or anyone know someone over > at > > vodafone? we are having goofy issues with mobile clients on your LTE > > network. we're having to dump mtu and advmss a whole bunch to make things > > work. wondering if you'd be willing to chat offline. > > "vodafone europe" is mostly run on a per country basis. You'll need to > specify which asn + country you're talking about > > Nick > > From bill at herrin.us Tue Jul 30 20:00:32 2013 From: bill at herrin.us (William Herrin) Date: Tue, 30 Jul 2013 16:00:32 -0400 Subject: which firewall product? Message-ID: Hi folks, I'm trying to identify a firewall appliance for one of my customers. The wrinkle is: it has to be able to inspect packets inside an IPIP tunnel and accept/reject based on IP address, TCP port number and standard things like that. On the packet carried *inside* the IPIP tunnel packet. >From what I can tell, the Cisco ASA can't do this. Linux iptables can (with the u32 match module) but the customer wants an appliance, not a server. What appliances do you know of that can do this? Is there a different Cisco box? A Juniper firewall? Anything else? Thanks in advance, 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 Tue Jul 30 20:03:52 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 30 Jul 2013 20:03:52 +0000 Subject: which firewall product? In-Reply-To: References: Message-ID: Look into pfsense. It's rock solid and bad based, and can be purchased as an appliance. (both real and vm) Sent from my Mobile Device. -------- Original message -------- From: William Herrin Date: 07/30/2013 1:02 PM (GMT-08:00) To: nanog at nanog.org Subject: which firewall product? Hi folks, I'm trying to identify a firewall appliance for one of my customers. The wrinkle is: it has to be able to inspect packets inside an IPIP tunnel and accept/reject based on IP address, TCP port number and standard things like that. On the packet carried *inside* the IPIP tunnel packet. >From what I can tell, the Cisco ASA can't do this. Linux iptables can (with the u32 match module) but the customer wants an appliance, not a server. What appliances do you know of that can do this? Is there a different Cisco box? A Juniper firewall? Anything else? Thanks in advance, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dwessels at verisign.com Tue Jul 30 20:05:15 2013 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 30 Jul 2013 20:05:15 +0000 Subject: .gov DNSSEC operational message Message-ID: <85ED6D15-1809-4AC2-BFD3-461B7102B5E5@verisign.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An algorithm roll for the .gov zone will occur at the end of August, 2013. This notice is provided as a courtesy to the DNSSEC community. No action should be required on your part. The .gov zone is currently signed with algorithm 7 (RSASHA1-NSEC3-SHA1) and will be changed to use algorithm 8 (RSA/SHA-256), bringing it in line with other top-level domains such as as .com, .net, and the root zone. The zone will be signed with both algorithms for a period of approximately 10 days. Further scheduling details will be provided one week before the algorithm roll begins. Duane W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR+BwJAAoJEGyZpGmowJiNb1QIAL4VURzp377H7iX8ZaBfljTt pdj6gTyChZe4M4AwTslT3woTBMwJZsOYxMKFnGcPoxFd0ROT1HuFKt1JE5G6ITBN +qHQJFplgU4SBKcknAcIL5/0DXgqeGVR9JYsbkRiytocp89eBWx8lhZuVRqQCRDw u/ZiKluAd32ioSosuzAJJawRp0PZQKJX8/WQ5HnLPeDpH3jHDR21I5RDp35l8X0x GIiD9+UV1yivYr4JhjLfVqTkToND+m3rwG7c6VwUf8PxCv5mEJN3sFpC72HsRvCd uNipDuwaAcYLFCx3mSUsuXjUttUXe9yFE9v3rPZ286eMo5GqVvs+Zy7yjrQuOpU= =p/aG -----END PGP SIGNATURE----- From charles-lists at knownelement.com Tue Jul 30 20:10:23 2013 From: charles-lists at knownelement.com (Charles N Wyble) Date: Tue, 30 Jul 2013 15:10:23 -0500 Subject: which firewall product? In-Reply-To: References: Message-ID: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> Not sure how bsd handles ipip connections. If it breaks them out as a dedicated interface (like it does for openvpn connections) , then rules can be applied and pfsense would be quite useful. The UI is very simple. Warren Bailey wrote: >Look into pfsense. It's rock solid and bad based, and can be purchased >as an appliance. (both real and vm) > > >Sent from my Mobile Device. > > >-------- Original message -------- >From: William Herrin >Date: 07/30/2013 1:02 PM (GMT-08:00) >To: nanog at nanog.org >Subject: which firewall product? > > >Hi folks, > >I'm trying to identify a firewall appliance for one of my customers. >The wrinkle is: it has to be able to inspect packets inside an IPIP >tunnel and accept/reject based on IP address, TCP port number and >standard things like that. On the packet carried *inside* the IPIP >tunnel packet. > > >From what I can tell, the Cisco ASA can't do this. > >Linux iptables can (with the u32 match module) but the customer wants >an appliance, not a server. > >What appliances do you know of that can do this? Is there a different >Cisco box? A Juniper firewall? Anything else? > >Thanks in advance, >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 device with K-9 Mail. Please excuse my brevity. From michael at supermathie.net Tue Jul 30 20:19:34 2013 From: michael at supermathie.net (Michael Brown) Date: Tue, 30 Jul 2013 16:19:34 -0400 Subject: which firewall product? In-Reply-To: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> Message-ID: <51F81FD6.9000605@supermathie.net> In the pfSense UI, you create the physical interface as a GRE tunnel then assign it to a logical interface against which you can apply the firewall rules: The screenshot is a GIF IPv6 he.net tunnel (this is 2.1RC0) but it works the same way on 2.0.1. Works great! M. On 13-07-30 04:10 PM, Charles N Wyble wrote: > Not sure how bsd handles ipip connections. If it breaks them out as a dedicated interface (like it does for openvpn connections) , then rules can be applied and pfsense would be quite useful. The UI is very simple. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From jared at compuwizz.net Tue Jul 30 20:31:32 2013 From: jared at compuwizz.net (Jared Geiger) Date: Tue, 30 Jul 2013 13:31:32 -0700 Subject: Brighthouse issues Message-ID: We are seeing that all our customers in the Brighthouse Orlando, FL market that would make outbound connections on TCP port 3306 suddenly can't connect to us now. This happened suddenly mid day today. Other ISPs can still make the same outbound connections. VPN connections on Brighthouse into the same IP block work fine, just outbound port 3306 is being blocked now. If anyone has details as to an emergency maintenance or change that occurred, I'd like to be able to pass it along to our customers. Thanks, Jared From bill at herrin.us Tue Jul 30 20:38:49 2013 From: bill at herrin.us (William Herrin) Date: Tue, 30 Jul 2013 16:38:49 -0400 Subject: which firewall product? In-Reply-To: <51F81FD6.9000605@supermathie.net> References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> <51F81FD6.9000605@supermathie.net> Message-ID: On Tue, Jul 30, 2013 at 4:19 PM, Michael Brown wrote: > In the pfSense UI, you create the physical interface as a GRE tunnel > then assign it to a logical interface against which you can apply the firewall rules: Thanks all. To be clear: I'm dealing with IPIP packets, not GRE packets. Linux LVS emits IPIP encapsulated packets when the target server is non-local. I have no option to emit GRE or another kind of tunnel packet. Also, I'd prefer not to terminate the IPIP tunnel on the firewall. I can, but I'd prefer not to. What I want to do is look inside at the packet encapsulated by IPIP. Even if I have to hand-crank the rules in terms of byte X inside the packet should be value Y. Thanks again, 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 Tue Jul 30 21:36:38 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 30 Jul 2013 16:36:38 -0500 Subject: which firewall product? In-Reply-To: References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> <51F81FD6.9000605@supermathie.net> Message-ID: Well, I guess my first question is: Is this a design you are stuck with for some reason or alternately, is there a good reason for it, and I need to be educated as to real world design? It seems rather odd to put a firewall boundry between a LB and its associated cluster as opposed to in front of the LB. I've looked into something like this before for unrelated issues, and never really was very happy with the results. -Blake On Tue, Jul 30, 2013 at 3:38 PM, William Herrin wrote: > On Tue, Jul 30, 2013 at 4:19 PM, Michael Brown > wrote: > > In the pfSense UI, you create the physical interface as a GRE tunnel > > then assign it to a logical interface against which you can apply the > firewall rules: > > Thanks all. To be clear: I'm dealing with IPIP packets, not GRE > packets. Linux LVS emits IPIP encapsulated packets when the target > server is non-local. I have no option to emit GRE or another kind of > tunnel packet. > > Also, I'd prefer not to terminate the IPIP tunnel on the firewall. I > can, but I'd prefer not to. What I want to do is look inside at the > packet encapsulated by IPIP. Even if I have to hand-crank the rules in > terms of byte X inside the packet should be value Y. > > Thanks again, > 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 Tue Jul 30 22:39:38 2013 From: bill at herrin.us (William Herrin) Date: Tue, 30 Jul 2013 18:39:38 -0400 Subject: which firewall product? In-Reply-To: References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> <51F81FD6.9000605@supermathie.net> Message-ID: On Tue, Jul 30, 2013 at 5:36 PM, Blake Dunlap wrote: > Well, I guess my first question is: Is this a design you are stuck with for > some reason or alternately, is there a good reason for it, and I need to be > educated as to real world design? It seems rather odd to put a firewall > boundry between a LB and its associated cluster as opposed to in front of > the LB. Howdy, Paperwork. The customer owns 3 servers in a system of a consisting of a hundred or so. He wants his security people to accredit it. They won't accredit individual servers, so his options were: duplicate the full system just for him (very expensive) or create a security boundary where he can say, "This is my enclave. Accredit my enclave." Naturally his security people decide that they don't want the firewalls to be additional servers running Linux. That would make it far too easy to secure his system. I don't yet know if they'd accept an appliance running Linux underneath. :/ -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kkinkaid at usgs.gov Tue Jul 30 22:28:05 2013 From: kkinkaid at usgs.gov (Kinkaid, Kyle) Date: Tue, 30 Jul 2013 15:28:05 -0700 Subject: which firewall product? In-Reply-To: References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> <51F81FD6.9000605@supermathie.net> Message-ID: Hi Bill, I found nDPI (http://www.ntop.org/products/ndpi/) lists IP in IP as a supported protocol. That doesn't fit your requirement that it be an appliance but maybe it gets you going in the right direction. Cheers, Kyle On Tue, Jul 30, 2013 at 1:38 PM, William Herrin wrote: > On Tue, Jul 30, 2013 at 4:19 PM, Michael Brown > wrote: > > In the pfSense UI, you create the physical interface as a GRE tunnel > > then assign it to a logical interface against which you can apply the > firewall rules: > > Thanks all. To be clear: I'm dealing with IPIP packets, not GRE > packets. Linux LVS emits IPIP encapsulated packets when the target > server is non-local. I have no option to emit GRE or another kind of > tunnel packet. > > Also, I'd prefer not to terminate the IPIP tunnel on the firewall. I > can, but I'd prefer not to. What I want to do is look inside at the > packet encapsulated by IPIP. Even if I have to hand-crank the rules in > terms of byte X inside the packet should be value Y. > > Thanks again, > 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 Jul 30 22:56:35 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Jul 2013 15:56:35 -0700 Subject: which firewall product? In-Reply-To: References: Message-ID: Aren't there appliance versions that are just iptables/linux under the hood? For example, IPCop, IPFire, Smoothwall, Untangle, and Vyatta should fit the bill. Owen On Jul 30, 2013, at 13:00 , William Herrin wrote: > Hi folks, > > I'm trying to identify a firewall appliance for one of my customers. > The wrinkle is: it has to be able to inspect packets inside an IPIP > tunnel and accept/reject based on IP address, TCP port number and > standard things like that. On the packet carried *inside* the IPIP > tunnel packet. > > >> From what I can tell, the Cisco ASA can't do this. > > Linux iptables can (with the u32 match module) but the customer wants > an appliance, not a server. > > What appliances do you know of that can do this? Is there a different > Cisco box? A Juniper firewall? Anything else? > > Thanks in advance, > 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 Jul 30 22:57:41 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Jul 2013 15:57:41 -0700 Subject: which firewall product? In-Reply-To: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> Message-ID: On Jul 30, 2013, at 13:10 , Charles N Wyble wrote: > Not sure how bsd handles ipip connections. If it breaks them out as a dedicated interface (like it does for openvpn connections) , then rules can be applied and pfsense would be quite useful. The UI is very simple. That would only work if the firewall were terminating the tunnel instead of passing the tunneled traffic through still inside the tunnel. I believe Bill is looking for DPI on forwarded traffic and not to decapsulate the traffic prior to inspection. Owen > > Warren Bailey wrote: >> Look into pfsense. It's rock solid and bad based, and can be purchased >> as an appliance. (both real and vm) >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: William Herrin >> Date: 07/30/2013 1:02 PM (GMT-08:00) >> To: nanog at nanog.org >> Subject: which firewall product? >> >> >> Hi folks, >> >> I'm trying to identify a firewall appliance for one of my customers. >> The wrinkle is: it has to be able to inspect packets inside an IPIP >> tunnel and accept/reject based on IP address, TCP port number and >> standard things like that. On the packet carried *inside* the IPIP >> tunnel packet. >> >> >> From what I can tell, the Cisco ASA can't do this. >> >> Linux iptables can (with the u32 match module) but the customer wants >> an appliance, not a server. >> >> What appliances do you know of that can do this? Is there a different >> Cisco box? A Juniper firewall? Anything else? >> >> Thanks in advance, >> 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 device with K-9 Mail. Please excuse my brevity. From mysidia at gmail.com Tue Jul 30 23:15:49 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 30 Jul 2013 18:15:49 -0500 Subject: which firewall product? In-Reply-To: References: Message-ID: On 7/30/13, William Herrin wrote: > Hi folks, I don't know about IPIP tunnel inspection; it seems like an odd requirement to me, unless you mean _preventing_ IPIP tunnels from being established, in that case a non-appliance solution may be necessary. Is the IPIP tunnel supposed to land on the firewall; or to traverse it? I would encourage looking at Checkpoint / Palo Alto / Stonegate / Sonicwall / some others. I think LAN "firewall products" that cannot do SSL decryption and application identification (regardless of TCP port number) have begun to outlive their usefulness; the ASA pretty much falls in that category unless you bought lots of expensive addons, and unless Cisco finally fixed all the nasty bugs that occur if you actually attempted to use the deep protocol inspection features? > I'm trying to identify a firewall appliance for one of my customers. > The wrinkle is: it has to be able to inspect packets inside an IPIP > tunnel and accept/reject based on IP address, TCP port number and > standard things like that. On the packet carried *inside* the IPIP > tunnel packet. > From what I can tell, the Cisco ASA can't do this. > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us -- -JH From rgolodner at infratection.com Wed Jul 31 00:05:43 2013 From: rgolodner at infratection.com (Richard Golodner) Date: Tue, 30 Jul 2013 19:05:43 -0500 Subject: which firewall product? In-Reply-To: References: Message-ID: <1375229143.2023.5.camel@Andromeda> On Tue, 2013-07-30 at 18:15 -0500, Jimmy Hess wrote: > I would encourage looking at Checkpoint / Palo > Alto / Stonegate / Sonicwall / some others. > If this were me, I would give Stonegate a call and explain what I wanted to have happen. They are knowledgeable and kind folks. I can't speculate about the IPIP tunnels, but they will be able to give you an answer. I have used their products and found them to be very good. Then again, this is just me. Good luck solving your problem. Richard From ikiris at gmail.com Wed Jul 31 00:13:22 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 30 Jul 2013 19:13:22 -0500 Subject: which firewall product? In-Reply-To: References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> <51F81FD6.9000605@supermathie.net> Message-ID: Understood. I expected as much but thought I'd ask. Most of my suggestions would require more knowledge of the layout to be filtered out. I really don't know what you'd find that would do what you want in this case, based on the requirements stated previously. Sorry =/ I'd look more to finding a way to make it a truly isolated unit that they could audit personally, instead of a distributed zone with boundaries in the middle. -Blake On Tue, Jul 30, 2013 at 5:39 PM, William Herrin wrote: > On Tue, Jul 30, 2013 at 5:36 PM, Blake Dunlap wrote: > > Well, I guess my first question is: Is this a design you are stuck with > for > > some reason or alternately, is there a good reason for it, and I need to > be > > educated as to real world design? It seems rather odd to put a firewall > > boundry between a LB and its associated cluster as opposed to in front of > > the LB. > > Howdy, > > Paperwork. The customer owns 3 servers in a system of a consisting of > a hundred or so. He wants his security people to accredit it. They > won't accredit individual servers, so his options were: duplicate the > full system just for him (very expensive) or create a security > boundary where he can say, "This is my enclave. Accredit my enclave." > > Naturally his security people decide that they don't want the > firewalls to be additional servers running Linux. That would make it > far too easy to secure his system. I don't yet know if they'd accept > an appliance running Linux underneath. :/ > > -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 Wed Jul 31 02:55:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 30 Jul 2013 22:55:02 -0400 (EDT) Subject: Brighthouse issues In-Reply-To: Message-ID: <1646736.2680.1375239302313.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Geiger" > We are seeing that all our customers in the Brighthouse Orlando, FL market > that would make outbound connections on TCP port 3306 suddenly can't > connect to us now. This happened suddenly mid day today. > > Other ISPs can still make the same outbound connections. VPN connections on > Brighthouse into the same IP block work fine, just outbound port 3306 > is being blocked now. > > If anyone has details as to an emergency maintenance or change that > occurred, I'd like to be able to pass it along to our customers. Speculation: are these residential class cablemodem customers? Carriers are prone to block uncommon ports on such modems at random. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jeff-kell at utc.edu Wed Jul 31 03:02:21 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 30 Jul 2013 23:02:21 -0400 Subject: Brighthouse issues In-Reply-To: <1646736.2680.1375239302313.JavaMail.root@benjamin.baylink.com> References: <1646736.2680.1375239302313.JavaMail.root@benjamin.baylink.com> Message-ID: <51F87E3D.6050109@utc.edu> On 7/30/2013 10:55 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jared Geiger" >> >> We are seeing that all our customers in the Brighthouse Orlando, FL market >> that would make outbound connections on TCP port 3306 suddenly can't >> connect to us now. This happened suddenly mid day today. >> >> Speculation: are these residential class cablemodem customers? Carriers >> are prone to block uncommon ports on such modems at random. Yeah, 3306 is MySQL. Overly-paranoid firewall somewhere? DDoS mitigation collateral damage? Jeff From jared at compuwizz.net Wed Jul 31 03:33:57 2013 From: jared at compuwizz.net (Jared Geiger) Date: Tue, 30 Jul 2013 20:33:57 -0700 Subject: Brighthouse issues In-Reply-To: <51F87E3D.6050109@utc.edu> References: <1646736.2680.1375239302313.JavaMail.root@benjamin.baylink.com> <51F87E3D.6050109@utc.edu> Message-ID: On Tue, Jul 30, 2013 at 8:02 PM, Jeff Kell wrote: > On 7/30/2013 10:55 PM, Jay Ashworth wrote: > > ----- Original Message ----- > >> From: "Jared Geiger" > >> > >> We are seeing that all our customers in the Brighthouse Orlando, FL > market > >> that would make outbound connections on TCP port 3306 suddenly can't > >> connect to us now. This happened suddenly mid day today. > >> > > >> Speculation: are these residential class cablemodem customers? Carriers > >> are prone to block uncommon ports on such modems at random. > > Yeah, 3306 is MySQL. Overly-paranoid firewall somewhere? DDoS > mitigation collateral damage? > > > I routed around nlayer>TWC>Brighthouse to Cogent>XO>Brighthouse and problem was resolved. So the first path has something wonky. The reverse path is BHN>Level3>Inforelay>Me. So my guess is there is something in nlayer or TWC 7843 that is filtering/limiting it. From morrowc.lists at gmail.com Wed Jul 31 07:40:00 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 31 Jul 2013 03:40:00 -0400 Subject: which firewall product? In-Reply-To: References: <0a63d3fc-4506-41ce-90f5-e38402f68b8a@email.android.com> Message-ID: On Tue, Jul 30, 2013 at 6:57 PM, Owen DeLong wrote: > I believe Bill is looking for DPI on forwarded traffic and not to decapsulate the traffic prior to inspection. oh! dpi? just use sandvine? comcast says that the work well... From morrowc.lists at gmail.com Wed Jul 31 07:45:23 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 31 Jul 2013 03:45:23 -0400 Subject: vodafone contact In-Reply-To: References: <51F80265.10705@foobar.org> Message-ID: got an example item to test with too? I'm sure they'll want to see that as well. On Tue, Jul 30, 2013 at 3:08 PM, ryanL wrote: > the common transit point for this problem is vodafone backone: > > aut-num: AS3209 > as-name: VODANET > > > On Tue, Jul 30, 2013 at 2:13 PM, Nick Hilliard wrote: > >> On 30/07/2013 18:34, ryanL wrote: >> > anyone hanging out from vodafone in europe? or anyone know someone over >> at >> > vodafone? we are having goofy issues with mobile clients on your LTE >> > network. we're having to dump mtu and advmss a whole bunch to make things >> > work. wondering if you'd be willing to chat offline. >> >> "vodafone europe" is mostly run on a per country basis. You'll need to >> specify which asn + country you're talking about >> >> Nick >> >> From tdurack at gmail.com Wed Jul 31 13:28:50 2013 From: tdurack at gmail.com (Tim Durack) Date: Wed, 31 Jul 2013 09:28:50 -0400 Subject: GTT/Inteliquent/nLayer Message-ID: Any experience/comments on the GTT Global eXpress service? Looks interesting but odd. Why would I use a virtual IXP? Who participates? Comments on-list or off-list are fine. -- Tim:> From luan20176 at gmail.com Wed Jul 31 14:06:32 2013 From: luan20176 at gmail.com (Luan Nguyen) Date: Wed, 31 Jul 2013 10:06:32 -0400 Subject: File transfer speed between Hong Kong and Johannesburg, South Africa In-Reply-To: <51DF601A.90200@cox.net> References: <51DF601A.90200@cox.net> Message-ID: Just a note on this thread, we got everything sorted out. There was a little asymmetric routing going on, but the great folks at HGC was very quick in helping us fix this. We had some problem with HGC support at the Hutch before, but they are great and fast now. At the other end in Johannesburg, we have our sister company and Ruhann was great with helping us out. In the end, with the Riverbed we get 1.5MBytes/sec bidirectional for SMB2 (active/active SQL database log shipping). With High-Speed TCP setting, we could get to 7MBytes/sec. Regards, -Luan On Thu, Jul 11, 2013 at 9:47 PM, Larry Sheldon wrote: > On 7/11/2013 10:32 AM, Clayton Zekelman wrote: > >> >> It all depends on the air speed velocity of an unladen swallow, and >> varies if it is African or Eurpoean. >> >> In all seriousness, you need to know the speed and latency of the link >> before that question can be answered. >> >> At 10:04 AM 11/07/2013, Luan Nguyen wrote: >> >>> Hello folks, >>> >>> Does anyone know what's the average speed for windows file transferring >>> (SMB2) between Hong Kong and Johannesburg? >>> Any guide on how to calculate/estimate this? >>> >> > An old-timers-uncalibrated-guess" If you are going to do large transfers > using a protocol designed (for want of a term) for local area networks with > near-fault free performance over a long multihop network, you are not going > to like it. > > What criteria drive the selection of such an unlikely protocol? > > > -- > 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 bottiger10 at gmail.com Wed Jul 31 04:25:44 2013 From: bottiger10 at gmail.com (bottiger) Date: Tue, 30 Jul 2013 21:25:44 -0700 Subject: SNMP DDoS: the vulnerability you might not know you have Message-ID: Before you skim past this email because you already read the Prolexic report on it or some other article on the internet, there are 2 disturbing properties that I haven't found anywhere else online. 1) After sending abuse emails to many networks, we received many angry replies that they monitored their traffic for days without seeing anything (even as we were being attacked) and that their IPs were spoofed and would block us for spamming them. What we discovered was that their firewalls/routers/gateways coming from vendors like Cisco and SonicWall apparently didn't record SNMP traffic going in or out of themselves. We confirmed this multiple times by running a query to an IP that was claimed to be clean and watching the response come 10-60 seconds later because the device was being so heavily abused. 2) SNMP reflection offers the largest amplification factor by far, even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a 68 byte query and received responses of up to 30,000 to 60,000 bytes. The trick is to use GetBulkRequest to start enumerating from the first OID and setting max repetitions to a large number. This is contrary to the other articles online which suggest a much smaller amplification factor with other queries. This protocol is also prevalent in many devices ranging from routers to printers. To solve this problem you should block SNMP traffic coming from outside your network and whitelist outside IPs that require it. From wbailey at satelliteintelligencegroup.com Wed Jul 31 14:46:15 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 31 Jul 2013 14:46:15 +0000 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' Message-ID: Tin foil hat Wednesday, limited supplies. Revealed: NSA program collects 'nearly everything a user does on the internet' http://gu.com/p/3hy4h Sent from my Mobile Device. From ikiris at gmail.com Wed Jul 31 14:57:32 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 31 Jul 2013 09:57:32 -0500 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: Message-ID: This looks like more a security issue with the devices, not border security issues. If you're seeing replies of that size, it means the devices themselves are set up to allow public queries of their information (not secured by even keys), which no one should be comfortable with. People should never be leaving the public access snmp strings on devices even if they are internal. Edge blocking just masks the real issue. -Blake On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: > Before you skim past this email because you already read the Prolexic > report on it or some other article on the internet, there are 2 > disturbing properties that I haven't found anywhere else online. > > 1) After sending abuse emails to many networks, we received many angry > replies that they monitored their traffic for days without seeing > anything (even as we were being attacked) and that their IPs were > spoofed and would block us for spamming them. > > What we discovered was that their firewalls/routers/gateways coming > from vendors like Cisco and SonicWall apparently didn't record SNMP > traffic going in or out of themselves. We confirmed this multiple > times by running a query to an IP that was claimed to be clean and > watching the response come 10-60 seconds later because the device was > being so heavily abused. > > 2) SNMP reflection offers the largest amplification factor by far, > even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a > 68 byte query and received responses of up to 30,000 to 60,000 bytes. > The trick is to use GetBulkRequest to start enumerating from the first > OID and setting max repetitions to a large number. This is contrary to > the other articles online which suggest a much smaller amplification > factor with other queries. > > This protocol is also prevalent in many devices ranging from routers > to printers. > > To solve this problem you should block SNMP traffic coming from > outside your network and whitelist outside IPs that require it. > > From jay at west.net Wed Jul 31 15:00:19 2013 From: jay at west.net (Jay Hennigan) Date: Wed, 31 Jul 2013 08:00:19 -0700 Subject: ARIN WHOIS for leads In-Reply-To: <51F2968A.3090701@opus1.com> References: <51F2968A.3090701@opus1.com> Message-ID: <51F92683.3080200@west.net> On 7/26/13 8:32 AM, Joel M Snyder wrote: > I also don't see the problem of cold calling when it's obviously for a > service or product that I am interested in, just as I don't see the > problem of cold snail-mailing for the same services. I'm in business, > and I expect other businesses to try and market to me. I have a low tolerance for telemarketers, especially those who scrape technical lists or databases. One test I have is to immediately ask, "Is this a sales call?" Anything other than a forthright "Yes" gets nowhere. Weasel words don't count. If the first thing they tell me is a lie, I don't want to do business with them. If they're honest I might give them a minute or two to pitch their wares. It's surprising how people go out of their way to deny that it's a sales call, and then start trying to sell something. -- 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 tstpierre at iweb.com Wed Jul 31 15:17:37 2013 From: tstpierre at iweb.com (Thomas St-Pierre) Date: Wed, 31 Jul 2013 15:17:37 +0000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: Message-ID: The problem isn't the people on this list leaving the public snmp community on their devices, it's the vendors of home routers leaving it there in their devices. Normal end users don't know or even care what snmp is. (nor can we expect them too) A simple scan of a large cable/dsl ISP's address space will likely net you tens of thousands of devices which respond to the "public" snmp community. Thomas On 13-07-31 10:57 AM, "Blake Dunlap" wrote: >This looks like more a security issue with the devices, not border >security >issues. > >If you're seeing replies of that size, it means the devices themselves are >set up to allow public queries of their information (not secured by even >keys), which no one should be comfortable with. People should never be >leaving the public access snmp strings on devices even if they are >internal. Edge blocking just masks the real issue. > > >-Blake > > >On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: > >> Before you skim past this email because you already read the Prolexic >> report on it or some other article on the internet, there are 2 >> disturbing properties that I haven't found anywhere else online. >> >> 1) After sending abuse emails to many networks, we received many angry >> replies that they monitored their traffic for days without seeing >> anything (even as we were being attacked) and that their IPs were >> spoofed and would block us for spamming them. >> >> What we discovered was that their firewalls/routers/gateways coming >> from vendors like Cisco and SonicWall apparently didn't record SNMP >> traffic going in or out of themselves. We confirmed this multiple >> times by running a query to an IP that was claimed to be clean and >> watching the response come 10-60 seconds later because the device was >> being so heavily abused. >> >> 2) SNMP reflection offers the largest amplification factor by far, >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a >> 68 byte query and received responses of up to 30,000 to 60,000 bytes. >> The trick is to use GetBulkRequest to start enumerating from the first >> OID and setting max repetitions to a large number. This is contrary to >> the other articles online which suggest a much smaller amplification >> factor with other queries. >> >> This protocol is also prevalent in many devices ranging from routers >> to printers. >> >> To solve this problem you should block SNMP traffic coming from >> outside your network and whitelist outside IPs that require it. >> >> From ikiris at gmail.com Wed Jul 31 15:24:51 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 31 Jul 2013 10:24:51 -0500 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: Message-ID: Agreed, but progressively breaking every service on the internet at the edge because you think there might possibly be an issue just leads to bad places. Get better defaults sure, but don't slowly turn the internet into a cable distribution system because "they're just users". It's bad enough already, don't make it worse trying to solve every issue with the nuclear option before trying anything else. -Blake On Wed, Jul 31, 2013 at 10:17 AM, Thomas St-Pierre wrote: > The problem isn't the people on this list leaving the public snmp > community on their devices, it's the vendors of home routers leaving it > there in their devices. Normal end users don't know or even care what snmp > is. (nor can we expect them too) > > A simple scan of a large cable/dsl ISP's address space will likely net you > tens of thousands of devices which respond to the "public" snmp community. > > Thomas > > > > On 13-07-31 10:57 AM, "Blake Dunlap" wrote: > > >This looks like more a security issue with the devices, not border > >security > >issues. > > > >If you're seeing replies of that size, it means the devices themselves are > >set up to allow public queries of their information (not secured by even > >keys), which no one should be comfortable with. People should never be > >leaving the public access snmp strings on devices even if they are > >internal. Edge blocking just masks the real issue. > > > > > >-Blake > > > > > >On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: > > > >> Before you skim past this email because you already read the Prolexic > >> report on it or some other article on the internet, there are 2 > >> disturbing properties that I haven't found anywhere else online. > >> > >> 1) After sending abuse emails to many networks, we received many angry > >> replies that they monitored their traffic for days without seeing > >> anything (even as we were being attacked) and that their IPs were > >> spoofed and would block us for spamming them. > >> > >> What we discovered was that their firewalls/routers/gateways coming > >> from vendors like Cisco and SonicWall apparently didn't record SNMP > >> traffic going in or out of themselves. We confirmed this multiple > >> times by running a query to an IP that was claimed to be clean and > >> watching the response come 10-60 seconds later because the device was > >> being so heavily abused. > >> > >> 2) SNMP reflection offers the largest amplification factor by far, > >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a > >> 68 byte query and received responses of up to 30,000 to 60,000 bytes. > >> The trick is to use GetBulkRequest to start enumerating from the first > >> OID and setting max repetitions to a large number. This is contrary to > >> the other articles online which suggest a much smaller amplification > >> factor with other queries. > >> > >> This protocol is also prevalent in many devices ranging from routers > >> to printers. > >> > >> To solve this problem you should block SNMP traffic coming from > >> outside your network and whitelist outside IPs that require it. > >> > >> > > From oscar.vives at gmail.com Wed Jul 31 15:26:44 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Wed, 31 Jul 2013 17:26:44 +0200 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: On 31 July 2013 16:46, Warren Bailey wrote: > Tin foil hat Wednesday, limited supplies. > > Revealed: NSA program collects 'nearly everything a user does on the internet' > > http://gu.com/p/3hy4h > - Have I read it correctly. Can then break into a vpn connection, then leach documents that a german in pakistan is sending to his office in germany? - So excel documents store MAC address?... time to set them to random numbers :D - What is the red dots in the bottom of the map? satellites? penguin powered servers on the south pole? - The document make it looks like this exist to spy religious terrorist and industrial espionage. But who know. Woah, thats a lot of red dots in europe. Must be to protect the europeans. -- -- ?in del ?ensaje. From jmamodio at gmail.com Wed Jul 31 15:30:03 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 31 Jul 2013 10:30:03 -0500 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: Interesting that they are showing screen captures of a ppt file. -Jorge On Jul 31, 2013, at 9:46 AM, Warren Bailey wrote: > Tin foil hat Wednesday, limited supplies. > > Revealed: NSA program collects 'nearly everything a user does on the internet' > > http://gu.com/p/3hy4h From james.braunegg at micron21.com Wed Jul 31 15:39:06 2013 From: james.braunegg at micron21.com (James Braunegg) Date: Wed, 31 Jul 2013 15:39:06 +0000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: Message-ID: These attacks are known as SAD attacks ;( ... yes very SAD ;( SNMP Amplification DDoS Kindest Regards James Braunegg P:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? W:??www.micron21.com/tv-hosting ?T:?@micron21 This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Thursday, August 01, 2013 1:25 AM To: Thomas St-Pierre Cc: nanog at nanog.org Subject: Re: SNMP DDoS: the vulnerability you might not know you have Agreed, but progressively breaking every service on the internet at the edge because you think there might possibly be an issue just leads to bad places. Get better defaults sure, but don't slowly turn the internet into a cable distribution system because "they're just users". It's bad enough already, don't make it worse trying to solve every issue with the nuclear option before trying anything else. -Blake On Wed, Jul 31, 2013 at 10:17 AM, Thomas St-Pierre wrote: > The problem isn't the people on this list leaving the public snmp > community on their devices, it's the vendors of home routers leaving it > there in their devices. Normal end users don't know or even care what snmp > is. (nor can we expect them too) > > A simple scan of a large cable/dsl ISP's address space will likely net you > tens of thousands of devices which respond to the "public" snmp community. > > Thomas > > > > On 13-07-31 10:57 AM, "Blake Dunlap" wrote: > > >This looks like more a security issue with the devices, not border > >security > >issues. > > > >If you're seeing replies of that size, it means the devices themselves are > >set up to allow public queries of their information (not secured by even > >keys), which no one should be comfortable with. People should never be > >leaving the public access snmp strings on devices even if they are > >internal. Edge blocking just masks the real issue. > > > > > >-Blake > > > > > >On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: > > > >> Before you skim past this email because you already read the Prolexic > >> report on it or some other article on the internet, there are 2 > >> disturbing properties that I haven't found anywhere else online. > >> > >> 1) After sending abuse emails to many networks, we received many angry > >> replies that they monitored their traffic for days without seeing > >> anything (even as we were being attacked) and that their IPs were > >> spoofed and would block us for spamming them. > >> > >> What we discovered was that their firewalls/routers/gateways coming > >> from vendors like Cisco and SonicWall apparently didn't record SNMP > >> traffic going in or out of themselves. We confirmed this multiple > >> times by running a query to an IP that was claimed to be clean and > >> watching the response come 10-60 seconds later because the device was > >> being so heavily abused. > >> > >> 2) SNMP reflection offers the largest amplification factor by far, > >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a > >> 68 byte query and received responses of up to 30,000 to 60,000 bytes. > >> The trick is to use GetBulkRequest to start enumerating from the first > >> OID and setting max repetitions to a large number. This is contrary to > >> the other articles online which suggest a much smaller amplification > >> factor with other queries. > >> > >> This protocol is also prevalent in many devices ranging from routers > >> to printers. > >> > >> To solve this problem you should block SNMP traffic coming from > >> outside your network and whitelist outside IPs that require it. > >> > >> > > From erey at ernw.de Wed Jul 31 15:15:12 2013 From: erey at ernw.de (Enno Rey) Date: Wed, 31 Jul 2013 17:15:12 +0200 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: Message-ID: <20130731151512.GA5018@ernw.de> Hi, On Wed, Jul 31, 2013 at 03:17:37PM +0000, Thomas St-Pierre wrote: > The problem isn't the people on this list leaving the public snmp > community on their devices, it's the vendors of home routers leaving it > there in their devices. Normal end users don't know or even care what snmp > is. (nor can we expect them too) > > A simple scan of a large cable/dsl ISP's address space will likely net you > tens of thousands of devices which respond to the "public" snmp community. I can confirm this. we did some enumeration (and discussed the said amplification attack) here: http://conference.hitb.org/hitbsecconf2007dubai/materials/D1%20-%20Enno%20Rey%20-%20Digging%20into%20SNMP%202007%20-%20An%20Excercise%20on%20Breaking%20Networks.pdf at the time once you scanned "typical broadband segments" of major European carriers, pretty much every address responding to a ping had SNMP "public" also. we gave the talk several times and demoed the amplification attack (with a slightly modified version of this tool: https://www.ernw.de/download/snmpattack.pl) against some of our systems, abusing $SOME_RANDOM_SEGMENT as amplifiers (we asked to stop [camera] recording in those cases where the talks were recorded) and it worked pretty much all the time (~20:1 ratio, initiated from the respective conferences' hotel wifi). thanks Enno > > Thomas > > > > On 13-07-31 10:57 AM, "Blake Dunlap" wrote: > > >This looks like more a security issue with the devices, not border > >security > >issues. > > > >If you're seeing replies of that size, it means the devices themselves are > >set up to allow public queries of their information (not secured by even > >keys), which no one should be comfortable with. People should never be > >leaving the public access snmp strings on devices even if they are > >internal. Edge blocking just masks the real issue. > > > > > >-Blake > > > > > >On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: > > > >> Before you skim past this email because you already read the Prolexic > >> report on it or some other article on the internet, there are 2 > >> disturbing properties that I haven't found anywhere else online. > >> > >> 1) After sending abuse emails to many networks, we received many angry > >> replies that they monitored their traffic for days without seeing > >> anything (even as we were being attacked) and that their IPs were > >> spoofed and would block us for spamming them. > >> > >> What we discovered was that their firewalls/routers/gateways coming > >> from vendors like Cisco and SonicWall apparently didn't record SNMP > >> traffic going in or out of themselves. We confirmed this multiple > >> times by running a query to an IP that was claimed to be clean and > >> watching the response come 10-60 seconds later because the device was > >> being so heavily abused. > >> > >> 2) SNMP reflection offers the largest amplification factor by far, > >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a > >> 68 byte query and received responses of up to 30,000 to 60,000 bytes. > >> The trick is to use GetBulkRequest to start enumerating from the first > >> OID and setting max repetitions to a large number. This is contrary to > >> the other articles online which suggest a much smaller amplification > >> factor with other queries. > >> > >> This protocol is also prevalent in many devices ranging from routers > >> to printers. > >> > >> To solve this problem you should block SNMP traffic coming from > >> outside your network and whitelist outside IPs that require it. > >> > >> > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey Troopers 2013 Videos online: http://www.youtube.com/user/TROOPERScon?feature=watch ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de ======================================================= From cboyd at gizmopartners.com Wed Jul 31 15:50:09 2013 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 31 Jul 2013 10:50:09 -0500 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: On Jul 31, 2013, at 10:26 AM, "<<\"tei''>>>" wrote: > - Have I read it correctly. Can then break into a vpn connection, > then leach documents that a german in pakistan is sending to his > office in germany? I would guess that it's becasuse many VPN services still support PPTP which can be attacked as outlined here: http://www.schneier.com/paper-pptpv2.html --Chris From shortdudey123 at gmail.com Wed Jul 31 15:54:51 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 31 Jul 2013 08:54:51 -0700 Subject: Hilton proxy issue In-Reply-To: References: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> Message-ID: Anyone from Hilton out there? We are still having this issue. It is not a wayport address since I looked and they are not registered under Hilton's name. -Grant On Tue, Jul 16, 2013 at 1:17 PM, Grant Ridder wrote: > The requests are coming from 167.187.100.202 which is in a /16 assigned to > Hilton. As far as i know, the waypoint service has its own netblocks. > > -Grant > > > On Tue, Jul 16, 2013 at 1:11 PM, Jared Mauch wrote: > >> >> On Jul 16, 2013, at 3:44 PM, Grant Ridder >> wrote: >> >> > Hi, >> > >> > Anyone from Hilton Hotels NOC or related on here? We are seeing their >> > internet proxy doing weird things to http requests to servers at >> $DAYJOB. >> >> >> Many of the hilton properties have migrated to Wayport/"attwifi". Are >> you seeing the requests from AT&T/Wayport or from their corporate? >> >> (btw, if you're here and with wayport/attwifi, i would be interested in >> chatting briefly with you). >> >> - Jared > > > From ken.gilmour at gmail.com Wed Jul 31 15:55:43 2013 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Wed, 31 Jul 2013 16:55:43 +0100 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: Don't forget Theo DeRaadt's email about IPSec! http://marc.info/?l=openbsd-tech&m=129236621626462 On 31 July 2013 16:50, Chris Boyd wrote: > > On Jul 31, 2013, at 10:26 AM, "<<\"tei''>>>" < > oscar.vives at gmail.com> wrote: > > > - Have I read it correctly. Can then break into a vpn connection, > > then leach documents that a german in pakistan is sending to his > > office in germany? > > I would guess that it's becasuse many VPN services still support PPTP > which can be attacked as outlined here: > http://www.schneier.com/paper-pptpv2.html > > --Chris > > > From wbailey at satelliteintelligencegroup.com Wed Jul 31 15:56:52 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 31 Jul 2013 15:56:52 +0000 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: , Message-ID: And how many people utilize a VPN for site to site? You can convince me you can spin up an Ipsec connection, but at that point your "originating gateway" changed from your way to the Internet to the VPN's way. Either.. Way.. You still head out in clear channel Internet and get owned elsewhere. I can't see a giant "this doesn't work here" sign on much except for Tor. Sent from my Mobile Device. -------- Original message -------- From: Chris Boyd Date: 07/31/2013 8:52 AM (GMT-08:00) To: NANOG Subject: Re: Revealed: NSA program collects 'nearly everything a user does on the internet' On Jul 31, 2013, at 10:26 AM, "<<\"tei''>>>" wrote: > - Have I read it correctly. Can then break into a vpn connection, > then leach documents that a german in pakistan is sending to his > office in germany? I would guess that it's becasuse many VPN services still support PPTP which can be attacked as outlined here: http://www.schneier.com/paper-pptpv2.html --Chris From Jason_Livingood at cable.comcast.com Wed Jul 31 17:05:55 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 31 Jul 2013 17:05:55 +0000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: Message-ID: <10229F86C86EB444898E629583FD4171BDE0134D@PACDCEXMB06.cable.comcast.com> A relevant paper was released by the BITAG, see http://www.bitag.org/report-snmp-ddos-attacks.php Section 7 includes recommendations. See also this blog post I wrote one day short of a year ago that may be of interest: http://corporate.comcast.com/comcast-voices/taking-steps-to-prevent-unintentional-network-abuse A remaining issue out there for the community is taking action to reduce spoofing. A related project is the Open Resolver Project at http://openresolverproject.org/. - Jason On 7/31/13 6:25 AM, "bottiger" > wrote: Before you skim past this email because you already read the Prolexic report on it or some other article on the internet, there are 2 disturbing properties that I haven't found anywhere else online. 1) After sending abuse emails to many networks, we received many angry replies that they monitored their traffic for days without seeing anything (even as we were being attacked) and that their IPs were spoofed and would block us for spamming them. What we discovered was that their firewalls/routers/gateways coming from vendors like Cisco and SonicWall apparently didn't record SNMP traffic going in or out of themselves. We confirmed this multiple times by running a query to an IP that was claimed to be clean and watching the response come 10-60 seconds later because the device was being so heavily abused. 2) SNMP reflection offers the largest amplification factor by far, even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a 68 byte query and received responses of up to 30,000 to 60,000 bytes. The trick is to use GetBulkRequest to start enumerating from the first OID and setting max repetitions to a large number. This is contrary to the other articles online which suggest a much smaller amplification factor with other queries. This protocol is also prevalent in many devices ranging from routers to printers. To solve this problem you should block SNMP traffic coming from outside your network and whitelist outside IPs that require it. From bzs at world.std.com Wed Jul 31 17:17:16 2013 From: bzs at world.std.com (Barry Shein) Date: Wed, 31 Jul 2013 13:17:16 -0400 Subject: ARIN WHOIS for leads In-Reply-To: <51F92683.3080200@west.net> References: <51F2968A.3090701@opus1.com> <51F92683.3080200@west.net> Message-ID: <20985.18076.970267.597692@world.std.com> On July 31, 2013 at 08:00 jay at west.net (Jay Hennigan) wrote: > > It's surprising how people go out of their way to deny that it's a sales > call, and then start trying to sell something. [NOTE: The anecdote is followed by some practical advice] I had a guy call and tell the person who answered he was my brother and there was a family emergency. I don't have a brother. I said put him through. He began a sales pitch. That was quite a few years ago, he probably still talks about what jerk I am and if so I am proud of it! THAT SAID, beyond personal tastes, in this context there's really only one substantive complaint: Telemarketing info is PAID FOR, particularly in a ready to use list form. If they're scraping WHOIS etc for free that's a problem. Lists can be protected by intellectual property law against such abuse. The usual method is to insert "ringers" which would be info which points back at non-existant people with valid-looking contact information. If for example they called a phone number, or several, owned by ARIN (or a service they employed) asking for James T Kirk or Diana Prince then that would be a problem and should be logged. One obvious response is to just bill them a reasonable telemarketing list rental fee for the entire database and go from there. Believe it or not this is well-trod ground, people steal or abuse (e.g., resell w/o permission) telemarketing and mailing list info all the time. -- -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 ras at e-gerbil.net Wed Jul 31 17:38:08 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 31 Jul 2013 12:38:08 -0500 Subject: GTT/Inteliquent/nLayer In-Reply-To: References: Message-ID: <20130731173808.GR67768@gerbil.cluepon.net> On Wed, Jul 31, 2013 at 09:28:50AM -0400, Tim Durack wrote: > Any experience/comments on the GTT Global eXpress service? Looks > interesting but odd. Why would I use a virtual IXP? Who participates? > > Comments on-list or off-list are fine. This was an old PacketExchange service, essentially just a single large VPLS-based global layer 2 virtual IXP service, which combined long-haul transport and multi-party interconnection. It's somewhat interesting as a concept (since I'm not aware of anyone else offering anything similar), but IMHO not the most practical thing in the world, which is why it hasn't really been promoted as a new product in many years. If you've heard differently, please contact me off-list. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From bottiger10 at gmail.com Wed Jul 31 20:11:37 2013 From: bottiger10 at gmail.com (bottiger) Date: Wed, 31 Jul 2013 13:11:37 -0700 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: Message-ID: Public SNMP being exploited for 8000x amplification is a very serious issue. It is arguably worse than open email relays. Not only does it expose critical information from your users but it offers the largest possible amplified DDoS by far, likely bigger than DNS when you take into account the amplification size and ubiquity. It will also cause your user's device to lag. The most disturbing part is the lack of logging. We have tried reporting these exploited servers for many weeks and because of the logging problem most of them never get shut down because they just assume they were being spoofed. We even had replies threatening to block us because they thought were because they couldn't see they were sending anything. When we were reported chargen attacks we had much more positive responses. Maybe you could refine the block by denying SNMP requests with the public string. As network operators some compromises must be made for a problem of this magnitude instead of just saying that you should only be the best dumb pipe you can be. We have seen attacks large enough to disturb 10G uplinks so as network administrators you should not ignore this issue because you think it is a small problem affecting only end users. This will affect you once more people figure out how to get 8000x amplification from it. It is great news that Comcast is trying to proactively solve this problem on their network and hope that more networks would follow their example. On Wed, Jul 31, 2013 at 8:24 AM, Blake Dunlap wrote: > Agreed, but progressively breaking every service on the internet at the edge > because you think there might possibly be an issue just leads to bad places. > > Get better defaults sure, but don't slowly turn the internet into a cable > distribution system because "they're just users". It's bad enough already, > don't make it worse trying to solve every issue with the nuclear option > before trying anything else. > > -Blake > > > On Wed, Jul 31, 2013 at 10:17 AM, Thomas St-Pierre > wrote: >> >> The problem isn't the people on this list leaving the public snmp >> community on their devices, it's the vendors of home routers leaving it >> there in their devices. Normal end users don't know or even care what snmp >> is. (nor can we expect them too) >> >> A simple scan of a large cable/dsl ISP's address space will likely net you >> tens of thousands of devices which respond to the "public" snmp community. >> >> Thomas >> >> >> >> On 13-07-31 10:57 AM, "Blake Dunlap" wrote: >> >> >This looks like more a security issue with the devices, not border >> >security >> >issues. >> > >> >If you're seeing replies of that size, it means the devices themselves >> > are >> >set up to allow public queries of their information (not secured by even >> >keys), which no one should be comfortable with. People should never be >> >leaving the public access snmp strings on devices even if they are >> >internal. Edge blocking just masks the real issue. >> > >> > >> >-Blake >> > >> > >> >On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: >> > >> >> Before you skim past this email because you already read the Prolexic >> >> report on it or some other article on the internet, there are 2 >> >> disturbing properties that I haven't found anywhere else online. >> >> >> >> 1) After sending abuse emails to many networks, we received many angry >> >> replies that they monitored their traffic for days without seeing >> >> anything (even as we were being attacked) and that their IPs were >> >> spoofed and would block us for spamming them. >> >> >> >> What we discovered was that their firewalls/routers/gateways coming >> >> from vendors like Cisco and SonicWall apparently didn't record SNMP >> >> traffic going in or out of themselves. We confirmed this multiple >> >> times by running a query to an IP that was claimed to be clean and >> >> watching the response come 10-60 seconds later because the device was >> >> being so heavily abused. >> >> >> >> 2) SNMP reflection offers the largest amplification factor by far, >> >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a >> >> 68 byte query and received responses of up to 30,000 to 60,000 bytes. >> >> The trick is to use GetBulkRequest to start enumerating from the first >> >> OID and setting max repetitions to a large number. This is contrary to >> >> the other articles online which suggest a much smaller amplification >> >> factor with other queries. >> >> >> >> This protocol is also prevalent in many devices ranging from routers >> >> to printers. >> >> >> >> To solve this problem you should block SNMP traffic coming from >> >> outside your network and whitelist outside IPs that require it. >> >> >> >> >> > From shortdudey123 at gmail.com Wed Jul 31 20:16:34 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 31 Jul 2013 13:16:34 -0700 Subject: Hilton proxy issue In-Reply-To: References: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> Message-ID: Better yet, does anyone have any Hilton contacts they could pass my info to? -Grant On Wed, Jul 31, 2013 at 8:54 AM, Grant Ridder wrote: > Anyone from Hilton out there? We are still having this issue. It is not > a wayport address since I looked and they are not registered under Hilton's > name. > > -Grant > > > On Tue, Jul 16, 2013 at 1:17 PM, Grant Ridder wrote: > >> The requests are coming from 167.187.100.202 which is in a /16 assigned >> to Hilton. As far as i know, the waypoint service has its own netblocks. >> >> -Grant >> >> >> On Tue, Jul 16, 2013 at 1:11 PM, Jared Mauch wrote: >> >>> >>> On Jul 16, 2013, at 3:44 PM, Grant Ridder >>> wrote: >>> >>> > Hi, >>> > >>> > Anyone from Hilton Hotels NOC or related on here? We are seeing their >>> > internet proxy doing weird things to http requests to servers at >>> $DAYJOB. >>> >>> >>> Many of the hilton properties have migrated to Wayport/"attwifi". Are >>> you seeing the requests from AT&T/Wayport or from their corporate? >>> >>> (btw, if you're here and with wayport/attwifi, i would be interested in >>> chatting briefly with you). >>> >>> - Jared >> >> >> > From wbailey at satelliteintelligencegroup.com Wed Jul 31 20:16:39 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 31 Jul 2013 20:16:39 +0000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: , Message-ID: Write into your TOS a block for SNMP. Deal with the whiners on a case by case basis. Problem solved. Sent from my Mobile Device. -------- Original message -------- From: bottiger Date: 07/31/2013 1:13 PM (GMT-08:00) To: Blake Dunlap Cc: nanog at nanog.org Subject: Re: SNMP DDoS: the vulnerability you might not know you have Public SNMP being exploited for 8000x amplification is a very serious issue. It is arguably worse than open email relays. Not only does it expose critical information from your users but it offers the largest possible amplified DDoS by far, likely bigger than DNS when you take into account the amplification size and ubiquity. It will also cause your user's device to lag. The most disturbing part is the lack of logging. We have tried reporting these exploited servers for many weeks and because of the logging problem most of them never get shut down because they just assume they were being spoofed. We even had replies threatening to block us because they thought were because they couldn't see they were sending anything. When we were reported chargen attacks we had much more positive responses. Maybe you could refine the block by denying SNMP requests with the public string. As network operators some compromises must be made for a problem of this magnitude instead of just saying that you should only be the best dumb pipe you can be. We have seen attacks large enough to disturb 10G uplinks so as network administrators you should not ignore this issue because you think it is a small problem affecting only end users. This will affect you once more people figure out how to get 8000x amplification from it. It is great news that Comcast is trying to proactively solve this problem on their network and hope that more networks would follow their example. On Wed, Jul 31, 2013 at 8:24 AM, Blake Dunlap wrote: > Agreed, but progressively breaking every service on the internet at the edge > because you think there might possibly be an issue just leads to bad places. > > Get better defaults sure, but don't slowly turn the internet into a cable > distribution system because "they're just users". It's bad enough already, > don't make it worse trying to solve every issue with the nuclear option > before trying anything else. > > -Blake > > > On Wed, Jul 31, 2013 at 10:17 AM, Thomas St-Pierre > wrote: >> >> The problem isn't the people on this list leaving the public snmp >> community on their devices, it's the vendors of home routers leaving it >> there in their devices. Normal end users don't know or even care what snmp >> is. (nor can we expect them too) >> >> A simple scan of a large cable/dsl ISP's address space will likely net you >> tens of thousands of devices which respond to the "public" snmp community. >> >> Thomas >> >> >> >> On 13-07-31 10:57 AM, "Blake Dunlap" wrote: >> >> >This looks like more a security issue with the devices, not border >> >security >> >issues. >> > >> >If you're seeing replies of that size, it means the devices themselves >> > are >> >set up to allow public queries of their information (not secured by even >> >keys), which no one should be comfortable with. People should never be >> >leaving the public access snmp strings on devices even if they are >> >internal. Edge blocking just masks the real issue. >> > >> > >> >-Blake >> > >> > >> >On Tue, Jul 30, 2013 at 11:25 PM, bottiger wrote: >> > >> >> Before you skim past this email because you already read the Prolexic >> >> report on it or some other article on the internet, there are 2 >> >> disturbing properties that I haven't found anywhere else online. >> >> >> >> 1) After sending abuse emails to many networks, we received many angry >> >> replies that they monitored their traffic for days without seeing >> >> anything (even as we were being attacked) and that their IPs were >> >> spoofed and would block us for spamming them. >> >> >> >> What we discovered was that their firewalls/routers/gateways coming >> >> from vendors like Cisco and SonicWall apparently didn't record SNMP >> >> traffic going in or out of themselves. We confirmed this multiple >> >> times by running a query to an IP that was claimed to be clean and >> >> watching the response come 10-60 seconds later because the device was >> >> being so heavily abused. >> >> >> >> 2) SNMP reflection offers the largest amplification factor by far, >> >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a >> >> 68 byte query and received responses of up to 30,000 to 60,000 bytes. >> >> The trick is to use GetBulkRequest to start enumerating from the first >> >> OID and setting max repetitions to a large number. This is contrary to >> >> the other articles online which suggest a much smaller amplification >> >> factor with other queries. >> >> >> >> This protocol is also prevalent in many devices ranging from routers >> >> to printers. >> >> >> >> To solve this problem you should block SNMP traffic coming from >> >> outside your network and whitelist outside IPs that require it. >> >> >> >> >> > From wbailey at satelliteintelligencegroup.com Wed Jul 31 20:19:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 31 Jul 2013 20:19:21 +0000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: <10229F86C86EB444898E629583FD4171BDE0134D@PACDCEXMB06.cable.comcast.com> References: , <10229F86C86EB444898E629583FD4171BDE0134D@PACDCEXMB06.cable.comcast.com> Message-ID: Would it be possible to add SNMP to your (collective cable labs buddies) shapers and it would be taken care of prior to it leaving your network but after the cmts? Sent from my Mobile Device. -------- Original message -------- From: "Livingood, Jason" Date: 07/31/2013 10:07 AM (GMT-08:00) To: bottiger ,nanog at nanog.org Subject: Re: SNMP DDoS: the vulnerability you might not know you have A relevant paper was released by the BITAG, see http://www.bitag.org/report-snmp-ddos-attacks.php Section 7 includes recommendations. See also this blog post I wrote one day short of a year ago that may be of interest: http://corporate.comcast.com/comcast-voices/taking-steps-to-prevent-unintentional-network-abuse A remaining issue out there for the community is taking action to reduce spoofing. A related project is the Open Resolver Project at http://openresolverproject.org/. - Jason On 7/31/13 6:25 AM, "bottiger" > wrote: Before you skim past this email because you already read the Prolexic report on it or some other article on the internet, there are 2 disturbing properties that I haven't found anywhere else online. 1) After sending abuse emails to many networks, we received many angry replies that they monitored their traffic for days without seeing anything (even as we were being attacked) and that their IPs were spoofed and would block us for spamming them. What we discovered was that their firewalls/routers/gateways coming from vendors like Cisco and SonicWall apparently didn't record SNMP traffic going in or out of themselves. We confirmed this multiple times by running a query to an IP that was claimed to be clean and watching the response come 10-60 seconds later because the device was being so heavily abused. 2) SNMP reflection offers the largest amplification factor by far, even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a 68 byte query and received responses of up to 30,000 to 60,000 bytes. The trick is to use GetBulkRequest to start enumerating from the first OID and setting max repetitions to a large number. This is contrary to the other articles online which suggest a much smaller amplification factor with other queries. This protocol is also prevalent in many devices ranging from routers to printers. To solve this problem you should block SNMP traffic coming from outside your network and whitelist outside IPs that require it. From jay+NANOG at tp.org Wed Jul 31 20:31:47 2013 From: jay+NANOG at tp.org (Jay Moran) Date: Wed, 31 Jul 2013 16:31:47 -0400 Subject: Hilton proxy issue In-Reply-To: References: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> Message-ID: I have BCC'd the likely appropriate Hilton contact for you on this response so they can take a look at the NANOG emails below regarding their Internet proxies to see if it looks like something they can assist with. They were able to have some MTA issues corrected last time Hilton came up on the NANOG list. Good luck! -- Jay Moran http://linked.com/in/jaycmoran On Wed, Jul 31, 2013 at 4:16 PM, Grant Ridder wrote: > Better yet, does anyone have any Hilton contacts they could pass my info > to? > > -Grant > > On Wed, Jul 31, 2013 at 8:54 AM, Grant Ridder >wrote: > > > Anyone from Hilton out there? We are still having this issue. It is not > > a wayport address since I looked and they are not registered under > Hilton's > > name. > > > > -Grant > > > > > > On Tue, Jul 16, 2013 at 1:17 PM, Grant Ridder >wrote: > > > >> The requests are coming from 167.187.100.202 which is in a /16 assigned > >> to Hilton. As far as i know, the waypoint service has its own > netblocks. > >> > >> -Grant > >> > >> > >> On Tue, Jul 16, 2013 at 1:11 PM, Jared Mauch >wrote: > >> > >>> > >>> On Jul 16, 2013, at 3:44 PM, Grant Ridder > >>> wrote: > >>> > >>> > Hi, > >>> > > >>> > Anyone from Hilton Hotels NOC or related on here? We are seeing > their > >>> > internet proxy doing weird things to http requests to servers at > >>> $DAYJOB. > >>> > >>> > >>> Many of the hilton properties have migrated to Wayport/"attwifi". Are > >>> you seeing the requests from AT&T/Wayport or from their corporate? > >>> > >>> (btw, if you're here and with wayport/attwifi, i would be interested in > >>> chatting briefly with you). > >>> > >>> - Jared > From rdobbins at arbor.net Wed Jul 31 20:46:59 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 31 Jul 2013 20:46:59 +0000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: Message-ID: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> On Aug 1, 2013, at 3:11 AM, bottiger wrote: > The most disturbing part is the lack of logging. Flow telemetry can be of use in this instance. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From ikiris at gmail.com Wed Jul 31 21:29:18 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 31 Jul 2013 16:29:18 -0500 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> Message-ID: I bet blocking all SYN packets and non related flow UDP packets to customers would be even more effective. Why don't we do that and be done with it instead of playing whack a mole every 3 months when someone finds some new service that was poorly designed so that it can be used to send a flood? Yes, I'm being sarcastic above. This is hardly the first finger of death amplification attack, and I strongly doubt it'll be the last. Years ago it was smurf, then Quake servers, then DNS, then Battlefield boxes, etc etc. Now it seems to be snmp and recently chargen, and tomorrow it'll be some peer 2 peer service, the next day it'll be a voice app. It will never end, and breaking the internet port by port doesn't do anything to make it better. I've been the victim of week long DDoS attacks that took down our upstreams, not to mention us, and I still maintain the above. It works better to fix the design issues than to play whack a mole by blocking every imaginable service to your customers that responds to the public with data larger than a FIN. Like getting their providers to more proactively police their spew, manufactures to stop making negligent devices, or implementing more intelligent filter communication so the only option doesn't begin with calling your provider and asking them over the phone to block X ip for you since you're off the internet. Maybe even look into liability laws for allowing said attacks to originate from your customers and not doing anything about it, or being manufacturer of said devices that harm others through their lack of due diligence implementing proper security. It's still way more effective than trying to fix the *last instance* of the problem, instead of it's reasons for enduring as an issue at a global scale. -Blake On Wed, Jul 31, 2013 at 3:46 PM, Dobbins, Roland wrote: > > On Aug 1, 2013, at 3:11 AM, bottiger wrote: > > > The most disturbing part is the lack of logging. > > Flow telemetry can be of use in this instance. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From bottiger10 at gmail.com Wed Jul 31 22:02:13 2013 From: bottiger10 at gmail.com (bottiger) Date: Wed, 31 Jul 2013 15:02:13 -0700 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> Message-ID: This vulnerability has been present ever since SNMP v2 was announced back in 1993. There is a reason why the biggest attacks these days are from protocols that are decades old like DNS and Chargen. People making widely spread protocols these days are aware of the problem and are usually able to get their software to auto-update. Enforcing source IP filtering seems like a lost cause. Not much progress has been made that I can tell and it is difficult to discover if the network allows it without being inside it. I don't see many uses for unsecured SNMP access so this is not like blocking all syn and udp packets. On Wed, Jul 31, 2013 at 2:29 PM, Blake Dunlap wrote: > I bet blocking all SYN packets and non related flow UDP packets to > customers would be even more effective. Why don't we do that and be done > with it instead of playing whack a mole every 3 months when someone finds > some new service that was poorly designed so that it can be used to send a > flood? > > Yes, I'm being sarcastic above. > > This is hardly the first finger of death amplification attack, and I > strongly doubt it'll be the last. Years ago it was smurf, then Quake > servers, then DNS, then Battlefield boxes, etc etc. Now it seems to be snmp > and recently chargen, and tomorrow it'll be some peer 2 peer service, the > next day it'll be a voice app. It will never end, and breaking the internet > port by port doesn't do anything to make it better. > > I've been the victim of week long DDoS attacks that took down our > upstreams, not to mention us, and I still maintain the above. > > It works better to fix the design issues than to play whack a mole by > blocking every imaginable service to your customers that responds to the > public with data larger than a FIN. Like getting their providers to more > proactively police their spew, manufactures to stop making negligent > devices, or implementing more intelligent filter communication so the only > option doesn't begin with calling your provider and asking them over the > phone to block X ip for you since you're off the internet. > > Maybe even look into liability laws for allowing said attacks to originate > from your customers and not doing anything about it, or being manufacturer > of said devices that harm others through their lack of due diligence > implementing proper security. It's still way more effective than trying to > fix the *last instance* of the problem, instead of it's reasons for > enduring as an issue at a global scale. > > -Blake > > > On Wed, Jul 31, 2013 at 3:46 PM, Dobbins, Roland wrote: > >> >> On Aug 1, 2013, at 3:11 AM, bottiger wrote: >> >> > The most disturbing part is the lack of logging. >> >> Flow telemetry can be of use in this instance. >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Luck is the residue of opportunity and design. >> >> -- John Milton >> >> >> From LarrySheldon at cox.net Wed Jul 31 22:50:18 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 31 Jul 2013 17:50:18 -0500 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: <79WN1m01D1Una3W019WPWf> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <79WN1m01D1Una3W019WPWf> Message-ID: <51F994AA.9090402@cox.net> On 7/31/2013 4:29 PM, Blake Dunlap wrote: > It works better to fix the design issues than to play whack a mole > by blocking every imaginable service to your customers that responds > to the public with data larger than a FIN. Like getting their > providers to more proactively police their spew, manufactures to stop > making negligent devices, or implementing more intelligent filter > communication so the only option doesn't begin with calling your > provider and asking them over the phone to block X ip for you since > you're off the internet. > > Maybe even look into liability laws for allowing said attacks to > originate from your customers and not doing anything about it, or > being manufacturer of said devices that harm others through their > lack of due diligence implementing proper security. It's still way > more effective than trying to fix the *last instance* of the problem, > instead of it's reasons for enduring as an issue at a global scale. The first time I became a pariah on NANOG was for postulating precisely that view--that if the originators of problems would stop, we would not have to figure out how to clean up after them. But I am past that now and out of work. But it does occur to me for the first time that I can recall, that maybe the tremendous efforts to Get Control Of The Intertubes could be suckered into doing some good, say be establishing a certification authority to test and certify the safety of designs (is Scott B????? still around) and devise a way to not permit traffic from uncertified devices or configurations. But after years of research I will tell you that there is no way to stop an avalanche once it has been released at the source. -- 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 jfbeam at gmail.com Wed Jul 31 23:05:27 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 31 Jul 2013 19:05:27 -0400 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: <51F994AA.9090402@cox.net> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <79WN1m01D1Una3W019WPWf> <51F994AA.9090402@cox.net> Message-ID: On Wed, 31 Jul 2013 18:50:18 -0400, Larry Sheldon wrote: > But after years of research I will tell you that there is no way to stop > an avalanche once it has been released at the source. http://youtu.be/60loeoblu0M Anyone can make a device and connect it to the internet. From shortdudey123 at gmail.com Wed Jul 31 23:34:21 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 31 Jul 2013 16:34:21 -0700 Subject: Hilton proxy issue In-Reply-To: References: <9AB39A70-5DCF-4A49-8360-6529A9763493@puck.nether.net> Message-ID: Sounds great Jay, thanks! On Wed, Jul 31, 2013 at 1:31 PM, Jay Moran wrote: > I have BCC'd the likely appropriate Hilton contact for you on this > response so they can take a look at the NANOG emails below regarding their > Internet proxies to see if it looks like something they can assist with. > They were able to have some MTA issues corrected last time Hilton came up > on the NANOG list. Good luck! > -- > Jay Moran > http://linked.com/in/jaycmoran > > On Wed, Jul 31, 2013 at 4:16 PM, Grant Ridder wrote: > >> Better yet, does anyone have any Hilton contacts they could pass my info >> to? >> >> -Grant >> >> On Wed, Jul 31, 2013 at 8:54 AM, Grant Ridder > >wrote: >> >> > Anyone from Hilton out there? We are still having this issue. It is >> not >> > a wayport address since I looked and they are not registered under >> Hilton's >> > name. >> > >> > -Grant >> > >> > >> > On Tue, Jul 16, 2013 at 1:17 PM, Grant Ridder > >wrote: >> > >> >> The requests are coming from 167.187.100.202 which is in a /16 assigned >> >> to Hilton. As far as i know, the waypoint service has its own >> netblocks. >> >> >> >> -Grant >> >> >> >> >> >> On Tue, Jul 16, 2013 at 1:11 PM, Jared Mauch > >wrote: >> >> >> >>> >> >>> On Jul 16, 2013, at 3:44 PM, Grant Ridder >> >>> wrote: >> >>> >> >>> > Hi, >> >>> > >> >>> > Anyone from Hilton Hotels NOC or related on here? We are seeing >> their >> >>> > internet proxy doing weird things to http requests to servers at >> >>> $DAYJOB. >> >>> >> >>> >> >>> Many of the hilton properties have migrated to Wayport/"attwifi". Are >> >>> you seeing the requests from AT&T/Wayport or from their corporate? >> >>> >> >>> (btw, if you're here and with wayport/attwifi, i would be interested >> in >> >>> chatting briefly with you). >> >>> >> >>> - Jared >> > > From maray at microsoft.com Wed Jul 31 21:14:30 2013 From: maray at microsoft.com (Marsh Ray) Date: Wed, 31 Jul 2013 21:14:30 +0000 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' Message-ID: Chris Boyd cboyd at gizmopartners.com Wed Jul 31 15:50:09 UTC 2013 > > I would guess that it's becasuse many VPN services still support PPTP which can be attacked as outlined here: > http://www.schneier.com/paper-pptpv2.html > > --Chris That link doesn't even mention the worst vulnerability in PPTP/MS-CHAPv2. Strangely, it's only in the PDF version http://www.schneier.com/paper-pptpv2.pdf at the bottom of page 6: > Note also that the MS-CHAP response generation algorithm is also a weak > link, even when passwords contain adequate entropy. It is clear that the NT > hash can be recovered with just two DES exhaustive keysearches (about 256 > trial DES decryptions on average) In other words, PPTP/MS-CHAPv2 is equivalent to encrypting your password with *single DES* and sending it over the untrusted network. It doesn't matter how strong your plaintext password is. Not only can the passive eavesdropper decrypt your VPN-tunneled data, he can obtain the NT hash which is a password-equivalent credential allowing him to impersonate the user to log into any other network services. Moxie Marlinspike and David Hulton described the exploit for it at Defcon 20 last summer: Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2 http://www.youtube.com/watch?v=vWXP3DvH8OQ Moxie's Cloudcracker online service will decrypt your PPTP packet captures using an FPGA cluster from Pico Computing. Last I heard, the price was a flat fee of $200, although it sometimes goes on sale. http://www.h-online.com/security/features/A-death-blow-for-PPTP-1716768.html http://h-online.com/-1716768 So it's not just the NSA, it's any passive observer with a budget of $200 for a one-off or ~$10K for their own hardware capability. PPTP is old and busted, don't let your friends use it! If you've ever used it, change your password. IMHO, if there's any other protocol more deserving of the "internet kill switch" I don't know what it is. - Marsh (sorry for not threading properly, I just subscribed to reply) From mysidia at gmail.com Wed Jul 31 23:42:07 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 31 Jul 2013 18:42:07 -0500 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> Message-ID: On 7/31/13, Blake Dunlap wrote: > I bet blocking all SYN packets and non related flow UDP packets to > customers would be even more effective. Why don't we do that and be done > with it instead of playing whack a mole every 3 months when someone finds > some new service that was poorly designed so that it can be used to send a > flood? Because it breaks applications that people are paying to be able to use. The way I see it; more and more samples keep getting found about protocols abused because networks have not implemented BCP38. The latest SNMP trend is just another uptick to the sample size, and proof that Closing off perfectly OK recursive DNS services is totally inadequate and not a useful long-term fix to the problem of DDoS or IP/UDP reflection attacks. Asking folks to improve the security of access to their SNMP instances is just chasing the latest exploit implementation, with no attention to the vulnerability or the root cause.... -- -JH